tiomap-dev team mailing list archive
-
tiomap-dev team
-
Mailing list archive
-
Message #01438
[Bug 974264] [NEW] DOMX H264 decoder fails, H264 encoder hangs randomly
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
Follow ups
References