[Bug 734412] multiqueue: The buffering logic can lead to a pipeline stuck in PAUSED forever

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=734412
  GStreamer | gstreamer (core) | unspecified

--- Comment #1 from Thibault Saunier <tsaunier at gnome.org> 2014-08-07 10:44:42 UTC ---
Created an attachment (id=282767)
 View: https://bugzilla.gnome.org/attachment.cgi?id=282767
 Review: https://bugzilla.gnome.org/review?bug=734412&attachment=282767

multiqueue: Not post BUFFERING message if one of the singlequeue is full

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 is
full, prevent this situtation from happening though it lets the
oportunity for buffering in all other cases.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.