[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

Sebastian Dröge (slomo) <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|HEAD                        |1.5.1

--- Comment #13 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-08-13 15:25:50 UTC ---
commit 78e22645444fa3784e0bcf4e2b1d0858be3af4fb
Author: Thibault Saunier <thibault.saunier at collabora.com>
Date:   Thu Aug 7 12:18:04 2014 +0200

    multiqueue: Not post BUFFERING message if one of the singlequeue doesn't
need it

    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

-- 
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.