GNOME Bugzilla – Bug 592739
Audio/Video sync lost after seeking in Totem
Last modified: 2009-08-28 11:04:29 UTC
I'm frequently having problems with lost sync between audio and video after seeking in Totem. It's usually a problem when I skip backwards in a movie, but I've seen it happen skipping forward too. It's usually Xvid and Mp3 in an AVI container, but I'm not sure if it's limited to these files only. I'm using Totem 2.27.2. gstreamer-tools 0.10.24-1 gstreamer0.10-alsa 0.10.24-1 gstreamer0.10-doc 0.10.24-1 gstreamer0.10-esd 0.10.15.3-1 gstreamer0.10-ffmpeg 0.10.8-2 gstreamer0.10-gnomevfs 0.10.24-1 gstreamer0.10-gnonlin 0.10.12-1 gstreamer0.10-lame 0.10.11-0.0 gstreamer0.10-nice 0.0.9-2 gstreamer0.10-plugins-bad 0.10.13.3-1 gstreamer0.10-plugins-base 0.10.24-1 gstreamer0.10-plugins-base-apps 0.10.24-1 gstreamer0.10-plugins-base-doc 0.10.24-1 gstreamer0.10-plugins-gl 0.10.1-2 gstreamer0.10-plugins-good 0.10.15.3-1 gstreamer0.10-plugins-good-doc 0.10.15.3-1 gstreamer0.10-plugins-ugly 0.10.12-1+b1 gstreamer0.10-pulseaudio 0.10.15.3-1 gstreamer0.10-sdl 0.10.13.3-1 gstreamer0.10-tools 0.10.24-1 gstreamer0.10-x 0.10.24-1 libgstreamer-plugins-base0.10-0 0.10.24-1 libgstreamer-plugins-base0.10-dev 0.10.24-1 libgstreamer-plugins-gl0.10-0 0.10.1-2 libgstreamer0.10-0 0.10.24-1 libgstreamer0.10-dev 0.10.24-1
What audio sink ends up being used in your case? pulsesink? Could you point us towards a sample file the exhibits the problem?
I use pulse by default, but the problem is the same with the alsa sink. I chopped of the first 50M of one of the movies. It's enough to reproduce the problem: http://uploading.com/files/VHR95W9G/file.avi.html
And it's the same problem with Totem 2.26 (thought it might be related to the playbin2 switch, but no).
One more question: is this a regression from -good 0.10.15 or has it been a problem for longer?
I think this was a regression in gst-ffmpeg caused by the new timestamp tracking code, I think it is fixed by: http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/commit/?id=2b967b4122125e5591c72708a698f2ceed841de2
As far as I can tell, there's no difference with the patch applied. It's a regression, but I really can't say when it broke, unfortunately.
I tried reverting back to 0.10.7 of gst-ffmpeg and got the same problem. It seems avidemux does manage to find the right indexes, so all seems right. Needs more investigation. I suspect it's because of the VBR mp3 audio that the audio timestamps don't really match up.
If you are using the pulsesink from the 0.10.15 prereleases (which seems to be the case) then it might be Bug #593015. Please try the newest prerelease and reopen if not fixed. *** This bug has been marked as a duplicate of bug 593015 ***