GNOME Bugzilla – Bug 619381
[matroskamux] drift in timestamps for audio
Last modified: 2011-04-04 10:33:04 UTC
Easy to reproduce this: gst-launch -e audiotestsrc ! vorbisenc ! matroskamux ! filesink location=blah.mkv ctrl-c after say 10 seconds then: gst-launch -m filesrc location=blah.mkv ! matroskademux ! vorbisdec ! identity check-imperfect-timestamp=true ! fakesink You get reports every buffer for example: Got message #135 from element "identity0" (element): imperfect-timestamp, prev-timestamp=(guint64)1940000000, prev-duration=(guint64)23000000, prev-offset=(guint64)18446744073709551615, prev-offset-end=(guint64)18446744073709551615, cur-timestamp=(guint64)1964000000, cur-duration=(guint64)23000000, cur-offset=(guint64)18446744073709551615, cur-offset-end=(guint64)18446744073709551615 here: prev-timestamp + prev-duration = 1963000000 and cur-timestamp = 1964000000 so looks like a rounding error somewhere when scaling or something in the muxer because it doesn't happen with gst-launch -m audiotestsrc ! vorbisenc ! vorbisdec ! identity check-imperfect-timestamp=true ! fakesink
So it happens with raw audio as well as vorbis too.
So the reason for the imperfect streams are that matroska has a timecode scale which in matroskamux is set to 1 millisecond. This means all timestamps and durations are rounded to nearest millisecond. When matroskademux outputs timestamp/duration the timestamp does not match up to the previous timestamp + previous duration therefore and hence the non-perfect decoded stream. There is a drift between audio and video however, I noticed about 10 seconds after 9 hours. But this simple test case is not causing the problem. Though we should fix the imperfect decoded stream.
The 10 seconds after 9 hours drift was as a result of something completely different, closing as invalid.