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.

Generic YCbCr Capture issue on DM355

Hi All,

I am facing issue, while capturing 16-bit Interlace 1080i data on DM355 through Generic YCbCr interface. 0xC0 pixels at the start of each line are black in single field, while other field is absolutely correct. Attached files describes it well.

 

Has anyone faced this kind of issue?

Any kind of help will be appreciated.

Thanks,

Deepika

 

  • Are you doing any resizing of the image or is this simply a capture and display scenerio?  both Luma and chroma components seem to be present; it could be a memory buffer offset problem; one thing we can experiment with is filling display buffer with a known color and then writing valid video data to it to see if there is any data that is not being overwritten (still has known color data in it).   This would tell us if the issue is due to not writing all expected data to the correct place or if it is something more subtle like chroma color swaping issue, although I would expect the latter to change the entire buffer not only the begining of the lines.

  • Hi Juan,

    Thanks for help.

    No resizing operation is done here and I have already tried with 0x80 in complete buffer, however the issue is resolved now after making two changes in ccdc_dm355.c files (i.e VPFE CCDC driver).

    1080i is 1125 Line Interlaced data, in which total horizontal resolution is 2200 and horizontal blanking is 280, as per this values v4l2_rect window should have below configurations:

    • win.top = 44
    • win.left = 192
    • win.width = 1920
    • win.height = 1080

    Other than this, in ccdc_setwin function which is used to configure window size, sets horz_start and horz_nr_pixels considering data to be 8-bit if ppc = 2 and 16-bit if ppc = 1, correct me if I am wrong, in my case ppc argument to ccdc_setwin function should be 1.

    Thanks,

    Deepika

     

  • I am glad to hear this is resolved.  You are correct, DM355 IPIPE treats YCbCr pixels as 16-bit pixels, hence ppc should be 1.