mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-27 20:21:24 +00:00
78e2264544
Imagine the following 'pipeline' -------------- p1/| 'fullqueue' |--- 'laggy' downstream --------- / | | -| demuxer | | multiqueue | --------- \ | | p2\| 'emptyqueue' |--- 'fast' downstream -------------- In the case downstream of one single queue (fullqueue) has (a lot of) latency (for example for reverse playback with video), we can end up having the other SingleQueue (emptyqueue) emptied, before that fullqueue gets unblocked. In the meantime, the demuxer tries to push on fullqueue, and is blocking there. In that case the current code will post a BUFFERING message on the bus when emptyqueue gets emptied, that leads to the application setting the pipeline state to PAUSED. So now we end up in a situation where 'laggy downstream' is prerolled and will not unblock anymore because the pipeline is set to PAUSED, the fullequeue does not have a chance to be emptied and the emptyqueue can not get filled anymore so no more BUFERRING message will be posted and the pipeline is stucked in PAUSED for the eternity. Making sure that we do not try to "buffer" if one of the single queue does not need buffering, prevents this situtation from happening though it lets the oportunity for buffering in all other cases. That implements a new logic where we need all singlequeue to need buffering for the multiqueue to actually state buffering is needed, taking the maximum buffering of the single queue as the reference point. https://bugzilla.gnome.org/show_bug.cgi?id=734412 |
||
---|---|---|
.. | ||
elements | ||
Makefile.am |