• State Answer Suggested
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1242 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.

Linux/DRA746: How to drain video decoding instead of flush?

Halley Zhao
Intellectual 560 points
Part Number: DRA746


Tool/software: Linux

I feed 200 compressed frame data (parsed by ffmpeg), then issus XDM_FLUSH command; finally I got 184 decoded video frame.

seems the frames in dpb are discarded.

I also noticed that, after issued XDM_FLUSH, I called VIDDEC3_process() but just got one output frame with err == IH264VDEC_ERR_STREAM_END.

  • 0
    TI__Guru**** 161600 points
    I've notified the automotive team. Their feedback will be posted here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Mastermind 42515 points
    Hi Halley,

    which SDK you use?

    Regards,
    Yordan
  • 0 in reply to Yordan Kamenov
    Intellectual 560 points

     I use git://git.omapzoom.org/repo/libdce.git directly.

    the product is Alibaba YunOS car, it uses GStreamer before. but now, I uses YunOS original multimedia framework instead. 

    my media framework is similar to GStreamer, but implemented through C++ and simplified to remove some tedious negotiation process.

  • 0
    Mastermind 8775 points

    Hi Halley,

    When the bitstream ends, application needs to do a XDM_FLUSH control command. Once after Flush is called, application need to call the process function in do-while loop, until you see the error IH264VDEC_ERR_STREAM_END.

    So, if we take your example, once after bitstream ends application has to do XDM_FLUSH followed by process call in do-while loop for 16 times. For 16th process call you should see this error and you would have got all the buffers held by codec.

    These process calls after XDM_FLUSH are to drain/free all the buffer's locked/held by the codec. When the last buffer is release codec will return err IH264VDEC_ERR_STREAM_END.

    Please refer viddec3test.c, how the XDM_FLUSH is done. (https://git.ti.com/glsdk/omapdrmtest/blobs/master/viddec3test.c )

    Halley Zhao said:
    I also noticed that, after issued XDM_FLUSH, I called VIDDEC3_process() but just got one output frame with err == IH264VDEC_ERR_STREAM_END.

    this is not the expected behaviour.