GNOME Bugzilla – Bug 361793
Get some feedback on how much of the buffert has been filled.
Last modified: 2009-11-09 19:52:31 UTC
It would be very helpful to get some feedback on how much of the buffert has been filled. Then the user would know how long he/she should wait until video/audio started. Or if the buffering has stopped for some reason the user wouldent have to sit and wait forever before closing it down. Have no idea how this could be solved, there is not much space on the browser-plugin. Maybe a *"visual plugin" that shows how many percent has been buffered? *"visual plugin" = As the ones show in the Totem Movie Player when playing audio, "GOOM: What a GOOM!" for example. Just a thought.
What bugs me is that it starts playing the file almost instantly, if it would wait a few seconds and build up a buffer playback would run more smoothly. Also there is no way of starting playback from the begining until the file is fully buffered. in ubuntu the progressbar (that shows where you are in the movie) changes color to the left of the marker, if this color was used to show how much was buffered (as in Quicktime on Windows) and then the marker can move along that colored area and play that content, it would be great.
I just installed Ubuntu 7.04, so I'm using 2.18.1 with the gstreamer back end and I am finding the way buffering is handled to be disappointing as well. I have had trouble with this before, so I just came to the bugzilla and searched for buffering related bugs and found a few 390003, 364578 and this one. They seem to boil down to the lack of the behaviour that Marten described above, basically display the buffer progress overlayed on the play progress bar, and only start playing when it is estimated that the whole clip can be watched without running to the end of the buffer. I should emphasize that even if the buffer progress can't be displayed and the download speed is only estimated from the connection type set by the user, the playback should not start until the video is sufficiently buffered to play the whole thing in one go. Thanks for all your work
*** Bug 431975 has been marked as a duplicate of this bug. ***
*** Bug 456261 has been marked as a duplicate of this bug. ***
*** Bug 482735 has been marked as a duplicate of this bug. ***
I agree with the above comments. This would make Totem much more pleasant to use.
Please note that fill level[1] is currently "implemented" only in standard GTK+ theme and in Clearlooks gummy (yes, themes have to manage it). See bug #481348 for progress [1] http://library.gnome.org/devel/gtk/2.11/GtkRange.html
am using the new clearlooks theme on ubuntu gutsy and there is no fill level during buffering that i see
(In reply to comment #8) > am using the new clearlooks theme on ubuntu gutsy and there is no fill level > during buffering that i see > I said that the theme Gummy supports fill level, not that Totem is using them.
Created attachment 97197 [details] Example of GtkScale using fill level Note: it's an animated GIF showing a horizontal scale with value=30 and fill-level=60 rendered in some themes installed by gtk-engines module. The order should be: Clearlooks-Classic, Glossy, Gummy, Raleigh, Crux, Glider, Industrial.
since more themes are supporting this feature, is there a chance of getting this built into totem in the future? i have little to no programming experience but it seems like a trivial addition if I were given some direction...
*** Bug 527753 has been marked as a duplicate of this bug. ***
without such info, I don't know when to click play on getamac site ( http://www.apple.com/getamac/ ). and the progress slider. it is unusable in there, don't know why.
I wanted to give it a shot today but unfortunately it seems (I might be wrong) the gstreamer pipeline used by totem: 1) does not provide such prebuffering information (only for current play buffer which is kind of useless as it does not expose the time, only the percentage) 2) does not allow scrolling through streamed content (at least not for common formats like X264 or FLV with embedded stream index) Can anyone point me in the right direction? I'm fairly familiar with gst but I usually use it to work with local streams.
gstreamer 0.10.20 now has gst_query_new_buffering and gst_query_parse_buffering_* that can provide us with both percentage and range (so we can limit seeking to only the buffered part) but it seems no elements make real use of it yet. The buffering query will fail on all elements except playbin2 which always reports 100%. Also as there is no real documentation (there is syntax but without examples it's not very useful to me) we should probably check (or can we somehow ask for it to always cache the full stream?) the buffering mode: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstQuery.html#GstBufferingMode Therefore I propose to extend the SIGNAL_TICK (or "tick") signal to also contain cached_range_start and cached_range_end (so we can display it on the slider). Comments? Any gst gurus to help me with the gst buffering API? Anyone willing to implement the buffering API at least for the flv + soup case so I can test totem on some working content?
This would be a really nice addition because compared to the DivX plugin on windows there is absolutely no feedback if the video works or not - you can just wait and see.
Agreed, this would make the totem plugin a lot more usable for playing videos (and audio) in the browser.
This is already fixed in totem master. See: http://www.hadess.net/2009/11/no-more-stuttering.html 1) Only works with FLV and QuickTime files 2) Then again, not all of them, see: https://bugzilla.gnome.org/show_bug.cgi?id=600877 For other file types, or if it doesn't work for a specific file, please file a separate bugs, with a reproducer URL.
Bastien: Your blog link mentions using on-disk buffering, which is cool. However, does totem visually indicate the buffer status with your changes, like youtube does?
(In reply to comment #19) > Bastien: > > Your blog link mentions using on-disk buffering, which is cool. > > However, does totem visually indicate the buffer status with your changes, like > youtube does? Follow the links, there's a screenshot the previous day...