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.

DVR-RDK4.0 capture-display latency

We are using the DM8148 EVM with a VS daughter card & DVR-RDK 4.0. The application we want to have (as 1st stage)  is a basic capture & display with graphics overlay. The intention is to capture a single channel SD video, put graphic overlay (using FBDev) on the video frames & output the video-with-graphics to HDMI/analog display.

It's important to us to have this capability with minimal latency (60ms will be good)

I would like to ask the following please:
1. What is the best latency I should expect to see for this capture-> graphic overlay -> display implemetation ?
    Taking into account SD video input (e.g. NTSC), is a 60ms target feasible ?
2 .Assuming  that I use the McFW API (not the Link API), what is the recommended use-case to start from ?
    Currently, I'm starting with the capture-encode-decode-display DM8148 demo. I saw there is a capture-display
    demo only for the DM8168. It did not work for me (as expected) using the DM8148 board I have.

Thank you.

Sharon Golan

 


     

 

  • Sharon Golan said:
    1. What is the best latency I should expect to see for this capture-> graphic overlay -> display implemetation ?
        Taking into account SD video input (e.g. NTSC), is a 60ms target feasible ?

    - Capture driver works on polling mode and can add upto 8ms latency. Display driver will add 2 frame latency if configured to queue frames in ISR. Graphics overlay doenst add any latency. Achieving less than 60 ms latency is going to be difficult.  Are you going to deinterlace the fields or directly display without deinterlacing. SD display can support display of fields. What is your plan for HDMI ? Are you going to configure it for 1080i60 ? Even when doing field display driver will take both fields together so latency will be 2 frame duration .

     

    Sharon Golan said:
    2 .Assuming  that I use the McFW API (not the Link API), what is the recommended use-case to start from ?     Currently, I'm starting with the capture-encode-decode-display DM8148 demo. I saw there is a capture-display     demo only for the DM8168. It did not work for me (as expected) using the DM8148 board I have.

    - There is no ready made usecase to match your data flow. You can look at the multich_car_dvr usecase which is more complex but does atleast what you require and has a capture ->dei ->display path .

  • Thank you.

    What I did so far is the following:

    I started from the DM8148 capture-encode-decode-display 4D1 use-case & manipulated it to
    have the fillowing McFW components flow

     capture->dei->display

    The input is a PAL camera & the display is HDMI. The dei scales the input SD to have the 1080 output.
    Using this flow I see a preliminary (more accurate measurements will follow later on) glass-to-glass latency
    of ~190ms (about 4-5 PAL frames).

    I would like to try & configure interlace  HDMI display. Can you guide me where can I find a reference for such a configuration. I presume that is such a flow there is no need for DEI. In this context there is a scalar issue. In my
    original flow I used the DEI scalar to scale PAL  to HD. I guess that I want to leave the DEI out of the flow I should use another scaler, maybe the SwMs ? I'll appreceiate any guidance in this issue too.

    By the way, in my current flow I set the DEI to have 50Hz frame rate as input & as output. Is this correct ?any other setting that can help me in my current flow to minimize latency ?

    Thank you.

    Sharon

  • To reduce latency pls configure displayLink createParams.queueInISR = TRUE.

    Refer

    /dvr_rdk/mcfw/src_linux/mcfw_api/usecases/ti81xx/multich_car_dvr.c for example code.

     

    Sharon Golan said:
    I would like to try & configure interlace  HDMI display. Can you guide me where can I find a reference for such a configuration. I presume that is such a flow there is no need for DEI. In this context there is a scalar issue. In my original flow I used the DEI scalar to scale PAL  to HD. I guess that I want to leave the DEI out of the flow I should use another scaler, maybe the SwMs ? I'll appreceiate any guidance in this issue too.

    Is this a product requirement or are you doing this to measure and minimize latency. THis configuration is not tested on 814x and there would be some debug effort to get it functional.

    1. Configure the DEI for forceDEIBypass = TRUE and interlaceBypass = TRUE.

    2. Configure the displayLink displayRes to 1080i50

    3. Set displayLink fieldSeparatedMode = TRUE.

    Sharon Golan said:
    By the way, in my current flow I set the DEI to have 50Hz frame rate as input & as output. Is this correct ?any other setting that can help me in my current flow to minimize latency ?

    This setting is correct. but if you are displaying on 1080P60 display you would see frame repeats due to source  sink frame rate mismatch. Can you do the measurement with NTSC input for the purpose of  latency measurement.

     

  • Thanks Badri.

    Badri Narayanan said:

    To reduce latency pls configure displayLink createParams.queueInISR = TRUE.
    Refer
    /dvr_rdk/mcfw/src_linux/mcfw_api/usecases/ti81xx/multich_car_dvr.c for example code.

    I did that. At this stage with the not accurate latency measurement I use I don't see any improvement in latency. The numbers remain the same.

    Badri Narayanan said:

    Is this a product requirement or are you doing this to measure and minimize latency. THis configuration is not tested on 814x and there would be some debug effort to get it functional.

    It's not a product requirement. As you wrote it's just for measurement. I thought that this maybe can give us some clue about latency performance when we'll operate with 60Hz progressive input

    Badri Narayanan said:

    1. Configure the DEI for forceDEIBypass = TRUE and interlaceBypass = TRUE.
    2. Configure the displayLink displayRes to 1080i50
    3. Set displayLink fieldSeparatedMode = TRUE.

    I configured the capture for 1080i 50Hz and set the forcefieldSeparatedMode to TRUE. I see on the LCD screen a picture having half the height it should have. Seems like the fields are displayed in a raw one after the other. Maybe the screen don't know what to do with 1080i ?

    I'm trying now to have this flow (for more accurate latency measurement)

    Capture->display->analog-PAL-screen

    The settings of the capture remained the same. For the display I changed only 2 fields:
    - I changed the displayId to be SYSTEM_LINKID_DIAPLAY_2 .
    - And I also changed the resolution to be VSYS_STD_D1.

    With these settings the create-link operation of the Display is failed. The VPSS returns with assertion failure message. I'm still checking what is wrong here. I guess this will force me to add some printf directives in the VPSS code side in order to understand what the M3 code find to be wrong with the above setting.

    Thanks again.
    Sharon

  • Do you want to pursue debug of 1080i60 display issue ? If It is important to get 1080i60 working check if the changes mentioned in this thread help http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/223439/786638.aspx#786638

     

    For SD display your resolution should be VSYS_STD_PAL

  • Badri Narayanan said:

    For SD display your resolution should be VSYS_STD_PAL

    Actually I used VSYS_STD_PAL before and it did not work. same error message from the VPSS.

    Now, based on your input I tried  VSYS_STD_NTSC. And to my surprise there is no error during the creation of the display link and I have video on the analog display (via the composite output).

    There are 2  problems now:
    1. The input video is from a PAL camera and the DVR-RDK recognized it as such, So it is strange I had to
         to set NTSC in the display resolution to make it output video (  VSYS_STD_PAL causes assertion failure in
         VPSS).
    2. The video present true capture of the scene but has significant issues. It seems like the fields are in reverse
        order or maybe frames are lost. This is most noticeable when objects in the scenes change their vertical position.
        This causes an effect in the video like their are shaking. Given the configuration dissonance I have here (capture
        link "sees" PAL but display link set deliberatlly to NTSC) I am not surprise to have this issues. Now I need to      
        figure out how to configure the display the right way in order to have intact PAL output.

    Again my setup is just capture->display,  without de-interlacer bwteen.And the display is configured to have only
    the SD output to analog display.

    Thanks.

    sharon 

     

  • Pls attach your usecase file where you are creating and connecting links and the console logs from start of application run.

    Are you setting capturePrm.isPALMode = TRUE ?

    Also you should set capturePrm.numExtraBufs               = 8; because display driver may hold upto 6 fields and capture would start dropping fields due to lack of output buffers,

  • Hi Badri.
    Forcing "isPALMode" to TRUE doesn't change the picture. And same for "numExtraBufs".
    The code that sets this  capture->display usecase is here :

    #define VDIS_DEV_HDMI   0
    #define VDIS_DEV_SD       3
    #define VDIS_DEV VDIS_DEV_SD

     
    MULTICH_INIT_STRUCT(DisplayLink_CreateParams, displayPrm[VDIS_DEV]);
     
    MULTICH_INIT_STRUCT(DeiLink_CreateParams, deiPrm); 
     
    printf("\n***** Entered usecase 4CH <814x> capture-display *****\n\n"); 
     
    MultiCh_detectBoard(); 
     
    System_linkControl( SYSTEM_LINK_ID_M3VPSS , SYSTEM_M3VPSS_CMD_RESET_VIDEO_DEVICES , 
     NULL , 
     0 , 
     TRUE ); 
     
    vipInstId = 0; 
     
    gVcapModuleContext.captureId = SYSTEM_LINK_ID_CAPTURE; 
    gVdisModuleContext.displayId[0] = SYSTEM_LINK_ID_DISPLAY_2; //SD
    
    
    CaptureLink_CreateParams_Init(&capturePrm); 
     
    capturePrm.outQueParams[0].nextLink = gVdisModuleContext.displayId[0]; 
    capturePrm.numVipInst = 1;
    capturePrm.tilerEnable = FALSE;
    capturePrm.numBufsPerCh = NUM_CAPTURE_BUFFERS;
    capturePrm.maxBlindAreasPerCh = 4;
     
    pCaptureInstPrm = &capturePrm.vipInst[0];
    pCaptureInstPrm->vipInstId = (SYSTEM_CAPTURE_INST_VIP0_PORTA + vipInstId) % SYSTEM_CAPTURE_INST_MAX;
    pCaptureInstPrm->videoDecoderId = SYSTEM_DEVICE_VID_DEC_TVP5158_DRV;
    pCaptureInstPrm->inDataFormat = SYSTEM_DF_YUV422P;
    pCaptureInstPrm->standard = SYSTEM_STD_MUX_4CH_D1;
    pCaptureInstPrm->numOutput = 1;
     
    pCaptureOutPrm = &pCaptureInstPrm->outParams[0];
    pCaptureOutPrm->dataFormat = SYSTEM_DF_YUV422I_YUYV; 
    pCaptureOutPrm->scEnable = FALSE;
    pCaptureOutPrm->scOutWidth = 0; 
    pCaptureOutPrm->scOutHeight = 0; 
    pCaptureOutPrm->outQueId = 0; 
     
    //ADC
    vidDecVideoModeArgs[0].vipInstId = SYSTEM_CAPTURE_INST_VIP0_PORTA+i; 
    vidDecVideoModeArgs[0].deviceId = DEVICE_VID_DEC_TVP5158_DRV; 
    vidDecVideoModeArgs[0].numChInDevice = 4; 
    vidDecVideoModeArgs[0].modeParams.videoIfMode = DEVICE_CAPT_VIDEO_IF_MODE_8BIT; 
    vidDecVideoModeArgs[0].modeParams.videoDataFormat = SYSTEM_DF_YUV422P; 
    vidDecVideoModeArgs[0].modeParams.standard = SYSTEM_STD_MUX_4CH_D1; 
    vidDecVideoModeArgs[0].modeParams.videoCaptureMode = DEVICE_CAPT_VIDEO_CAPTURE_MODE_MULTI_CH_PIXEL_MUX_EMBEDDED_SYNC;
    vidDecVideoModeArgs[0].modeParams.videoSystem = DEVICE_VIDEO_DECODER_VIDEO_SYSTEM_AUTO_DETECT; 
    vidDecVideoModeArgs[0].modeParams.videoCropEnable = FALSE; 
    vidDecVideoModeArgs[0].modeParams.videoAutoDetectTimeout = -1; 
    Vcap_configVideoDecoder(vidDecVideoModeArgs, NUM_CAPTURE_DEVICES); 
     
    //forcing below capturePrm.isPalMode to be TRUE doesn't help 
    capturePrm.isPalMode = Vcap_isPalMode(); 
    if(capturePrm.isPalMode) 
     printf("\nVideo input std: PAL\n\n"); 
    else 
     printf("\nVideo input std: NTSC\n\n"); 
     
    System_linkCreate(gVcapModuleContext.captureId , &capturePrm, sizeof(capturePrm)); 
     
     
    displayPrm[VDIS_DEV].displayId = gVdisModuleContext.displayId[0];
    displayPrm[VDIS_DEV].inQueParams[0].prevLinkId = gVcapModuleContext.captureId;
    displayPrm[VDIS_DEV].inQueParams[0].prevLinkQueId = 0; 
    //setting below display res to VSYS_STD_NTSC brings to output video (although the 
    //video out is not good, the scene shakes or wraps around vertically)
    displayPrm[VDIS_DEV].displayRes = VSYS_STD_PAL; 
    displayPrm[VDIS_DEV].displayId = gVdisModuleContext.displayId[0]; 
    displayPrm[VDIS_DEV].forceFieldSeparatedInputMode = TRUE; 
    //increasing below que length number does not solve the issue
    displayPrm[VDIS_DEV].maxDriverQueLength = 2;
    displayPrm[VDIS_DEV].queueInISRFlag = TRUE; 
     
    System_linkCreate(gVdisModuleContext.displayId[0],  &displayPrm[VDIS_DEV],  sizeof(displayPrm[VDIS_DEV])); 
     
    And the shell output:
     
    Video input std: PAL
    
    
     [m3vpss ] 16076: CAPTURE: Create in progress !!!
     [m3vpss ] 16114: CAPTURE: VIP0 PortA capture mode is [ 8-bit, Pixel-mux Embedded Sync] !!! 
     [m3vpss ] UTILS: DMA: Allocated CH (TCC) = 58 (58)
     [m3vpss ] UTILS: DMA: 0 of 4: Allocated PaRAM = 58 (0x49004740)
     [m3vpss ] UTILS: DMA: 1 of 4: Allocated PaRAM = 64 (0x49004800)
     [m3vpss ] UTILS: DMA: 2 of 4: Allocated PaRAM = 65 (0x49004820)
     [m3vpss ] UTILS: DMA: 3 of 4: Allocated PaRAM = 66 (0x49004840)
     [m3vpss ] CAPTURE::HEAPID:0 USED:328
     [m3vpss ] CAPTURE::HEAPID:4 USED:17713152
     [m3vpss ] 16204: CAPTURE: Create Done !!!
     [m3vpss ] 23028: DISPLAY: Create in progress !!!
     [m3vpss ] 23028: DISPLAY: 44: Field Separate Mode ENABLED for Que 0 !!!
     [m3vpss ] 23030: Assertion @ Line: 941 in links_m3vpss/display/displayLink_drv.c: status == FVID2_SOK : failed !!!
    Thanks.
    sharon
  • displayPrm[VDIS_DEV].displayId should be DISPLAY_LINK_DISPLAY_AUTO_SELECT not gVdisModuleContext.displayId[0] although I don't think it is related to the issue you are seeing.

    What is the Vdis_params.resolution set before invoking Vdis_init ? Are you using your own app or are you running the mcfw api demo with only changing the usecase file. If you are running the mcfw api demo, change

    vdisParams.deviceParams[VDIS_DEV_SD].resolution     = VSYS_STD_NTSC;

    to

    vdisParams.deviceParams[VDIS_DEV_SD].resolution     = VSYS_STD_PAL;

    in /dvr_rdk/demos/mcfw_api_demos/mcfw_demo/demo_vcap_venc_vdec_vdis.c before invoking Vdis_init

     

     

    Are you using grpahics via fbdev in your app.Did insmod of fbdev driver succeed ? Pls share the console logs from kernel boot onwards to confirm this.

    Also pls confirm the following.

    Value of define NUM_CAPTURE_BUFFERS is 8.

    numExtraBufs was set to zero for the log shared above.