GNOME Bugzilla – Bug 480188
Totem time resets to zero when playing mpg-in-avi
Last modified: 2011-10-29 15:39:09 UTC
The bug has been opened on https://bugs.launchpad.net/bugs/136704 "... When I play an mpgv (mpeg-1) file in totem-gstreamer, the time progress reading <current time> / <total time> keeps resetting current time to zero and then resetting it to the correct time, so it will say, for example: Playing 0:06 / 15:40 Playing 0:00 / 15:40 Playing 0:07 / 15:40 Playing 0:00 / 15:40 Playing 0:07 / 15:40 Playing 0:08 / 15:40 Playing 0:00 / 15:40 Playing 0:08 / 15:40 etc. It doesn't show this problem while it still says "Buffering", only when it says "Playing". I tried totem-xine and vlc and they didn't have this problem. Versions are: totem-gstreamer: 2.19.90-0ubuntu3 gstreamer0.10-ffmpeg: 0.10.2-2ubuntu1 gstreamer0.10-plugins-good: 0.10-6-0ubuntu1 gstreamer0.10-plugins-ugly: 0.10-6-0ubuntu2 gstreamer0.10-plugins-bad-multiverse: 0.10.5-1 libgstreamer0.10-0: 0.10.14-1ubuntu1 ... http://launchpadlibrarian.net/9275768/mpg.tar.bz2 ... I've found that it doesn't happen with all mpgs, just some that I tried. I've managed to isolate a small example for you. It might be something to do with the way the sound is encoded, because when I removed the sound (using avidemux 'copy video' but with no sound), it didn't happen any more. There are two files in the attached tar.bz file: * mpg that resets time in totem-gstreamer2.avi * demo of time reset in totem-gstreamer.ogg The first one is a 7-second mpg that shows the problem when played in totem-gstreamer. The ogg file is a screen vid of totem-gstreamer playing a 12-second version of the file, captured with recordMyDesktop. The video doesn't render in the ogg file, and it runs a bit slow (recordMyDesktop slows things down somewhat - when I play the mpg without recordMyDesktop recording, the time resets to zero more frequently that in the ogg file.), but it demonstrates the issue - you can see the time resetting to zero every now and again, going back to what it should be, then back to zero, etc."
It'll be a GStreamer bug if it doesn't happen with totem-xine; forwarding to the GStreamer people.
> It'll be a GStreamer bug if it doesn't happen with totem-xine That's a non sequitur (it could be totem GStreamer backend doing something weird). In any case, I'm not getting the problem with GStreamer CVS + totem trunk (but I do get it with the gutsy packages), so it looks like it's been fixed. Not sure what exactly fixed it though right now.
do you need informations or should rather the bug be marked fixed since it works with svn versions?
I don't need any further information, apologies for not making that clear. Just marking it as NEEDINFO for now so I/someone will look at it again later. I do want to know what exactly fixed this.
This is still happening with latest CVS here. The time in totem advances correctly but jumps back to 0:00 for a few milliseconds a few times. Behaviour is like 0:00 0:00 0:01 0:01 0:00 0:01 0:02 0:02 ....
I just downloaded the file from the old launchpad bug and tested. Works fine. Closing this as fixed.