Slashdot Mirror
Facebook Announces That It Has Invented a New Unit of Time (theverge.com)
Facebook has announced a new unit of time, called Flicks. "According to the GitHub page documenting Flicks, a Flick is 'the smallest time unit which is LARGER than a nanosecond,' defined as 1/705,600,000 of a second," reports The Verge. (For comparison, a nanosecond is 1/1,000,000,000 of a second, making a Flick roughly 1.41723356 nanoseconds long.) From the report: Now, you may be sitting there wondering what was wrong with regular seconds that Facebook had to go and invent its own unit, especially since the second is one of the few units that is universal across SI and imperial units. The name itself is a portmanteau of the phase "frame-tick," which is also why you might want to use them. Flicks are designed to help measure individual frame duration for video frame rates. So whether your video is 24hz, 25hz, 30hz, 48hz, 50hz, 60hz, 90hz, 100hz, or 120hz, you'll be able to use Flicks to ensure that everything is in sync while still using whole integers (instead of decimals). Programmers already use built in tools in C++ to manage these sorts of exact frame syncing, especially when it comes to designing visual effects in CGI, but the most exact timing possible in C++ is nanoseconds, which doesn't divide evenly into most frame rates. The idea to create a new unit of time to solve this problem dates back to last year, when developer Christopher Horvath posted about it on Facebook.
Because when you display a frame in a video player you hold that frame for a certain duration against the computers clock which is measured in nanoseconds (or milliseconds). To calculate that duration at present you take the quotient (e.g. 25/60 * 1000 (or 1000000000)) given you a floating point approximation of the actual frame duration. Now in reality that approximation is pretty good; at least if you do the calculation properly to avoid exaggerating early rounding error.
What this proposal does is ensure that the number you get is a whole number of flicks, so no approximations are necessary. Unfortunately it only helps if you have a flick timer that you can time against, so it needs OS and hardware support to be useful.
Except that all of those frame rates are also integer divisors of 3600 Hz, so 1/3600 Hz would naturally support all of those frame rates also. They have an extra factor of 196,000 beyond what is needed. Even if you want margin for more (weirder) frame rates, and to be conveniently close to a power-of-10 of a second, they could go for 1/864,000 of a second (864,000 = 3600 * 16 * 3 * 5) and have more manageable counts.
For legacy reasons, some (but not all) videos that are nominally 24Hz are actually 23.97Hz, some that are 30Hz are actually 29.97Hz, some that are 48Hz are actually 47.95Hz, some that are 60Hz are actually 59.94Hz, and some that are 120Hz are actually 119.88Hz. I suspect this new "unit" is the greatest common denominator between all those.
Facebook did not "invent" a unit of time. They defined a non-standard unit of time based on the already existent S.I. system.
Correction: The NTSC frame rates can be represented exactly as flicks, but also with any other multiple of 3,600,000 (which also reflects their desire to exactly support 1000 times the 24, 25, 30, 48, 50, 60, 90, 100 and 120 Hz rates).
The way they got to 705,600,000 is by also including 44100 Hz and 192000 Hz for audio purposes. 705,600,000 is the least common multiple of 88,200, 90,000, 100,000, 120,000 and 192,000 (along with the other numbers they cite, which are all divisors of those).
We need "Flicks" exactly why, again?
Because although the error is small, it increases as you do things like frame rate conversion and synchronization to audio. It's also prone to programming errors, because people like to do things like use floats and division to calculate values and then add them up repeatedly, which as we know is a really bad idea.
Also, being a nerd I like precision, and being able to use precise integer values to represent these time intervals.
Granted, none of this is essential, but it's neat that someone figured out a nice common denominator for all the common and uncommon audio/video frequencies in use. Well, except NTSC, which as they point out is just broken and can't be fixed.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC