OMX H264 decoder stream change

Samuel Hurst samuelh at rd.bbc.co.uk
Mon Jul 10 17:00:50 UTC 2017


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
-------------- next part --------------
0:00:16.279168350   942 0x761b5690 DEBUG            omxvideodec gstomxvideodec.c:2182:gst_omx_video_dec_handle_frame:<omxh264dec> Starting task
0:00:16.279455641   942 0x761b5690 DEBUG                    omx gstomx.c:1250:gst_omx_port_acquire_buffer:<omxh264dec> Acquiring video_decode buffer from port 130
0:00:16.279590849   942 0x761b5690 DEBUG                    omx gstomx.c:1372:gst_omx_port_acquire_buffer:<omxh264dec> video_decode port 130 has pending buffers
0:00:16.279612307   942 0x6f5183b0 DEBUG                    omx gstomx.c:1250:gst_omx_port_acquire_buffer:<omxh264dec> Acquiring egl_render buffer from port 221
0:00:16.279707359   942 0x761b5690 DEBUG                    omx gstomx.c:1386:gst_omx_port_acquire_buffer:<omxh264dec> Acquired buffer 0x70701b30 (0x65e18c10) from video_decode port 130: 0
0:00:16.279778036   942 0x6f5183b0 DEBUG                    omx gstomx.c:1271:gst_omx_port_acquire_buffer:<omxh264dec> Component egl_render port 221 is flushing
0:00:16.279816318   942 0x761b5690 DEBUG            omxvideodec gstomxvideodec.c:2327:gst_omx_video_dec_handle_frame:<omxh264dec> Passing frame offset 0 to the component
0:00:16.279890276   942 0x6f5183b0 DEBUG                    omx gstomx.c:1386:gst_omx_port_acquire_buffer:<omxh264dec> Acquired buffer (nil) ((nil)) from egl_render port 221: 1
0:00:16.280004807   942 0x6f5183b0 DEBUG            omxvideodec gstomxvideodec.c:1537:gst_omx_video_dec_loop:<omxh264dec> Flushing -- stopping task
0:00:16.280073765   942 0x761b5690 DEBUG                    omx gstomx.c:1408:gst_omx_port_release_buffer:<omxh264dec> Releasing buffer 0x70701b30 (0x65e18c10) to video_decode port 130
0:00:16.281707097   942 0x761b5690 DEBUG                    omx gstomx.c:1454:gst_omx_port_release_buffer:<omxh264dec> Released buffer 0x70701b30 to video_decode port 130: None (0x00000000)
0:00:16.281842878   942 0x761b5690 DEBUG            omxvideodec gstomxvideodec.c:2374:gst_omx_video_dec_handle_frame:<omxh264dec> Passed frame to component
0:00:16.281930222   942 0x761b5690 DEBUG           videodecoder gstvideodecoder.c:3412:gst_video_decoder_decode_frame:<omxh264dec> flow error flushing

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170710/070227c5/attachment.sig>


More information about the gstreamer-devel mailing list