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.

DEI component in DM8148

Hi All,

We are using DM8148 based customized board in our product. 

We are using EZSDK 5_02 , HDVPSS (hdvpss_01_00_01_44), omx-ti81xx-src_05_02_00_48.

While running an application we have find that there is 3 to 4 buffer delay in DEI component when de-interlacing algorithm is on. 

We have verified it by putting timestamp on every buffer and printing it before EmptyBufferRequest of DEI and after FillBufferDone of DEI. 

We got prints like below:

Give buffer to DEI 125
Out buffer from DEI 122
Out buffer from DEI 122
Give buffer to DEI 126
Out buffer from DEI 123
Out buffer from DEI 123
Give buffer to DEI 127
Out buffer from DEI 124
Out buffer from DEI 124
Give buffer to DEI 128
Out buffer from DEI 125
Out buffer from DEI 125
Give buffer to DEI 129

We don't observed such delay in case of progressive input because algorithm is bypassed. 

What can be reason for this delay?

While going through datasheet I come to know that there is Motion Detection (MDT) feature which need 4 fields (4 Field Mode) to calculate final field value. Is that correct reason for such delay. 

If yes then I would like to know is it compulsory feature or we can disable it?

If we disable it what will be consequences. 

Any suggestion or pointers will be appreciated.

Thanks,

Jemish

  • That's correct, you could get few frame latency when DEI is doing deinterlacing. If you don't want to convert interlaced fields to progressive frames, you could disable this feature. There should some DEIBypass flag to bypass DEI fuctionality.. Set this to TRUE to bypass this functionality and get the single frame latency in DEI.

    Rgds,
    Brijesh
  • Hi Brijesh,

    Thanks for a quick response!
    I have already bypassed the DEI functionality and verified it there is not latency in that case. I have mentioned also.
    We want to do deinterlacing of interlaced input.

    But my question is weather the current delay we are getting is accepted or it is an issue?
    If my understanding regarding MDT (Motion Detection) feature is correct and delay is being introduced due to Motion Detection (4 Field Mode) algorithm can we disable it ? Or is there any alternative where we can use for deinterlacing.

    Basically I need confirmation from TI weather we must have to use Motion Detection feature(which is part of DEI) or do we have any alternative with less delay or no delay.

    Thanks,
    Jemish
  • Hello,

    4-field MDT is used in DEI_M.
    You could check vpscore_deiHal.c file.

    BR
    Margarita
  • Hi Margarita,

    I have checked that 4-field MDT is used in DEI_M.
    My question is do we have to use 4-field MDT compulsory?
    Or in very simple:
    If I want to deinterlace an interlaced video input and we don't need delay from DEI component which we are seeing now is it possible?

    Thanks,
    Jemish
  • There is a line merge mode in the DEI, but i am not sure if it can give any latency reduction. Give it a try.
    There is no way to reduce the latency for 4 field MDT dei mode.

    One question is, when you give input field, you get output frame, you will not get input field back for next two fields. But you still get the output frame, why is there issue in latency?

    Rgds,
    Brijesh
  • Hi Brijesh,

    First if I understand your question correctly you want to say that this latency is accepted behavior it not an issue. Please correct me if I am wrong.

    Regarding your suggestion:
    There are two different configuration structure for interpolation method and Motion detection field mode.

    typedef enum
    {
    VPS_DEIHQ_FLDMODE_4FLD = 1,
    /**< 4-field operation. */
    VPS_DEIHQ_FLDMODE_5FLD = 2,
    /**< 5-field operation. */
    VPS_DEIHQ_FLDMODE_MAX
    /**< Should be the last value of this enumeration.
    Will be used by driver for validating the input parameters. */
    } Vps_DeiHqFldMode;


    typedef enum
    {
    VPS_DEI_EDIMODE_LINE_AVG = 0,
    /**< Line average. */
    VPS_DEI_EDIMODE_FLD_AVG,
    /**< Field average. */
    VPS_DEI_EDIMODE_LUMA_ONLY,
    /**< EDI for Luma only. */
    VPS_DEI_EDIMODE_LUMA_CHROMA,
    /**< EDI for Luma and Chroma. */
    VPS_DEI_EDIMODE_MAX
    /**< Should be the last value of this enumeration.
    Will be used by driver for validating the input parameters. */
    } Vps_DeiEdiMode;

    So I don't think it will reduce delay.
    My question is weather MDT (Motion Detection) an integral part of DEI component in case of DEI algorithm enabled?
    If it is the case that's fine. We just need confirmation from TI that our understanding regarding current introduced latency is right and it is because of MDT (Motion Detection) which can not be removed.

    Thanks,
    Jemish
  • Hi Jemish,

    These two are different things, you will have to go through TRM to understand it.
    I was talking about the EDI mode to Line average mode. it may reduce latency, but will not provide good quality output.
    if you want good quality output, you will have to use Luma_chroma mode with 4Fld mode and with this mode, driver keeps few field with itself. I dont consider as the latency as you still get the output when you submit input field.. it does not get delayed.

    How do you measure this latency?

    Rgds,
    Brijesh
  • Hi Brijesh,

    Sorry for misinterpretation created by me regarding DEI latency/delay. I apologize for that . I asked wrong question.

    I actually want to ask why DEI buffer always hold four buffers (which I mistakenly interpret as delay )?
    It always hold four buffer in case of interlaced input and dei algorithm enabled.
    After that I go through the datasheet and doubt on MDT(Motion detection Algorithm) so I asked you question regarding that.

    As per your suggestion I also try with "Line Number Average" algorithm. But it doesn't reduce number buffer hold by DEI.
    So it is necessary that DEI always hold four buffers for interlace input can we reduce the number of buffers hold by it?

    Thanks,
    Jemish