• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 100 subscribers
  • Views 341 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM368 artefact

pgQuest
Prodigy 50 points

Hello

Tried streaming 800x600 @60fps from a laptop and a desktop PC separately through their DVI/HDMI ports but seeing a grey moving pixel region across the image at certain times. It is not there in the main desktop screen for example but comes up when opening some windows and applications on the PCs. Using IPNC. A video decoder captures the raw input and converts it to yuv 422 and sends it to the dm368 with the syncs through the generic port. Using MJPEG for streaming. Tried with 1280x720 @60fps but the corruption remains.  How could i remove the noise?

Regards

PG.

  • 0
    TI__Expert 8465 points

    Hi PG,

    If I understand you correctly, you are using DM36x MJPEG encoder, its getting PC screen as video input and you are streaming the encoded MJPEG video. In the encoded MJPEG stream you are seeing the corruption. And you are saying corruption is random and mostly seen when you open new window in PC. As opening the new window is not related to MJPEG encoder running on DM36x, I guess input YUV to MJPEG encoder might be corrupted. Can you please conform this?

  • 0 in reply to Veeranna Hanchinal
    TI__Genius 11000 points

    Hello,

    Also, are you observing this issue when using IE ?

    Can you check with VLC streaming and check if you encounter bitsream errors

    Regards,

    Raghu

     

  • 0 in reply to Raghu Kudva
    Prodigy 50 points

    Hi

    Thanks for replies. Am still trying to isolate this. Am using ISIF-IPIPE/RSZ-DDR use case. Did not notice this problem for one scenario: 1280x720@60fps capture and 640x480@60fps encoded stream. Does this probably mean that the problem is related to resizer-DDR interface? Is it because of any fluctuations in the blanking information or line timing from the source which might cause variation in the resizer-DDR bandwidth? A dmaInterval (DMA_RSZ) parameter in resizer set params function also seems to be a factor because varying that value is causing changes in the gray noise. The datasheet says that this parameter specifies the minimum number of VPSS clock cycles between two DMA accesses but I could not find any information on the acceptable values to program for different resolutions. Tried tuning this value thinking that a higher value maybe given for lower resolutions and a lower value for higher resolutions but the corruption remains. Tried bypassing the resizer but the problem remains. Maybe because RSZ_A is still enabled in bypass? Could this be related to improper resizer buffer allocation? Am i debugging in the correct directions?

    Regards

    PG.