[Bug 762125] uridecodebin: Add properties and documentation for better control over buffering

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Carlos Rafael Giani <dv at pseudoterminal.org> ---
There was a discussion regarding the "will-post-buffering" signal. It is
necessary because it is not guaranteed that at least one buffering message
(say, 0%) arrives by the time a state change to PAUSED is posted and arrives at
the application's bus. If the queue were to guarantee that it posts a buffering
message before its state change finishes, this signal would probably not be
necessary.

One possibility would be to have a "has_posted_buffering" flag inside
queue2/multiqueue. Initially it is set to FALSE. Whenever a buffering message
is about to be posted, this flag is set to TRUE. Then, during the READY->PAUSED
state change, if this flag hasn't yet been set to TRUE, it posts a buffering
message with 0% (and sets the flag to TRUE). The flag is reset to FALSE after a
FLUSH_STOP event and after going back to READY. With this, the application
would simply check if a buffering message has arrived by the time the PAUSED
state is reached. If not, then no buffering is expected.

This assumes however that the 0% message will make it in time *before* the
state change message! The question is, is such a guarantee possible?

Also, there is a similar problem: sometimes, the 100% buffering message is not
posted. Sometimes, <100% messages do get posted, just not the 100% message
itself. On other occasions, no message is posted at all. (The latter is only a
problem if the will-post-buffering signal is used; if instead the
"has_posted_buffering" flag approach is taken, it can be ignored.) Reproducing
this is difficult. Once I have something, I will post it as a bugzilla entry.

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