[Bug 752376] New: MPEG-DASH stream causes omxh264dec deadlock
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Jul 14 07:34:42 PDT 2015
https://bugzilla.gnome.org/show_bug.cgi?id=752376
Bug ID: 752376
Summary: MPEG-DASH stream causes omxh264dec deadlock
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: major
Priority: Normal
Component: gst-omx
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: samuelh at rd.bbc.co.uk
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created attachment 307412
--> https://bugzilla.gnome.org/attachment.cgi?id=307412&action=edit
Tarball of debug output showing omx deadlock.
Hi,
I've hit a problem in gst-omx that causes issues when playing back adaptive
bitrate MPEG-DASH streams on a Raspberry Pi (2). When GStreamer attempts to do
a representation change, the omx decoder attempts to flush buffers in order to
reconfigure the decoder for the resolution change.
However, it always times out waiting for that to happen, and so the pipeline
fails. So far I've only tested this on a Raspberry Pi, so I don't know if this
is a problem specific to the Pi as it's the only device I use that requires
gst-omx.
You should be able to reproduce this behaviour with the following:
gst-launch-1.0 playbin
uri=http://rdmedia.bbc.co.uk/dash/ondemand/bbb/2/client_manifest-common_init.mpd
At present, I'm running GStreamer Core/Plugins-Base/Good/Bad at version 1.4.5,
and gst-omx is git latest. The OpenMAX support is provided by rpi-userland,
which is at git version b864074d. I'm building GStreamer via buildroot
(2015.08-git-00654-g5284dcf-dirty).
A quick canter through the bugzilla list indicates that there have been similar
problems with this in the past, but as I'm running git latest I'd have assumed
that they'd all be fixed by now. Indeed, all the fixes seem to be present in
git. (e.g. #710948, #726107,
I will attach a log I've produced with omx:9 and omxvideodec:9 debugging, which
seems to show the decoder deciding it needs to change, so sends the message
"0:00:09.714889582 [...] <omxh264dec-omxh264dec0> Waiting for video_decode port
131 to release all buffers"
But then when the decoder attempts to release a buffer, it says that the port
is flushing or disabled, and so doesn't release the buffer.
"0:00:09.750420143 [...] <omxh264dec-omxh264dec0> Releasing buffer 0xe92218
(0xf79750) to video_decode port 131
0:00:09.750522434 [...] <omxh264dec-omxh264dec0> video_decode port 131 is
flushing or disabled, not releasing buffer"
This seems like a bit of a deadlock to me. Looking at the debug dot file, the
omx decoder module isn't showing as flushing (no upper case F), but is showing
as the task being paused. I'll attach the files for these too.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list