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.

capture debug in RDK

Guru 20755 points

Hello,

We are trying to detect captured video frames which are recieved from FPGA but still detect no valid frames from FPGA.
I would like to ask if you can guide us with debug step of the hardware/software of this interface.
Is there a way maybe to check if the hardware between FPGA and VIP port 0, 16 bit interface is OK ?

Regards,

Ran

  • Hi Ran,

    The RDK configures capture to capture pixel muxed video source on 8 bit interface.
    Please list video stream details
    1. Is it muxed (pixel / line)
    2. In embedded sync mode / discerete sync mode

    Thanks,
    Sujith
  • Hi Sujith,

    we are trying in several directions:

    1. FPGA version that output 16-bit single channel video. We don't detect frames, though in onw of FPGA version's we've seen that off fields counter is increased, but the resolutions numbers are not valid in these statistics.
    2. FPGA version that output 8-bit signle channel. This FPGA version is not yet ready for test.

    Do you have any idea how we can debug this ?

    Ran

  • Hi Ran,
    OK, let consider the single channel 16 bit FPGA.
    1. Ensure pixel clock, hSync, vSync, DE (Data enable / active video) frequencies are as requited. e.g. vSync should be 60 HZ for 60 FPS capture.
    2. Update the Capture link to use discrete sync mode of capture. Please look at capture link creation time parameters.
    Before that,
    You will have to decided which mode of discrete sync capture would you require. Would you want to use hSync, vSync and DE lines or would you want to use vSync and DE lines. The VIP TRM lists various options possible. Once this is decided, we can list out the capture configurations that you would require.
    Thanks,
    Sujith

  • hi sujith

    we are working in embedded mode sorry for not mentioning it

    ran

  • Hi Ran,

     

    Could you first check that the SAV/EAV code is correct in your input? FVH bits are toggling correctly in the input streams? If there is any problem in input stream, Input port will not be able to detect stream correctly.

     

    Regards,

    Brijesh

  • how should i check that input is valod?

  • You could check in your fpga program.

     

    Rgds,

    Brijesh

  • Hi brijesh,

    Is there a way to make sure that input video from FPGA is valid for davinci ? We can't know what comes in capture because HW does not transfer it to driver.

    Regards,

    Ran

  • Hi brijesh, Is there a way to make sure that input video from FPGA is valid for davinci ? We can't know what comes in capture because HW does not transfer it to driver. Regards, Ran

  • Hi Ran,

    You will have to configure capture to receive data on 16 bit interface.

    1. In file \dvr_rdk\mcfw\src_bios6\links_m3vpss\capture\captureLink_drv.c
    2. Function CaptureLink_drvCreateInst (), before FVID2_create () ensure to set
    3. pVipCreateArgs->videoCaptureMode = VPS_CAPT_VIDEO_CAPTURE_MODE_SINGLE_CH_NON_MUX_EMBEDDED_SYNC
    4. pVipCreateArgs->videoIfMode = VPS_CAPT_VIDEO_IF_MODE_16BIT
    5. pVipCreateArgs->inDataFormat = FVID2_DF_YUV422P; /* Assuming YUV422 input data format. */
    5. Let the normal capture create continue.
    6. Read VIP registers output_port_a_src0_size. this register should tell you the detected height and width.
    7. If correct height and width is detected, capture should work as expected.
    8. If un-expected height / width is read, the video stream might not be correct.

    Thanks,
    Sujith

  • Hi Ran,

     

    Is this working fine for you now?

     

    Rgds,

    Brijesh

  • Hi Brijesh, Sujith,

    Sorry for not answering, I wasn't in office for couple of days.

    This works now fine with FPGA version which outputs 8-bits single channel. We checked both 8-bits ports for HW test of the connections. Now we intend to return to HD 16 bits test. I believe that the problem might be related to FPGA video in 16 bits. We also intend to check 4 D1 multiplex configuration.

    Regards,

    Ran