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.

Interlaced capture using the "capture_encode" OpenMax test application

Hi,

we are attempting to modify the "capture_encode" openMax example to capture and encode an interlaced video.

So far, it seems the odd and even images are each resized separately, giving an effect of "shaking" video.

So our question is: how do we configure the DEIMDUALOUT module so that it deinterlaces video instead of rescaling it?

The member bAlgBypass in OMX_CONFIG_ALG_ENABLE structure seems to have an effect: we find a deinterlaced image in between the resized images. But the video is still a mix between resized images and interlaced images, not what we would expect.

The OpenMax user guide does not give us any clue, nor the OpenMax examples.

Thanks in advance.

  • It sounds like the OMX module, either rescale or deinterlaced, is it correct?

    Initial feedback is that there is no native documentation on that specific topic yet

    Suggestion :

    - understand the program flow of the module through buffer and add more log the VPSS configuration

    - if you disable scaling does deinterlacing works? subsample fps parameter could be set wrong.

     

  • O'Mellin said:

    It sounds like the OMX module, either rescale or deinterlaced, is it correct?

    Yes, exactly.

    O'Mellin said:

    Initial feedback is that there is no native documentation on that specific topic yet

    Suggestion :

    - understand the program flow of the module through buffer and add more log the VPSS configuration

    - if you disable scaling does deinterlacing works? subsample fps parameter could be set wrong.

     Actualy, I have two solutions:

    - either I set sHwPortParam.eScanType = OMX_VIDEO_CaptureScanTypeProgressive

    in omx-ti81xx-src_05_02_00_30/examples/ti/omx/demos/capture_encode/src/ilclient_utils.c, line 984, and the effects are as I have described in my previous post (DEI seems to alternatively rescale and deinterlace).

    Or I set sHwPortParam.eScanType = OMX_VIDEO_CaptureScanTypeInterlaced and the effect are different. The resulting image has even lines correct and odd lines contain random noise. I have tried, in this second case to bypass completely the DEI module, and look at the pictures directly out of the capture, and they are already incorrect. So, from what I understand, the capture component already tries to do some deinterlacing (but fails). It looks confirmed by the code in file HDVPSS_01_00_01_33/packages/ti/psp/vps/drivers/capture/src/vpsdrv_captureList.c line 847 which sets the "line skip" parameter of the VPMA descriptor to 2 lines, in the case when the source is interlaced. So, it looks to me like the DMA for the top interlaced field is done correctly, but the DMA for the bottom interlaced field, for the same buffer is not done. I read the VPDMA documentation, the "line skip" parameter is documented, but I have not understood the details on how an interlaced capture should be done, and in particular, how to indicate to the VPDMA to use the same buffer for the top and bottom fields. There is a "field id" parameter in the VPDMA descriptor structure, the documentation says to put 0 for that parameter in case of interlaced capture, but then I have trouble to understand what is the difference between a capture of the even field, or a capture of both fields using the 2 lines skip trick.

    I am convinced the second solution is the way to go, as the source really is interlaced, so the scan type should be set to interlaced, but I will give the subsampling parameter a shot in that case anyway. Thanks for your answer.

  • If may i add to this thread, currently OMX examples (capture_encode) support only 1080p, 720p and 480p video formats. It will be helpful for TI users, if TI will arrange support and examples for capture of more useful video formats such as 1080i, 576p, 576i, 480i, VGA,XGA,SXGA, UXGA.

    Thanks,
    Gabi 

  • Hi,

    1080i60 should work with below changes -

    1. Height for capture o/p and DEI input would be half of app->height and corresponding buffer sizes also.

    2. Change scan type to TypeInterlaced instead of TypeProgressive.

    3. Change video standard to 1080I60 instead of P60.

    4. in DEI algbypass flag should be set to 0.

    Let me know what error / issue  you see with above changes.

    Also please check while booting your board prints TI8168-GP rev 1.1 or TI8168-GP rev 2.0 ? 

    Regards

    Vimal

  • Vimal Jain said:

    Hi,

    1080i60 should work with below changes -

    1. Height for capture o/p and DEI input would be half of app->height and corresponding buffer sizes also.

    2. Change scan type to TypeInterlaced instead of TypeProgressive.

    3. Change video standard to 1080I60 instead of P60.

    4. in DEI algbypass flag should be set to 0.

    Let me know what error / issue  you see with above changes.

    This is what I did. What issues I see is described in my previous post. The buffer even lines are correct, the buffer odd lines are not. I can show you the corresponding .h264 file if you are interested.

    Vimal Jain said:

    Also please check while booting your board prints TI8168-GP rev 1.1 or TI8168-GP rev 2.0 ? 

    I am running a TI8148 rev 2.1.

    Regards.

  • Gilles Chanteperdrix said:

    This is what I did. What issues I see is described in my previous post. The buffer even lines are correct, the buffer odd lines are not. I can show you the corresponding .h264 file if you are interested.

    Hello,

    in case anybody cares, the "line skip" parameter of the capture DMA was indeed the culprit, setting this parameter to 1 line instead of 2 for interlaced capture lets the DEI do the deinterlacing, and the capture_encode works with interlaced source.

    The file to change is:

    HDVPSS_01_00_01_33/packages/ti/psp/vps/drivers/capture/src/vpsdrv_captureList.c

    The culprit snippet is around line 845:

            if ((FVID2_BUF_FMT_FRAME == pChObj->frameCapture) &&
                (TRUE == pChObj->fieldsMerged))
            {
                dataDescInfo.lineSkip = VPSHAL_VPDMA_LS_2;
            }
            else
            {
                dataDescInfo.lineSkip = VPSHAL_VPDMA_LS_1;
            }

    This should be changed to:

    dataDescInfo.lineSkip = VPSHAL_VPDMA_LS_1;

  • Did you try the fix which worked for me?

  • I'm sorry for late replying.

    Do you mean the fix in vpsdrv_captureList.c?

    The EZSDK I use is ezsdk_5_03_01_15.I can't find the file named vpsdrv_captureList.c.

    Thanks.

  • We are also facing similar problem when trying to do HDMI 1080i input capture on DM8168. The capture-encode demo code present in ezsdk_5_03_01_15 has been modified to just use the capture OMX component. The captured output is showing only one field correct and the other field being garbage.

    We are not using DEI or any other OMX component and are trying to display/file-dump the output of capture component.

    It would be useful if we could get the  IL_ClientSetCaptureParams function of some demo code where 1080i HDMI capture works

    Thanks

  • Hi,

    If you try 420SP capture, It should work for 1080i60. For 422 capture, software has issues where odd filed is not proper.

    Regards

    Vimal