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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Aug 11 04:14:48 PDT 2014


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

Thibault Saunier <tsaunier> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #282767|0                           |1
        is obsolete|                            |

--- Comment #7 from Thibault Saunier <tsaunier at gnome.org> 2014-08-11 11:14:45 UTC ---
Created an attachment (id=283076)
 View: https://bugzilla.gnome.org/attachment.cgi?id=283076
 Review: https://bugzilla.gnome.org/review?bug=734412&attachment=283076

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.

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


More information about the gstreamer-bugs mailing list