[Bug 752376] New: MPEG-DASH stream causes omxh264dec deadlock

[GStreamer (GNOME Bugzilla)]

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.