GNOME Bugzilla – Bug 678530
asfdemux: incorrect length for truncated dancer.asf
Last modified: 2018-05-12 06:27:29 UTC
Trying to load a file like: http://samples.mplayerhq.hu/asf-wmv/asf_errors/dogma.asf results in errors in totem-video-thumbnailer and lacks errors in totem itself. The length is reported as more than an hour, seeking further than the actual length of the file work, but: - totem-video-thumbnailer will fail to read frames and exit: ** (totem-video-thumbnailer:4766): WARNING **: Could not take screenshot: failed to retrieve or convert video frame - Totem will hang, and not go forward anymore causing the file never to finish
First, fix a little crash at the end: commit 7c89a7298a1c7e6f411bfdd18db057e87045a47e Author: Tim-Philipp Müller <tim@centricular.net> Date: Mon Nov 26 18:41:07 2012 +0000 streamsynchronizer: don't send gap events with huge bogus durations when advancing EOS streams When the input buffers for a stream don't have a duration set, timestamp_end might still be GST_CLOCK_TIME_NONE. When advancing EOSed streams via GAP events (with other streams not yet EOS), we would then use the invalid timestamp_end to calculate the duration of the gap. This in turn would make baseaudiosink abort, because it would try to allocate memory for a trizillion samples. So if buffers don't have a duration set, assume a duration of one second for stream catch-up purposes, just so we can still continue to catch up in those cases. And make sure that timestamp_end is valid before doing calculations with it. http://bugzilla.gnome.org/show_bug.cgi?id=678530
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 an hour 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. 678534 is also similar to this.
Also bug #678531 (with patch).
*** This bug has been marked as a duplicate of bug 678531 ***