← Back to team overview

tiomap-dev team mailing list archive

[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