OMX H264 decoder stream change

[Samuel Hurst]

Hi All,


I'm currently writing a small application to demonstrate DASH channel
changes, and in doing so I've come across something strange with the OMX
hardware decoder element.

I've written an application that takes a list of MPDs and then allows a
user to select which one to play back. When a user wants to change the
channel, I do the following:

* Set the whole pipeline to READY
* Unlink, destroy and create new souphttpsrc and dashdemux elements
* Relink the new elements with a new MPD
* Sync all the child elements of the pipeline to the READY state, and
* Set the pipeline to PLAYING.

On my PC this works fine, the video pauses while the stream changes and
then begins playback on the new stream without any interruption to the
display. However, on a Raspberry Pi (standing in as a noddy set top box
client), the playback doesn't start up after a channel change and the
whole pipeline is stuck in the PAUSED state while the GstGLImageSinkBin
waits for an Asynchronous state change to complete.

Tracing it back, it seems that the GstOMXH264Dec element isn't passing
buffers down to the elements beneath it, so the GstGLImageSink can't
resolve the Asynchronous state change. This is because when it restarts,
it fails when setting itself up as the egl_render port is set as
"flushing", presumably a consequence of the end of the first stream.
I've attached an excerpt of the log when it's restarting that shows this.

In order to fix this, I'm having to also unlink, delete and recreate the
OMX decoder at the same time as removing the DASH elements. Is this
expected, and it's just a happy coincidence that the VA-API decoder on
my PC survives such a pipeline change? Or is this a potential bug in the
OMX decoder?

For reference, I'm using GStreamer 1.12.1 in both cases. My PC is
running Ubuntu 16.04 with the 4.8.0 HWE kernel with VA-API version 0.39
with Intel i965 driver version 1.7.0. The Pi is a Pi 2 running a custom
Buildroot 2017.05 image and a 4.9 kernel with rpi-userland version 4b24a81a.


Thanks in advance,
-Sam

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Julien Isorce]

Is it same as https://bugzilla.gnome.org/show_bug.cgi?id=767499 ?

There are potential fixes here: https://git.collabora.com/cgit/raspberry-pi/gst-omx.git/log/?h=rpi-1.0.0.1

"omxvideodec: fix deadlock when flush on EOS"

"omxvideodec: Do not try to acquire buffer when flushing"

You might need also a few commits in between.

Also could be related to https://bugzilla.gnome.org/show_bug.cgi?id=759043

If it does not help, you might need to check if glimagesink is still releasing all its ref to buffers in GST_QUERY_DRAIN .

On 10 July 2017 at 18:00, Samuel Hurst <[hidden email]> wrote:

Hi All,


I'm currently writing a small application to demonstrate DASH channel
changes, and in doing so I've come across something strange with the OMX
hardware decoder element.

I've written an application that takes a list of MPDs and then allows a
user to select which one to play back. When a user wants to change the
channel, I do the following:

* Set the whole pipeline to READY
* Unlink, destroy and create new souphttpsrc and dashdemux elements
* Relink the new elements with a new MPD
* Sync all the child elements of the pipeline to the READY state, and
* Set the pipeline to PLAYING.

On my PC this works fine, the video pauses while the stream changes and
then begins playback on the new stream without any interruption to the
display. However, on a Raspberry Pi (standing in as a noddy set top box
client), the playback doesn't start up after a channel change and the
whole pipeline is stuck in the PAUSED state while the GstGLImageSinkBin
waits for an Asynchronous state change to complete.

Tracing it back, it seems that the GstOMXH264Dec element isn't passing
buffers down to the elements beneath it, so the GstGLImageSink can't
resolve the Asynchronous state change. This is because when it restarts,
it fails when setting itself up as the egl_render port is set as
"flushing", presumably a consequence of the end of the first stream.
I've attached an excerpt of the log when it's restarting that shows this.

In order to fix this, I'm having to also unlink, delete and recreate the
OMX decoder at the same time as removing the DASH elements. Is this
expected, and it's just a happy coincidence that the VA-API decoder on
my PC survives such a pipeline change? Or is this a potential bug in the
OMX decoder?

For reference, I'm using GStreamer 1.12.1 in both cases. My PC is
running Ubuntu 16.04 with the 4.8.0 HWE kernel with VA-API version 0.39
with Intel i965 driver version 1.7.0. The Pi is a Pi 2 running a custom
Buildroot 2017.05 image and a 4.9 kernel with rpi-userland version 4b24a81a.


Thanks in advance,
-Sam

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel