• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 869 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.

YCbCr 4:2:2 input data problem

Randy Scheifele
Intellectual 550 points

Hi,

I am attempting to capture SDI video input through the GS2971A video decoder.  I am able to get an image through and out the component output on the DM368 EVM, but I can't seem to get the image to show the proper colors.  When I configure the IPIPE data flow for SRC_FMT=3 (page 84 of the VPFE users manual), I can see some of text on a paper that I am viewing with the camera but the colors are all over the place.  When I configure the SRC_FMT=0, I get a crystal clear image, but it's black and white.

The GS2971A outputs YCbCr 4:2:2 so I expect to have the SRC_FMT set to 3.  I am also attempting to configure the resizer in continuous mode to convert the YCbCr 4:2:2 to YCbCr 4:2:0 so it is in the proper format for the H264 encoder.  I also have the BT.1120 configuration set up per the VPFE manual.

The data flow for the YCbCr input seems much simpler than a raw input so I am struggling to see what I am missing.  Are there any registers that I should focus on that would affect the color of the video feed when in this mode?  For example, do the ISIF.SDOFST registers come into play when I am not writing to SDRAM from the ISIF (since I am piping directly to the IPIPE)?

Any suggestions on registers values that I should focus on would be greatly appreciated!

Thanks,

Randy Scheifele

  • 0
    Intellectual 550 points

    A small follow up:

    I modified the linux driver example "capture_prev_rsz_onthe_fly_yuv" and I am getting the same image on my output display as when I perform a gstreamer passthrough pipeline on the video input.  Are there any debug statements that I could put into the capture_prev_rsz_onthe_fly_yuv program that would help in debugging this issue?  Once again, the video is there but the colors are all messed up.

    Any help is greatly appreciated!

    Randy

  • 0 in reply to Randy Scheifele
    TI__Expert 4685 points

    Please provide details such as width, height, bpp of the images you are capturing. Also, provide snapshots to understand nature of the corruption you are talking about.

  • 0 in reply to Nagabhushana
    Intellectual 550 points

    Hi Nagabhushana,

    Thanks for your response.  The incoming video is 1280x720 @ 60fps.  The following is some output from the capture:


    Changed mode to davinci_v4l2 davinci_v4l2.1: Before finishing with S_FMT:
    layer.pix_fmt.bytesperline = 2560,
     layer.pix_fmt.width = 1280,
     layer.pix_fmt.height = 720,
     layer.pix_fmt.sizeimage =1843200
    720P-60


    I have attached two pictures that show the picture that I am getting through the dm365.  One of the images is of a TV monitor with the signal from the davinci and the other is the object that I am taking the video of (Juniper networks CD).

    Please let me know if there is any other debug information I can provide.

    Thanks!
    Randy

     

  • 0 in reply to Randy Scheifele
    TI__Expert 4685 points

    Two cases you need to check.

    1. The color sequence(Y Cb Cr) at capture side and display side should match. If they are messed up, above corruption can happen.

    2. You can verify captured buffers with applications and check the actual format.

  • 0 in reply to Nagabhushana
    Intellectual 550 points

    Hi Nagabhushana,

    Thanks for all your assistance.  The problem was actually in the wiring for a custom cable between our decoder and the dm365.  The capture is up and running successfully now.

    Thanks!

    Randy