4 ms·

<rant>Ah...Matroska was nearly perfect, and then they chose nanosecond-precision timestamps. Countless attempts at frame-perfect seeking thwarted and videos imb

by mgdlbp 4y ago

<rant>Ah...Matroska was nearly perfect, and then they chose nanosecond-precision timestamps. Countless attempts at frame-perfect seeking thwarted and videos imbued with jitter over the years, subordinate to the tyranny of 33 34 33 33 34 33... Even worse, not only is the recommended precision only 1 ms, but almost all muxers support nothing else, ffmpeg included*. A shame that despite such versatility, mkv is scuffed as an intermediate/archival format by lossy muxing, yet almost no one is aware. * https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2021-May/280460.html https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2021-May/280... matroska precision parameter coming soon? It's been over a year, though - looks like the patch is dead. Meanwhile, the bikeshedding of rational timestamps in the matroska lists can now be expressed with a timebase of decades....

iforgotpassword 4y ago
Not that I know much more than how to merge multiple audio tracks into a single file and do the Faststart stuff so the video starts faster, isn't the issue then really only that everyone only does milliseconds with mkv, and theoretical otherwise? Surely, when using nanoseconds and just moving the error to the next frame, jitter should be unperceivable, not even measurable on even high refresh rate displays?
- astrange 4y ago
  There most likely aren't playback issues; it's just silly that a concept that is never anything but a rational number is being stored in a way that can't store rational numbers.
Dylan16807 4y ago
Exact timestamps are aesthetically nice but frame-perfect seek should not have any problems with sub-millisecond jitter.
- 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.

by mgdlbp 4y ago

iforgotpassword 4y ago

Not that I know much more than how to merge multiple audio tracks into a single file and do the Faststart stuff so the video starts faster, isn't the issue then really only that everyone only does milliseconds with mkv, and theoretical otherwise? Surely, when using nanoseconds and just moving the error to the next frame, jitter should be unperceivable, not even measurable on even high refresh rate displays?

astrange 4y ago
There most likely aren't playback issues; it's just silly that a concept that is never anything but a rational number is being stored in a way that can't store rational numbers.

Dylan16807 4y ago

Exact timestamps are aesthetically nice but frame-perfect seek should not have any problems with sub-millisecond jitter.

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.