GNOME Bugzilla – Bug 365288
[asfdemux] seeking not very smooth
Last modified: 2007-05-08 09:30:58 UTC
When i seek in WMV9 movies it gets corrupted and its not as smooth as other formats. The corrupted image fades away when the movie starts to play again. Example: http://thatvideosite.voxcdn.com/core/1471/nuclear_explosion_compilation.wmv In the past i thought it was problem with the gst-pitfdll codec thingy but i get the same problem with gst-ffmpeg and the new VC-1/WMV3/WMV9 video decoder. When seeking Totem outputs: 0:00:03.822906000 5896 0x85898f0 ERROR ffmpeg :0:: overflow in spectral RLE, ignoring Other information: Totem-CVS(Gstreamer), Gstreamer-CVS, Gst-plugins-*-CVS and Gst-ffmpeg-CVS.
Nope, it's just that seeking in asfdemux is extremely sucky.
I declare this as fixed in -ugly CVS. The spectral RLE warning is from the audio (I think). I still get it, but seeking is as smooth as I think it's going to get with key-unit seeking.
I've used the CVS asfdemuxer over the past month and it has gotten som great improvments. Really happy to see this and im sure many more is. One thing with the seeking is that for some videos it don't seek so you can see the video flashing by. But its not a specific codec like WMV9 because some WMV9 movies works and some don't. I'll try to find a video for free downloading on the net or something i can upload.
It depends a bit on whether it has a seek index or not, how good the index is, how many keyframes there are in the file and how fast the decoding is. If there is no index, a seek position will be guessed. This guess can be off quite a bit; if it's too early, it might take too long to advance to the right spot and decode it (totem only blocks for 100ms or so before potentially issuing another seek; if it's too late, it might not start playing again for a few seconds. This is still something that needs a bit of work, no doubt.