OMX H264 decoder stream change

[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
<https://git.collabora.com/cgit/raspberry-pi/gst-omx.git/commit/?h=rpi-1.0.0.1&id=ec7fe344c9d65eafa10b554e0a1a69e0fe58570a>
"
"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 <samuelh at rd.bbc.co.uk> 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
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170711/377d9313/attachment.html>