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

Mpeg4, OMX and GStreamer

Bruno Marchand
Prodigy 150 points

Hi,

I'm using GStreamer on the DM8168 to stream mpeg4 using rtp.  The GStreamer plugin I use to interface with openmax is an "in house" adaptation of gst-openmax.  Excepted for a few parameters, the same plugin code is used to encode in h264 or mpeg4. The GStreamer version used is an unmodified 0.10.35.

When I want to stream a still image, the mpeg4 codec seems to hang after a few frames (around 8).  The codec doesn't free the omx buffers sent to its input (OMX_CALLBACKTYPE.EmptyBufferDone).  When the codec is halted, it suddenly frees the 4 buffers.

An example pipeline is the following:

gst-launch videotestsrc pattern=snow ! imagefreeze ! omxmpeg4enc ! rtpmp4vpay ! udpsink   -->freeze

The same pipeline without the imagefreeze component or when used with h264 won't freeze:

gst-launch videotestsrc pattern=snow  ! omxmpeg4enc ! rtpmp4vpay ! udpsink  --> work

gst-launch videotestsrc pattern=snow ! imagefreeze ! omxh264enc ! rtph264pay ! udpsink  --> work

Does this problem occurs with the ti-version of the codec?  Do you have any suggestion to solve this issue?

Thanks

  • 0
    Prodigy 150 points

    Hi,

    Some update about this issue.  Yesterday I fetched the latest version of GStreamer-TI from https://gstreamer.ti.com/svn/gstreamer_ti/trunk/gstreamer_ti_dm81xx.  The current version (r983) compile against EZSDK 5.02 and do not include mpeg4 encoder.  With some slight modifications, I made it compile with the latest EZSDK 5.03.15.1 and enabled mpeg4 encoder.  After a few tests, I observed the same behaviour as with the "in-house" integration :  the codec freeze when feed with a still image.

    As an additional note, the issue is also present with SDK 5.03.00.09.

    gst-launch videotestsrc num-buffers=100 pattern=black ! omx_mpeg4enc ! video/mpeg,mpegversion=4,systemstream=false ! rtpmp4vpay  <-- freeze

    gst-launch videotestsrc num-buffers=100 pattern=blue ! omx_mpeg4enc ! video/mpeg,mpegversion=4,systemstream=false ! rtpmp4vpay  <-- freeze

    gst-launch videotestsrc num-buffers=100 pattern=snow ! omx_mpeg4enc ! video/mpeg,mpegversion=4,systemstream=false ! rtpmp4vpay  <-- works

    I think this indicates the issue is located in the mpeg4 implementation of the encoder.  Do you have any information about this issue or a workaround?

    Thanks.

  • 0 in reply to Bruno Marchand
    TI__Intellectual 755 points

    We have not yet worked on the gstreamer element for MPEG-4 encoder so its difficult to say whether the issue is there is MPEG-4 encoder element implementation or not. But here is some info that might help: the gstreamer encoder element needs pass on a contiguous video buffer to OMX encoder,  if the upstream element (videotestsrc / imagefreeze in this case) doesn't pass a contiguous buffer, then encoder element needs to copy the video data into OMX allocated buffer. Just wondering if this logic is there in MPEG-4 encoder element code.

    Thanks,

    Satish   

  • 0 in reply to Satish Arora
    Prodigy 150 points

    Hi Satish,

    Thank you for your anwser.

    I am already aware of the OMX buffers that needs to be allocated and used to transfer data with HDVICP2 encoders.  The Gstreamer component even implement a "sink buffer alloc" so component like videotestsrc directly render in OMX allocated memory.  Also, the h.264 Gstreamer component works flawlessly and shares all the buffer related code with the mpeg4 component, the only difference being the output port definition.

    I would like to bring attention to the fact the with moving picture, the component works properly.  The only case that make it freeze is software generated still picture.  I specify "software generated" because a still picture captured through the video ADC contains noise and is not completely still.  Finally, the component is not completely frozen. It doesn't free the input buffers and do not produce any output buffers but it will return to idle state when asked to.

    I hope this will help you look into this issue.

    Thanks.

  • 0 in reply to Bruno Marchand
    Prodigy 150 points

    Hello Everyone!

    It has been a long time now since I asked that question.  Is anyone looking into this?  I guess the question would be the same even if we remove GStreamer from the loop. 

    Regards,

    Bruno