[Bug 774654] Flushing can hang if output port queue of pending buffers is empty

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=774654

--- Comment #10 from minfrin at sharp.fm ---
I got some information back from the RPi people at
https://github.com/raspberrypi/firmware/issues/686 as follows:

> video_decode:3:RIL:resolution changing is the codec reports that
> the stream has changed format, ie there was a new set of header
> bytes in the stream. The codec processing will stop until you
> disable the output port and reconfigure it for the new
> resolution/format as buffers need reallocating.

> waiting for a cb structure means that you have fed in the maximum
> number of frames to the input FIFO and it is refusing to take any
> more, normally because you aren't draining the output (because you
> haven't dealt with the resolution change). There are 32 callback
> structures allocated which more than covers most normal situations.

The hang is happening in gstomxh264dec.

What seems to be happening in my case is that the graphics card is noticing
that the resolution has changed, logged as follows:

222754.226: video_decode:3:RIL:resolution changing

What is supposed to happen is that gst-omx drains the port, then reconfigures
the port, and only then will further packets be processed by the graphics card.

What appears to be happening is that gst-omx drains the port, but then never
reconfigures the port. The graphics card buffers get full, and then hang. The
whole pipeline is hung at this point.

Does gst-omx support dynamic resolution changes?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.