TechWatch: Flicks (Measurement of Time)

[Rodney]

What is larger than a nanosecond but shorter than a second?

 

If Facebook (and presumably others) have their way it is a 'flick'.

 

A flick is defined as:

 

1 flick = 1/705600000 second

 

Somewhat usefully (mathematically) a flick can "in integer quantities exactly represent a single frame duration for 24hz, 25hz, 30hz, 48hz, 50hz, 60hz, 90hz, 100hz, 120hz, and also 1/1000 divisions of each." This helps with conversions of frequencies and image/audio sync.

 

One potentially useful bit of information I saw outlined in the write up on flicks is this on the NTSC standard of 29.97 frames per second... something I have always thought was painful to consider:

 

The NTSC variations (~29.97, etc) are actually defined as 24 * 1000/1001 and 30 * 1000/1001, which are impossible to represent exactly in a way where 1 second is exact, so we don't bother - they'll be inexact in any circumstance.

 

 

I am rather pleased to see the underlying standard in that equation includes 24 fps but as oulined above it syncs well with 24, 25, 30, 48, 50, 60, 90, 100, 120 etc..

I can't help but think some old time animators might appreciate the use of the term flick as well. (as they were accustomed to flicking (and flipping**) sheets of paper to test their animation).

C++ code has been open sourced and is available on github at:

 

https://github.com/OculusVR/Flicks

 

According to the write up on github:

 

Knowing that you should never, ever use floating point representations for accumulated, simulated time (lest your temporal accuracy degrade over time), the std::chrono time tools in C++ are ideal. However, the highest usable resolution, nanoseconds, doesn't evenly divide common film & media framerates. This was the genesis of this unit.

 

So an accurate resolution of time was deemed necessary enough that they are releasing and promoting the spec in hope of universal adoption.

 

As for usage of the code itself:

 

it is not required to use the library, but only to show how it was derived. A brute-force approach was intentionally used.

 

This is an odd thought but... I was under the impression that A:M already used 'flics'.

Hmmmm...

 

 

**I wonder if we might eventually see a unit of time called a flip. Sure, why not.

But come to think of it a flip is likely a unit of measurement like 0/1, 1/0 and 0/0 that for all intents and purposes is undefined until such a time as another term is used to define it.

0/0 is straightforward enough. That's some undetermined percentage of 1.

[Rodney]

Here's the CNET article relating to this:

 

https://www.cnet.com/news/facebook-redefines-time-with-open-source-flicks

 

And a similar article from Techcrunch:

 

https://techcrunch.com/2018/01/22/facebook-invented-a-new-time-unit-called-the-flick-and-its-truly-amazing/

 

From that article:

Here’s a list of numbers into which 1/706,600,000 divides evenly: 8, 16, 22.05, 24, 25, 30, 32, 44.1, 48, 50, 60, 90, 100, 120. Notice a pattern?

Even if you don’t work in media production, some of those numbers probably look familiar. That’s because they’re all framerates or frequencies used in encoding or showing things like films and music. 24 frames per second, 120 hertz TVs, 44.1 KHz sample rate audio.

Many of these fractions resolve into inconvenient decimal series, necessitating shorthand or estimations. For instance, the 1/24th of a second around which the entire film industry is based on is equal to 0.0416666666666666… on and on forever (even attempting to use nanoseconds to represent these durations ends up creating fractions of nanoseconds). So it may be abbreviated for convenience to 0.04167. Easier to remember, but not numerically exact, and who knows when that “extra” value might break something?

On the other hand, using flicks almost all these important fractional frequencies turn into a nice exact round numbers, no bars or estimation needed: 1/24th of a second, for instance, is 29,400,000 flicks. 1/120th is 5,880,000 flicks. 1/44,100th is 16,000 flicks.

 

Those numbers may not be easier for you to remember, but it makes them a heck of a lot simpler for systems to match with one another without creating some kind of inter-format fraction that has to be resolved with yet another adjusting frequency. Computers love whole numbers...

And here's an article that gives some credit to a VR engineer from Facebook:

 

https://www.cnbc.com/2018/01/22/facebook-group-invents-flick-to-measure-video-frame-rates.html

 

The guy who invented it left the company months before it was approved to be released to the open source developer community.

 

Christopher Horvath has this to say about the news:

 

 

Hey remember that one time I took weeks and weeks to design a unit of time, with lots of help from you - and then it took over a year for me to get it through the Open Source process at Facebook (my fault, not theirs!)

Flicks is a thing in the world!!!! WHOOO HOOO!!!!

Thanks to Pascal, Simon,Kearsley,Francisco,Dan, and many more who I'm forgetting.

 

Added: Meethinks this is very timely with the release of the AV1 video format.

[nemyax]

Prior art: A:M's "ticks".

[Rodney]

Prior art: A:M's "ticks".

Ah yes, that's the tick-et!

Thanks for refreshing the memory.

 

From a previous discussion that quoted from an (unidentified) previous discussion:

 

 

"...It turns out A:M stores time in "ticks", not seconds or frames, and A:M counts 135000 ticks per second. Every keyframe you make is stored internally as a number of ticks elapsed from zero. This makes it possible to change your PRJ from 24fps to 30 fps, for example, and not have your animation run 25% faster.

 

A:M can count up to 18,446,744,073,709,551,616 ticks which is somewhat more than 4.3 million years.

 

135000 was chosen because it is evenly divisible by all the common frame rates and further divisible beyond that for most multipass intervals.

 

For example, at 24 fps, each frame is 5625 ticks apart...."