Filmmakers urge TV industry to phase out fractional frame rates (e.g. 23.976fps)
flatpanelshd.com
flatpanelshd.com
Industry tends to love mandates that force new purchases.
And hardware people tend to love it when their hardware just works too.
Clear conflict of interest here.
Making sure we have robust integer frame rate support means new material can be produced. Great! So let's do that.
Making sure we explicitly remove support for fractional frame rates means old material will either not be usable, or degraded.
We really do not need the latter. Simply doing the former will work this all out over time. There really is no rush.
They might report support for specific rates in their EDID, but you can usually feed it almost totally arbitrary video timings and it will still work as long as your vblank, front porch, etc. values are somewhat reasonable and you don’t exceed its max rate.
Furthermore, if you were to send a display a video signal with timing parameters for 24 Hz but actually clocked at 23.9, I doubt the monitor would even care. After all, it must tolerate some frequency difference since the incoming signal is being clocked by the sending device.
The only time I’ve ever seen a display (in this case, an LG 4K monitor) act weird is when I fed it an interlaced signal.
The industry support at the display level is good and can be even better.
This really is all about streaming having to compete with a body of legacy media. To a lesser degree it is about the most efficient solutions between creators and distributors.
The Xbox problem mentioned can be fixed with a firmware update. So do that... sheesh!
even this was an appropximation though:
> NTSC IS NOT EXPLICITLY SUPPORTED IN ALL OF ITS SUBTLE NUANCES, BUT: The NTSC variations (~23.976, ~29.97, etc) are approximately defined as 24 1000/1001 and 30 * 1000/1001, etc. These can be represented exactly in flicks, but 1/1000 divisions are not available.*
> Many folks online have pointed out that NTSC technically has a variable frame rate, and that this is handled correctly in other media playback libraries such as QuickTime. The goal of flicks is to provide a simple, convenient std::chrono::duration to work with when writing code that works with simulation and time in media, but not explicitly to handle complex variable-rate playback scenarios. So we'll stick with the 1000/1001 approximations, and leave it at that!