GNOME Bugzilla – Bug 719660
asfdemux: some dvr-ms files don't play
Last modified: 2014-05-26 07:57:27 UTC
Created attachment 263249 [details] [review] Patch to ignore the first 0 timestamp if next timestamp is significantly larger The issue is timestamp of first packet, which is 0, while the rest of the timestamps are much larger (couple of hours). The first timestamp should have been -1, but for some reason is 0, which means that the rest of the timestamps are not properly adjusted and there is a huge gap in resulting timestamps. However the 0 timestamp can not always be discarded (as -1 would be), because there are files where the first 0 timestamp is valid (and the rest of the timestamps are counting from it) I haven't found a "proper" way to distinguish between those two cases unfortunately. The patch fixes this by discarding the 0 timestamp if the gap between it and the second timestamp is larger than one second.
Unfortunately I can't submit a sample file as the only sample file that I have is over 2 gigabytes.
For what it's worth, the first few MB might be enough to reproduce the issue. ASF is a streaming format, there's just headers followed by packets.
That's a good point. I did cut a small sample file, available here https://s3.amazonaws.com/MatejK/Samples/timestamp-problem.dvr-ms The duration will be reported wrong of course, but the issue should be reproducible.
commit eb6569625198ceff40736360758a242aa6031e00 Author: Matej Knopp <matej.knopp@gmail.com> Date: Sun Dec 1 20:53:03 2013 +0100 asfdemux: Handle initial 0 timestamp that should have been -1 https://bugzilla.gnome.org/show_bug.cgi?id=719660