• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 762 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.

DVSDK v4.03.00.06 : loss of the first several decoded video frames

Sergey Matyukevich
Intellectual 340 points
Other Parts Discussed in Thread: DM3730

Hello,

We are using DVSDK v4.03.00.06 with the custom hardware platform based on DM3730. In our tests both the MPEG4 and H264 DVSDK decoders return fewer decoded frames than actual amount of frames in video files. According to our investigation, in most such cases DVSDK decoder does not return the first several frames. More specifically, in terms of DMAI Vdec2 API, the Vdec2_process() function reports successful decoding, however the Vdec2_getDisplayBuf() function does not return any decoded frames. The number of skipped frames usually ranges from 1 to 10.

DVSDK errata doesn't seem to mention such an issue.

Could you please provide any comments/suggestions why it may happen ?

Thanks,
Sergey

  • 0
    TI__Guru* 80190 points
    Hello,

    My understanding is that you are using decode_display demo, correct?

    If yes, could you try only to decode without the display part and check are you will observe the same behaviour.

    Are you using a default demos in DVSDK?

    Best Regards,
    Margarita
  • 0 in reply to Margarita Gashova
    Intellectual 340 points

    Hello,

    We are using DVSDK as a part of Android Rowboat project: DVSDK is integrated into Android Stagefright multimedia framework to provide hardware acceleration for video decoding. There is no display part in this code: it is a glue layer between Android framework and DVSDK. Infrastructure in use is quite complicated (e.g. see omx-dsp-video.cpp at gitorious.org/rowboat/hardware-ti-omx). But core processing part is actually the same as in DMAI VDEC2 video decode example.

    Thanks,
    Sergey

  • 0 in reply to Sergey Matyukevich
    TI__Guru* 80190 points
    Hello,

    Have you tried only to decode without a display element. Just feed the decoder with elementary stream on the output you will have a yuv in NV12 format. Let me know in this case are you will observe the same behaviour. I have doubts that the problem is in H264 and MPEG4 decoders.

    Best Regards,
    Margarita
  • 0 in reply to Margarita Gashova
    Intellectual 340 points
    Hello,

    Could you please clarify what do you mean by 'decode w/o a display element' ?

    Actually we do not display any frames. Rowboat DVSDK glue code is implemented in the form of OMX decoding plugin. All the decoded frames are passed upstairs where Android stagefright framework makes use of them. Note that Rowboat DVSDK glue code contains quite a few bells and whistles related to OpenCORE OMX, but at the bottom line it boils down to cycle with Vdec2_process/Vdec2_getDisplayBuf functions. So in our tests we observed that Vdec2_process worked fine and didn't reported any issues, but Vdec2_getDisplayBuf didn't return several first decoded frames in some cases.

    We observed this kind of behavior on a reasonably wide selection of movie snippets. In most part of our tests a small number of starting frames was missed. Roughly speaking, it looked like DVSDK decoding engine needed some time 'to warm up'.

    Thanks,
    Sergey