Public bug reported: The DOMX H264 decoder and encoder fail/misbehave on Ubuntu 11.10 Desktop with all the OMAP4 extras installed, on a Pandaboard ES rev B1 (while the DCE decoder and encoder seem to work just fine).
The issues can be reproduced with the following gstreamer pipeline: gst-launch filesrc location=test-320x170.mp4 ! qtdemux name=demux demux.video_00 ! h264parse ! omx_h264dec ! ffmpegcolorspace ! fakesink The test input file can be fetched at http://albin.abo.fi/~mstorsjo /test-320x170.mp4, plain 320x170 H264 baseline. This pipeline fails with the following messages: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... omx_proxy_common.c:806 PROXY_AllocateBuffer() ERROR: Returning error, eError = 0x80001018 ** (gst-launch-0.10:1243): CRITICAL **: g_omx_port_allocate_buffers: assertion `port->buffers[i]' failed omx_proxy_common.c:989 PROXY_UseBuffer() ERROR: Returning error, eError = 0x80001018 omx_proxy_common.c:1041 PROXY_UseBuffer() ERROR: Error in UseBuffer return value, freeing buffer header ** (gst-launch-0.10:1243): CRITICAL **: g_omx_port_allocate_buffers: assertion `port->buffers[i]' failed ERROR: from element /GstPipeline:pipeline0/GstOmxH264Dec:omxh264dec0: GStreamer encountered a general stream error. Additional debug info: gstomx_base_filter.c(621): pad_chain (): /GstPipeline:pipeline0/GstOmxH264Dec:omxh264dec0: Error from OpenMAX component ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... If I replace omx_h264dec with ducatih264dec, the pipeline works fine. Similarly, I test the DOMX H264 encoder with this gstreamer pipeline: gst-launch videotestsrc ! video/x-raw-yuv, width=320, height=240 ! omx_h264enc ! h264parse ! mp4mux ! filesink location=out.mp4 This pipeline starts properly, but hangs soon (often before anything has been written to the output file). Likewise, if I replace omx_h264enc with ducatih264enc, it works fine. I do know that DCE is the preferred interface, but the DOMX interface doesn't seem to be useful at all. These test cases can be reproduced using the gst-openmax elements, but other OMX client applications fail in similar ways (OMX_AllocateBuffer failing for the second buffer for the decoder, or just hanging within a few seconds for the encoder), where the same OMX client applications work just fine with the TI DOMX components available on Android. ** Affects: ubuntu-omap4-extras-multimedia Importance: Undecided Status: New ** Tags: dce domx gstreamer omx openmax -- You received this bug notification because you are a member of TI OMAP Developers, which is subscribed to ubuntu-omap4-extras-multimedia. https://bugs.launchpad.net/bugs/974264 Title: DOMX H264 decoder fails, H264 encoder hangs randomly Status in OMAP4 Ubuntu Multimedia addons: New Bug description: The DOMX H264 decoder and encoder fail/misbehave on Ubuntu 11.10 Desktop with all the OMAP4 extras installed, on a Pandaboard ES rev B1 (while the DCE decoder and encoder seem to work just fine). The issues can be reproduced with the following gstreamer pipeline: gst-launch filesrc location=test-320x170.mp4 ! qtdemux name=demux demux.video_00 ! h264parse ! omx_h264dec ! ffmpegcolorspace ! fakesink The test input file can be fetched at http://albin.abo.fi/~mstorsjo /test-320x170.mp4, plain 320x170 H264 baseline. This pipeline fails with the following messages: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... omx_proxy_common.c:806 PROXY_AllocateBuffer() ERROR: Returning error, eError = 0x80001018 ** (gst-launch-0.10:1243): CRITICAL **: g_omx_port_allocate_buffers: assertion `port->buffers[i]' failed omx_proxy_common.c:989 PROXY_UseBuffer() ERROR: Returning error, eError = 0x80001018 omx_proxy_common.c:1041 PROXY_UseBuffer() ERROR: Error in UseBuffer return value, freeing buffer header ** (gst-launch-0.10:1243): CRITICAL **: g_omx_port_allocate_buffers: assertion `port->buffers[i]' failed ERROR: from element /GstPipeline:pipeline0/GstOmxH264Dec:omxh264dec0: GStreamer encountered a general stream error. Additional debug info: gstomx_base_filter.c(621): pad_chain (): /GstPipeline:pipeline0/GstOmxH264Dec:omxh264dec0: Error from OpenMAX component ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... If I replace omx_h264dec with ducatih264dec, the pipeline works fine. Similarly, I test the DOMX H264 encoder with this gstreamer pipeline: gst-launch videotestsrc ! video/x-raw-yuv, width=320, height=240 ! omx_h264enc ! h264parse ! mp4mux ! filesink location=out.mp4 This pipeline starts properly, but hangs soon (often before anything has been written to the output file). Likewise, if I replace omx_h264enc with ducatih264enc, it works fine. I do know that DCE is the preferred interface, but the DOMX interface doesn't seem to be useful at all. These test cases can be reproduced using the gst-openmax elements, but other OMX client applications fail in similar ways (OMX_AllocateBuffer failing for the second buffer for the decoder, or just hanging within a few seconds for the encoder), where the same OMX client applications work just fine with the TI DOMX components available on Android. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-omap4-extras-multimedia/+bug/974264/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~tiomap-dev Post to : tiomap-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~tiomap-dev More help : https://help.launchpad.net/ListHelp
