GNOME Bugzilla – Bug 390003
poor buffering/pause during playing
Last modified: 2009-05-06 20:11:20 UTC
Please describe the problem: in totem 2.16, the totem-mozilla plugin works great, showing online videos where it didn't work before. however it does bring some new problems, at least on my computer. For instance, on http://www.apple.com/getamac/ads/ on my connection (cable 512kbps download, 128kps upload), the videos play fine for a while, then pause (presumably as more data is downloaded), then start playing again. This is true even for the lowest-resolution videos, which is quite disappointing since after all I have cable internet (not the fastest, but still). This is with totem-xine. I tried briefly with totem-gstreamer and the quality was a lot worse. Besides weak image quality, it seemed like only one frame on two was displayed, or something like that. But this bug is about totem-xine. I think in this case, totem should display a status bar "buffering" with a progress bar (I saw that once when I asked totem to play a video over a SMB share), and only start playing when reasonably sure it'll be able to play the whole video without skipping. It might be impossible due to the xine-lib API though... But it definitely should be the long-term goal. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Do you see the same problem with xine-ui itself, playing the same streams?
(In reply to comment #1) > Do you see the same problem with xine-ui itself, playing the same streams? i wanted to check it out, but the stream is within a webpage (apple.com), and I don't know how to launch xine to open the video from the website (i tried quickly and failed).
OK, I checked it out. the command is for instance: xine http://images.apple.com/movies/us/apple/getamall_480x376.mov And it's more or less the same behaviour as totem. Before the video starts there's displayed "Buffering [X%]" which is not the case with totem. Then it starts playing but like totem after a while, freezes. When it's frozen, the OSD displays "Buffering [X%]", and when the OSD reaches 100%, it starts playing again. So, same problem as totem.
Emmanuel, did you try again to play this movie, to see if the bug was still present, did you try with gstreamer-based totem ? I would tend to close this bug as NOTGNOME if xine-ui has the same issue. thanks for your feedback.
GStreamer based Totem browser plugin exhibits the same behaviour. The problem as I see it is twofold, but basically Totem should follow how YouTube et al work, this includes continuing to fetch the media even while playback is paused, and throttling fetch speed to maybe twice the bitrate of the media, and also in the case ConnectionBandwidth < MediaBitrate: only starting play after the whole file is buffered, or displaying an info dialog in the case of streaming media.
I can confirm Γριφεγ's statements. Totem (apparently) uses a fixed buffer size that doesn't adjust to higher bitrate video streams. Totem needs a 'bottomless' youtube-style buffer that fills even while a video stream is paused. As things stand, totem is useless for high bitrate streaming video (e.g. apple.com/trailers). Is streaming video a priority for totem? As I recall, Apple's quicktime plugin at one time included an 'autoplay when video stream is sufficiently buffered' feature, but it sometimes guessed wrong and started play too early, causing a buffer underrun. Maybe it still does this.
There are some interesting numbers to be found with the system monitor's Network graph. Sometimes, if I pause playback on a large video (theoretically so that the buffer can catch up while I go and a have a snack, since I can't rewind the thing!), download appears to cease entirely. It may be a related issue. Remote videos should be buffered more aggressively, while Totem seems almost completely ignorant of the need. May I suggest a GSoC, GHoP or gnome-love thing here? I have a feeling it should be reasonably straight-forward to implement a smarter video buffering; this bug just needs someone clever and keen, maybe with good networking experience, to get the ball rolling.
Pretty much a major issue for me, making lots of websites that embed video difficult to live with when they (or I) lack the bandwidth for live playback. For example, http://studios.ecchi.ca is my home server with a very small bandwidth. I had to use an apache hack to force downloads to prevent people from trying to play the videos in streaming (as the time of writing this, the files are OGG Theora, but I'll likely convert to H.264). I'm using Totem 2.24 + gstreamer 0.10.21. It annoys me that, on other platforms, all video players have this basic "show the buffer filling up" feature and that they calculate when it is sane to start playback; windows media, quicktime, and most flash-based players do this. I can't code to help this issue, but I can gladly lend studios.ecchi.ca as a testing ground for bandwidth-limited streaming torture tests.
Actually, that website still has the force-downloads htaccess hack in place; if someone wants to work on this bug and wants me to disable it for testing, don't hesitate to ask.
The xine-lib backend was removed from Totem master. Please test whether the problem(s) you were encountering still occur with the GStreamer backend (in which case you should file a new bug). If you are unwilling or unable to use the GStreamer backend, feel free to use alternative xine-lib based players, such as gxine. Totem 2.26.x will still have the xine-lib backend available.
This needs to be reopened, and the component changed to gstreamer. If you read the comments already posted, this has been tested w/gstreamer and found to be a problem. I can confirm that it still is.