14 ms·
When you seek to a timestamp from the source, or write a temporary matroska file and go over it in parallel in a second pass, timestamps being rounded variously
by mgdlbp 4y ago
When you seek to a timestamp from the source, or write a temporary matroska file and go over it in parallel in a second pass, timestamps being rounded variously up or down will cause off-by-ones and dropped frames and desyncs.
1 ms is pretty imprecise for audio seeks, however - mkvtoolnix actually increases precision to sample rate when there's audio. But why do all tracks have the same timescale? Oh right, TrackTimeStampScale was in the spec all along and could be used to solve all of this...apart from being floating-point.
- Dylan16807 4y ago> When you seek to a timestamp from the source, or write a temporary matroska file and go over it in parallel in a second pass, timestamps being rounded variously up or down will cause off-by-ones and dropped frames and desyncs. Why? It shouldn't. A millisecond-resolution timestamp unambiguously identifies a specific frame, at least until you start going over 400fps. You just need to go to the closest frame rather than rounding up/down. And rounding up/down can break very easily even if you're using ultra precise numbers, especially if you don't have a fixed framerate for the entire file.