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