Rather than invalidate a ton of legacy content and gear, I would much prefer explicit support for integer frame rates, and see exactly that in a lot of gear I use now.
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.
Right. Not only that, in my experience, TVs and monitors really don’t even support specific rates - what I mean is, they can usually accept a range of timings. It would probably require extra work to intentionally _not_ support some specific rates.
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.
Many HDMI devices will display a very wide range of inputs. A group I hang with are exploring all that with a micro able to output native HDMI / DVI. It has been enlightening.
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!
> 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!
5 comments
[ 1.1 ms ] story [ 30.1 ms ] threadIndustry 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!