GNOME Bugzilla – Bug 678534
asfdemux: Seeking in ASF file hangs
Last modified: 2018-05-08 05:24:35 UTC
Disabling the audio decoding makes seeking work. The watermark on the video links to a NSFW site, as is expected for video player bug reports ;) http://people.gnome.org/~hadess/.seek-hang-asf-nsfw.wmv (Note: need to use -t 1 because of bug 678530) $ ./totem-video-thumbnailer -v -t 1 seek-hang-asf.wmv foo.png TotemVideoThumbnailer-Message: Initialised libraries, about to create video widget TotemVideoThumbnailer-Message: setting URI file:///home/hadess/Projects/jhbuild/totem/src/seek-hang-asf.wmv TotemVideoThumbnailer-Message: Video widget created TotemVideoThumbnailer-Message: About to open video file 0:00:00.480449677 10481 0xe639e0 ERROR ffmpeg :0:: Custom get_buffer() for use withavcodec_decode_audio3() detected. Overriding with avcodec_default_get_buffer 0:00:00.480579360 10481 0xe639e0 ERROR ffmpeg :0:: Please port your application to avcodec_decode_audio4() TotemVideoThumbnailer-Message: Checking whether file has cover TotemVideoThumbnailer-Message: Opened video file: 'seek-hang-asf.wmv' totem-video-thumbnailer couldn't process file: 'seek-hang-asf.wmv' Reason: Took too much time to process. Seeking in totem results in the same problem. This is the smallest chunk of file that can reproduce the problem. Truncating it to 4 megs results in seeking working, bizarrely enough.
Works fine in everything except for totem-video-thumbnailer. Problems looks like the pipeline never finishes the state change, never pre-rolls. In other players seeking does not hang but does not work either. And the file has no duration
This issue happens in the latest master as well The main issue here is because of the corrupted header of the file. Play Duration value from the header is not proper. It is coming as more than 20 mins when the actual file duration is far less than that. Hence there is problem while trying to seek more than the actual duration. If we really need to make these kind of corrupted streams work, then we might have to estimate the duration similar to how we do in baseparse. But not sure if it is needed. 678530 is also similar to this.
Also bug #678531 (with patch).
The difference between these two bugs and 678531 is, in these two files are not broadcast files and both have header set to seekable.. so the patch there might not directly work out here.. but if we try to calculate the duration for all kind of files, irrespective of whether they are broadcast or not, then this might work out.. but again this means even for files which have proper play duration in header we will be calculating the duration again, since i think there is no possible way to say if the duration present in the header is proper or not..
Works fine with playbin3/decodebin3. An interleave issue again I assume.
Closing as obsolete since it works with playbin3/decodebin3.