GNOME Bugzilla – Bug 562558
Badly incorrect seek in MPEG files
Last modified: 2010-12-01 06:54:41 UTC
Please describe the problem: Seeking in MPEG files doesn't work as expected. When the slider is moved and then released, it jumps backwards. The length of the jump is progressively bigger towards the end of the file. For 50-minute mpeg film it is impossible to seek to the last 10 minutes, because when slider is moved to the far right the clock shows about 41 minutes! Seeking with keyboard also is unusable, and quite crazy. In play mode, using single keypresses (right arrow) advances my 50-minute film by decreasing leaps up to about timecode 04:37, and then the behaviour reverses - each keypress actually moves the film backwards. When I press and hold the key, it ultimately starts to seek forward, but never reaches the end, because at timecode 30:00 or so the slider just starts to jump wildly back and forth. In pause mode seeking works, but also stops at timecode 41:00, unable to reach the final 10 minutes of the file. I have also tested seeking in totem-gstreamer using AVI (xvid), FLV, and OGG (Theora) files, and got the following results: avi: Seek works reliably, with a small backjump of 2-3 seconds. flv: Seek works reliably, with a small backjump of 1-2 seconds. ogg: Seek works reliably to the very second. Steps to reproduce: 1. Open MPEG2 video file in Totem. 2. Press play. 3. Move the seek bar by mouse or key (right arrow). Actual results: Mouse: after the slider is released it jumps backwards, the further the longer is the film. Key pressed and held: slider jumps wildly back and forth in the second half of the clip, never reaching the end. Both in pause mode: even when the slider is moved far right it cannot seek to the last 20% of the clip Expected results: The slider should be able to seek reliably to any position in the clip. Does this happen every time? Yes. Other information: When the file is just left to play, it plays nicely until the very end. So the bug might be caused by a conflict between two competing calculations of the clip length: one made by playing engine, and another used by seek engine.
Could you attach an example file which demonstrates this problem please (or a section of such a file)? What version of GStreamer (and its plugins) have you got installed?
First, I have to make a correction. The MPEG file I used for testing was MPEG1 not MPEG2. I'm afraid I cannot provide the file I work on because it is copyrighted and too big (500 MB). Below you'll find another short file showing some of the bad behavior, notably 'backsnapping' of the slider. For the problem to show up in full extent (especially the chaos when using keyboard), however, the movie has to be long. I also think I found a clue. When Totem slider is clicked on and held still for a few seconds during playback, it actually snaps FORWARD on release. It seems that the slider follows the audio stream - which continues to play while video stays frozen - not the video stream, and that's the cause of snapping. http://www.jhepple.com/support/sample_movies1.htm Download the file number 3 (MPEG-1). I also attach two screen grabs showing the time discrepancy. While file was playing, the slider was moved by mouse all the way to the end. The Totem clock shows that the current position is the file's end at 24:03. But the timecode embedded in the video shows 19:35. When I release the mouse button, the slider 'backsnaps' 5 minutes. It is impossible to seek to the file's end. This happens with every MPEG1 file I have. I am using Ubuntu 8.10 amd64 on 2.6.27-10 kernel. My GStreamer version: $ dpkg -l | grep gstreamer ii gstreamer0.10-alsa 0.10.21-3 GStreamer plugin for ALSA ii gstreamer0.10-ffmpeg 0.10.5-1 FFmpeg plugin for GStreamer ii gstreamer0.10-gnomevfs 0.10.21-3 GStreamer plugin for GnomeVFS ii gstreamer0.10-gnonlin 0.10.9-1 non-linear editing module for GStreamer ii gstreamer0.10-plugins-bad 0.10.8-1 GStreamer plugins from the "bad" set ii gstreamer0.10-plugins-bad-multiverse 0.10.6-1ubuntu1 GStreamer plugins from the "bad" set (Multiverse Variant) ii gstreamer0.10-plugins-base 0.10.21-3 GStreamer plugins from the "base" set ii gstreamer0.10-plugins-base-apps 0.10.21-3 GStreamer helper programs from the "base" set ii gstreamer0.10-plugins-good 0.10.10.4-1ubuntu1 GStreamer plugins from the "good" set ii gstreamer0.10-plugins-ugly 0.10.9-1ubuntu0.1 GStreamer plugins from the "ugly" set ii gstreamer0.10-plugins-ugly-multiverse 0.10.7-2 GStreamer plugins from the "ugly" set (Multiverse Variant ii gstreamer0.10-pulseaudio 0.10.10.4-1ubuntu1 GStreamer plugin for PulseAudio ii gstreamer0.10-schroedinger 1.0.5-1 GStreamer plugin for encoding/decoding of Dirac video str ii gstreamer0.10-tools 0.10.21-4 Tools for use with GStreamer ii gstreamer0.10-x 0.10.21-3 GStreamer plugins for X11 and Pango ii libgstreamer-plugins-base0.10-0 0.10.21-3 GStreamer libraries from the "base" set ii libgstreamer0.10-0 0.10.21-4 Core GStreamer libraries and elements ii totem-gstreamer 2.24.3-0ubuntu1 A simple media player for the GNOME desktop based on GStr
Created attachment 123762 [details] slider moved with mouse to the end
Created attachment 123763 [details] mouse button released
I can't reproduce it with the file you suggested. Could you attach a debug log (perhaps gzipped if it's too big?) generated with the following command when you reproduce the bug: GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:4 totem --debug &> totem.log
Unfortunately, I cannot attach level 4 debug logs, because they are huge. After just a few seconds the file grows to more than 100 MB. I attached level 3 logs instead, number 1 for moving slider with mouse to far right, number 2 for pressing and holding the right keyboard arrow. Both operations resulted in improper behaviour. Hope they can help.
Created attachment 123850 [details] Level 3 debug logs
Tim?
Bug still present with the latest Ubuntu updates. I can provide one MPEG clip causing the problem, if this helps. Email me privately at andrzej.pienkowski(thisfunnysymbol)studiocompany.pl. BTW, Its not only me having this problem: https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/231538 Best regards, Andrzej
I'd say this is fixed in the latest gst-plugins-bad release (0.10.11). Andrzej, which version of gst-plugins-bad do you have ?
$ dpkg -l | grep plugins-bad ii gstreamer0.10-plugins-bad 0.10.8-1 GStreamer plugins from the "bad" set ii gstreamer0.10-plugins-bad-multiverse 0.10.6-1ubuntu1 GStreamer plugins from the "bad" set (Multiverse Variant) It looks like my version was not the latest. I added the GStreamer PPA, updated, and now I have: $ dpkg -l | grep plugins-bad ii gstreamer0.10-plugins-bad 0.10.10.2-1~intrepid1 GStreamer plugins from the "bad" set ii gstreamer0.10-plugins-bad-multiverse 0.10.6-1ubuntu1 GStreamer plugins from the "bad" set (Multiverse Variant) No 0.10.11 on the PPA. With the updated gstreamer, however, Totem refuses to play anything. With my MPEG1 files it just takes over the CPU. No error is reported to the stdout. With any other video file the playback is possible only when I kill pulseaudio (which also was updated when I updated gstreamer). So I'm afraid I cannot test the files with the new GStreamer. I reverted back to the standard Intrepid packages.
This is most probably fixed nowadays. If it's still an issue with the latest releases please reopen this bug. The PPA contains the latest releases for Ubuntu Jaunty.
Comment from the launchpad bug: >>> This is still an issue, but I have noticed some improvements. It only seems to affect a certain either file type or codec from the file type. Any suggestions on how I can get the most useful information on what makes this video type special? Basically a tool that can tell Codec, compressions, etc etc? This is using Ubuntu 9.10 x64 <<< (the launchpad bug had been reported about a general seek problem, but seems to narrow down to this bug about seeking in mpeg files) Ubuntu 9.10 has the following gstreamer components: gstreamer0.10 | 0.10.25-2 | karmic | source gstreamer0.10-plugins-bad | 0.10.14-4ubuntu1 | karmic/universe | amd64, i386 gstreamer0.10-plugins-ugly | 0.10.12-1 | karmic/universe | amd64, i386 gstreamer0.10-plugins-good | 0.10.16-1ubuntu3 | karmic | amd64, i386 gstreamer0.10-plugins-base | 0.10.25-2ubuntu1 | karmic | amd64, i386 gstreamer0.10-plugins-base | 0.10.25-2ubuntu1.1 | karmic-updates | amd64, i386
Could someone please explain why this bug is marked as "Resolved" and "Incomplete"? How can it be resolved while it is still incomplete?