I prefer to write them as 24000/1001, 30000/1001, 60000/1001 fields-per-second to avoid the ugly decimals and because I think it makes it a little more intuitively clear what’s going on to achieve those numbers.
Reminds me of Facebook's Flicks, which are a super short tiny common denominator time unit:
> A flick (frame-tick) is a very small unit of time. It is 1/705600000 of a second, exactly.
> 1 flick = 1/705600000 second
This unit of time is the smallest time unit which is LARGER than a nanosecond, and can in integer quantities exactly represent a single frame duration for 24 Hz, 25 Hz, 30 Hz, 48 Hz, 50 Hz, 60 Hz, 90 Hz, 100 Hz, 120 Hz, and also 1/1000 divisions of each, as well as a single sample duration for 8 kHz, 16 kHz, 22.05 kHz, 24 kHz, 32 kHz, 44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz, and 192kHz, as well as the NTSC frame durations for 24 * (1000/1001) Hz, 30 * (1000/1001) Hz, 60 * (1000/1001) Hz, and 120 * (1000/1001) Hz.
Guess the project got archived. Seemed like a semi sensible high res time format that was very media friendly.
Why bother with the EMU when we have nanometers (or some small multiple thereof)? Even 1/64 inch, 1 PostScript point, or 1 traditional point are an integral number of nanometers.
And that's what I get for not checking that my calculator was rounding on me. Apologies. (And I even used the good calculator, too, so I wouldn't screw up the units....)
The code amounts to a definition of the unit in a way that’s usable with the C++ standard library, there are no exchange formats or anything. That the repo got archived might mean that they are not planning to promote it, but neither the code nor the unit itself really need any further development—if you have a place where you want to use them, you can just do that.
Unfortunately most digital video formats don’t actually store them this way, either because the editing software rounds it off incorrectly or because the format itself stores timestamps in decimals for some reason (Matroska).
<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/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....
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?
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.
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.
> 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.
Many multimedia formats, frameworks and libraries actually store them that way.
In Mpeg 4, each track header has a “time scale” integer field. For a video track of 23.976 FPS the value can be 23976, or half of that, 11988. Audio tracks typically have different time scale field, often 48000 for 48kHz audio.
In Media Foundation, MF_MT_FRAME_RATE media type attribute is a rational number with uint32_t numerator and denominator. In DXGI, the RefreshRate field of DXGI_MODE_DESC structure which contains a refresh rate of a monitor is a rational number, for instance my display actually uses 59997/1000 Hz frame rate, not exactly 60 Hz.
I think part of the parent’s complaint is that, although 23976/1000 fps is much more accurate than 24 fps, it’s still very slightly slower than the correct value 24000/1001 fps, by about 2.1 frames per day.
Here’s what MediaInfo tool shows about the video stream of some *.mp4 file on my computer. The content was first released in 1997, before modern digital stuff.
Specifically, the timescale value in "mdhd" box (overall information about the media, defined in section 8.4.2 of the ISO/IEC 14496-12 spec) is 24000, and "stts" box (time-to-sample, defined in section 8.6.1.2 of that spec) says all video frames have the same sampleDelta = 1001.
But don’t you then have to then explain this every time you try to communicate with these numbers to someone else. Are you just writing this down for yourself?
“Teachable moment” I guess? I usually use that notation in my nfo blurb when encoding DVDs for a modern flatscreen target. Anecdotally, nobody has ever asked me to clarify. Small sample size though due to niche nature.
