GNOME Bugzilla – Bug 762125
uridecodebin: Add properties and documentation for better control over buffering
Last modified: 2018-11-03 11:44:52 UTC
Created attachment 321347 [details] [review] uridecodebin patch for enhanced buffering control Currently, there are only two properties for controlling the buffering: buffer-size and buffer-duration. Properties for the low/high percentage thresholds are missing. Also, the default value for buffer-size and buffer-duration is -1, which means "automatic/default". It is not obvious what this exactly means, and relies on hardcoded internal values. Furthermore, buffer-duration conflates two distinct concepts: its value is used both for bitrate-based and for input data rate based buffer size estimation. As a result, a buffer-duration value of for example 5 seconds can either mean a buffer size of bitrate*5 seconds , or in case of slow connections, in-data-rate*5 seconds, whichever is lower. In many cases, it is desirable to use only one of these two estimations. The exact way how buffering behaves, how the properties work, and how it should be used is not documented. This is the first version of a patch that deprecates buffer-size and buffer-duration in favor of three new properties: max-buffer-size, max-buffering-duration, and buffer-estimate-duration. The new properties work as follows: * max-buffer-size: The upper limit for the buffer size, in bytes; this value is passed to the internal queue/decodebin as the "max-size-bytes" property; default value is 10 MB * max-buffering-duration: The in-data-rate*duration estimate mentioned above; this value is passed to the internal queue/decodebin as the "max-size-time" property, but it is *not* used for bitrate based estimations; default value is 0 (= disables data rate based estimates) * buffer-estimate-duration: The bitrate*duration estimate mentioned above; this value is not passed to the internal queue, and used only if a bitrate tag is encountered; default value is 6.5 seconds Out of these three, the lowest size (in bytes) is picked. The patch also makes it possible to set these property during playback; the buffer size will be readjusted on the fly. Properties for low/high percentage are also introduced. Default values are: low 5%, high 5%. Together with the default values for the other three properties, this means buffering messages will reach 100% once 1.5 seconds are buffered. During playback, if the source can deliver data faster than realtime, additional 5 second can be buffered on the fly. This makes streaming playback more robust against network bandwidth drops without having to let the user wait too long for buffering to finish. gtkdoc documentation for how to use these new properties and how configuring buffer size works is also added. Also, a new "will-post-buffering" signal is added. This is emitted whenever uridecodebin sets the "use-buffering" property of an internal queue to TRUE. This is useful for applications to let them know that they should *not* switch to PLAYING just yet, because buffering messages *will* be posted soon. This prevents the possibility that the PLAYING state is reached, playback goes on briefly, and then the application receives the first BUFFERING message, and pauses playback again. In subsequent patches, playbin could also get these new properties (they'd be forwarded to uridecodebin just like buffer-size and buffer-duration are now), and the new signal. Another planned addition is a "current-buffer-level" property; however, this first requires a patch for multiqueue, since it doesn't have any property like that (queue2 does have "current-level-bytes"). Also, several parsers such as flacparse, wavparse, aiffparse have been found to not push bitrate tags downstream, and therefore also require patching to further improve buffering behavior.
Typo: I meant "Default values are: low 5%, high 23%" above.
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.
"makes it possible to set these property during playback; the buffer size will be readjusted on the fly."---seems to sound have allure very much．-) Consider the slower network,we want to use less data for prepare pipeline and see the picture as soon as possible,however, in playing, we hope that the data of buffering should not be too low, resulting in frequent buffering.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/253.