GNOME Bugzilla – Bug 620500
totem won't do progressive download for flv videos
Last modified: 2010-06-07 08:19:58 UTC
With most online videos, totem will do progressive download, filling up its buffer and then starting playback while it continues to download the rest of the video. For some reason it won't do this with FLV files. It doesn't start playing until the entire video is downloaded. I first noticed this on YouTube using a greasemonkey script that replaces the flash player with a native plugin. fmt=18 videos, which are mp4, begin playing almost immediately, while fmt=34 or fmt=35, which are flv, do not. I then confirmed it with some other videos in totem proper (not the browser plugin). Here's one posted by someone reporting this problem on ubuntuforums: http://hd.spaziogames.eu/hd20/2009/9/psp/4018.flv I tried it in banshee and it works fine, so this seems to be specific to totem and not gstreamer.
Which version of Totem and all the GStreamer packages are you using? (In reply to comment #0) > I tried it in banshee and it works fine, so this seems to be specific to totem > and not gstreamer. Totem is the only app along with the GStreamer support in webkit which uses download buffering. In fact, Banshee doesn't even use playbin2 as far as I know.
(In reply to comment #1) > Which version of Totem and all the GStreamer packages are you using? > Totem 2.30.2 Gstreamer 0.10.28, specifically (ubuntu version numbers): gstreamer0.10-alsa 0.10.28-1 gstreamer0.10-ffmpeg 0.10.10-1 gstreamer0.10-fluendo-mp3 0.10.12.debian-2 gstreamer0.10-gnonlin 0.10.15-1 gstreamer0.10-nice 0.0.10-2build1 gstreamer0.10-pitfdll 0.9.1.1+cvs20080215-1ubuntu2 gstreamer0.10-plugins-bad 0.10.18-1ubuntu1 gstreamer0.10-plugins-bad-multiverse 0.10.18-0ubuntu1 gstreamer0.10-plugins-base 0.10.28-1 gstreamer0.10-plugins-base-apps 0.10.28-1 gstreamer0.10-plugins-good 0.10.21-1ubuntu2 gstreamer0.10-plugins-ugly 0.10.14-1 gstreamer0.10-plugins-ugly-multiverse 0.10.14-0ubuntu1 gstreamer0.10-pulseaudio 0.10.21-1ubuntu2 gstreamer0.10-tools 0.10.28-1 gstreamer0.10-x 0.10.28-1 libgstreamer-plugins-base0.10-0 0.10.28-1 libgstreamer0.10-0 0.10.28-1 (is there a good way to get gstreamer to give me the version numbers via gst-inspect or something?) > (In reply to comment #0) > > I tried it in banshee and it works fine, so this seems to be specific to totem > > and not gstreamer. > > Totem is the only app along with the GStreamer support in webkit which uses > download buffering. In fact, Banshee doesn't even use playbin2 as far as I > know. I'm not familiar with the implementation details, but banshee most definitely plays the video at the URL above with buffering.
Nothing seems to be telling Totem about duration of the file. As Totem will only start playing when it knows that "time left to download" < duration (or thereabouts), it only starts playing back when we know that the "time left to download" is 0 (eg. when we reached 100%). So the problem is that GStreamer isn't updating us about the duration of the file (which can be seen in the status bar, with the 0:00:00/0:00:00 status).
commit 15141b3954fdfb46002783463f1cace148480fe9 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Jun 7 10:16:04 2010 +0200 queue2: don't wait for data when EOS When in download mode and we need to provide data for an offset that we don't have, also perform a seek to the requested location when we are EOS. The reason why we shouldn't wait for more data is because after EOS, there simply will be no more data and we end up waiting forever. Fixes #620500