[Bug 755220] Feature requests for playbin/decodebin/uridecodebin and/or successors

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Carlos Rafael Giani <dv at pseudoterminal.org> ---
Since I have some additions to (3), I continue here:


* Currently, there is no way to find out if a stream that is being decoded by
decodebin is going to send out buffering messages (at least not without
manually searching for queue elements etc.). This is however essential, since
otherwise, it is possible that the PLAYING state is reached before the very
first buffering message arrives, leading to a brief bit of playback followed by
silence (until buffering finishes). With a "will-use-buffering" signal,
applications can know that buffering is going to happen, and ensure to not
switch to PLAYING right away. Instead, they can initially just switch to
PAUSED, and if "will-use-buffering" was emitted, they know they should not
switch to PLAYING just yet.

Such a signal could for example be emitted whenever decodebin sets a queue's
use-buffering property to TRUE.


* Under certain circumstances, it appears that a multiqueue never emits
buffering messages even though use-buffering is set to TRUE. It is difficult to
reproduce, and very much looks like a race condition. It is not clear if just
having use-buffering set to TRUE is a guarantee that queue2/multiqueue will
*always* post a BUFFERING message. If this isn't the case, then I propose we
add a "dummy" message that signals 100%, and document that when use-buffering
is set to TRUE, there will *always* be at least one buffering message. (Both in
queue2 and multiqueue)

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