Slashdot Mirror

← Back to Stories (view on slashdot.org)

Facebook Announces That It Has Invented a New Unit of Time (theverge.com)

Posted by BeauHD on from the flick-of-the-wrist dept.

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.

39 of 188 comments (clear)

  1. Why? by saloomy · · Score: 4, Insightful

    Isn't a Hz effectively a measurement of time? (1/60'th of a second for example?)

    Why not measure them in their fractions of a second? Programmatically, simple.

    1. Re:Why? by Anonymous Coward · · Score: 5, Funny

      Because Facebook wants the press for "inventing" something, duh.

    2. Re:Why? by kondro · · Score: 2

      Because fractions of a second end up as fractions, which end up as floats, which end up with poor precision, which end up with syncing issues with media across large (time-wise) files.

    3. Re:Why? by Rosco+P.+Coltrane · · Score: 4, Informative

      No, a Hertz is a measurement of frequency - that is, the number of times something repeats itself per second. For instance, the thought "Facebook is really crap" springs to my mind at 1/86400 Hz on average.

      --
      "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    4. Re:Why? by TheCycoONE · · Score: 5, Interesting

      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.

    5. Re:Why? by DCFusor · · Score: 2

      rakudo handles rationals as...rationals. Like bigrat in perl5, only perfectly, no precision loss at all. But it's not a fad like...whatever TF facebook wants us to use.

      --
      Why guess when you can know? Measure!
    6. Re:Why? by Anonymous Coward · · Score: 5, Informative

      QuickTime (CoreVideo) has been doing this for decades. For example, CMTime and file data uses rational time (precise ratio of integers) supporting exact time calculations, including fir NTSC 59.94H for framerate, timecodes, etc. Other video standards and applications also do this.

      This Facebook standard doesn't even exactly support 59.94.

    7. Re:Why? by badboy_tw2002 · · Score: 3

      Well its in C++, which is basically invented yesterday. What a fad -- I guess just a big ol' bunch of script kiddies doing typical WEB STACK bullshit, amirite???

    8. Re:Why? by Obfuscant · · Score: 5, Informative

      What this proposal does is ensure that the number you get is a whole number of flicks, so no approximations are necessary.

      If you are working at 30Hz (not "30hz") and count in nanoseconds, you will be off by 0.333... ns per frame. That means 10ns per second. It would take 111,111,111.1 frames to be off by one frame. That's 3703703.7 seconds of video, or 42.8 continuous days of video. After 42.8 days of video, you will be off by one frame.

      If you blink once during that 42.8 days, you will miss the one additional frame that has been inserted into your 30Hz video stream.

      Given the extremely small errors for any frame rate if you use nanoseconds as the timebase, a simple stretch or compress of the rate for that tiny amount will be completely undetectable. The error in any "Flick" clock will vastly outweigh the error of using a simple nanosecond clock and "approximating".

      We need "Flicks" exactly why, again?

    9. Re:Why? by Anonymous Coward · · Score: 3, Informative

      No, a Hertz is a measurement of frequency - that is, the number of times something repeats itself per second. For instance, the thought "Facebook is really crap" springs to my mind at 1/86400 Hz on average.

      Not to be pedantic, but the unit of frequency is "hertz" (with a symbol "Hz"). "Hertz" is the guy it was named after. Units named after people are spelled in lowercase (volt, ampere, bohr, etc).

    10. Re:Why? by Anonymous Coward · · Score: 2, Insightful

      No, you will be off by at most 0.333 ns per frame. Because you store the origin and number of frames that you have processed to calculate the next time to deliver a frame. The error will not accumulate.

    11. Re:Why? by AmiMoJo · · Score: 3, Interesting

      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
    12. Re:Why? by Anonymous Coward · · Score: 2

      It's not technically correct to say that Hz is a measure of frequency, any more than it's technically correct to say that ohms are a measure of conductance

      Yes. Yes, it is. The herz is a unit of frequency; the ohm is not a unit of conductance (it measures resistance). Also, the word "technically" is superfluous in your post. Something is either correct, or it isn't.

  2. That's not a proper portmanteau by Quarters · · Score: 5, Insightful

    There's no 'l' in either Frame or Tick. The name should be Frick or Frack,

    1. Re:That's not a proper portmanteau by bagofbeans · · Score: 5, Funny

      I shudder at the notion that anyone thinks that it is clever to take the mickey out of someone serving them food.

    2. Re:That's not a proper portmanteau by mykro76 · · Score: 5, Funny

      Of course it's not a proper portmanteau.

      It's a Facebook portmanteau. A Fartmanteau.

    3. Re:That's not a proper portmanteau by AmiMoJo · · Score: 2

      Pretty sure there is an I in TlCK.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  3. Wow, what a terrible summary by ClickOnThis · · Score: 5, Informative

    Not that terrible summaries are anything new on Slashdot, but really. "Smallest unit of time greater than a nanosecond?"

    Too lazy to do the math right now, but it appears what they have defined is the largest unit of time that divides the frame-periods they're talking about by integral amounts, so you can synchronize video in these different rates with an integral number of "flicks" for each of the different frame-periods.

    --
    If it weren't for deadlines, nothing would be late.
    1. Re:Wow, what a terrible summary by Entrope · · Score: 4, Interesting

      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.

    2. Re:Wow, what a terrible summary by gman003 · · Score: 4, Interesting

      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.

    3. Re:Wow, what a terrible summary by Anonymous Coward · · Score: 2, Informative

      Except it isn’t. They messed up.

      Neither of these is integral:

      705600000 / NTSC_FREQ_APPROX
      705600000 / NTSC_FREQ_EXACT

      Where
      NTSC_FREQ_APPROX = 59940/1000 = 59.94000000...
      NTSC_FREQ_EXACT = 60000/1001 = 59.94005994005994...

      So they don’t support those frequencies exactly anyway.

    4. Re:Wow, what a terrible summary by chiefscienceofficer · · Score: 2

      Never miss an opportunity to take the audio through one more transform that distorts it. As long a everything was synchronous it was possible to send audio in sync. Now with the decoupling of the display rate from the propagation rate the poor stepchild that gets mangled is the audio as it is speed shifted and pitch shifted back to compensate. Tossing an occasional frame is much more problematic than just reprocessing the audio to match the new "frame rate".

    5. Re:Wow, what a terrible summary by Obfuscant · · Score: 2

      For legacy reasons,

      The legacy reason has to do with the AC line frequency introducing hum bars in the video, and the thought was that it was better for the hum bar to roll through the image than to be stuck in one place, which might happen to be the vertical sync period (thus screwing up the sync).

      The result of this was something called 'drop frame' so that video timing would match clock time. Time code for old B/W video at 30Hz would run from 0 through 29 frames and then roll over the second counter. From here:

      Drop frame timecode was invented to compensate for the discrepancy between 29.97 and 30 fps. Every minute except each tenth minute, two timecode numbers are dropped from the timecode count. This drop frame mode of 30 fps timecode remains accurate compared to the actual time passed, with a strange side effect that two numbers each minute vanish from the count.

      If you ever watch a video where they show the timecode, you can actually see this, if the time is ripe.

    6. Re: Wow, what a terrible summary by sexconker · · Score: 2

      Correct.

      https://www.youtube.com/watch?...
      https://www.youtube.com/watch?...
      https://www.youtube.com/watch?...

      I love this guy's videos.

    7. Re:Wow, what a terrible summary by Anonymous Coward · · Score: 3, Insightful

      Except it is. You messed up.

      705600000 / NTSC_FREQ_EXACT is integral.

      It's exactly 11771760.

      Hint: x / (a / b) = x / a * b. NOT x / a / b.

    8. Re:Wow, what a terrible summary by Entrope · · Score: 3, Interesting

      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).

  4. Portmanteau of "Frame-tick"? by jenningsthecat · · Score: 2

    Shouldn't that be "frick"? Nah, I guess that would be too confusing...

    --
    'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
  5. graphics driver developer here by Anonymous Coward · · Score: 2

    I measure frames in clocks. A frame is always an integer number of clocks.

    If you want to deal with just refresh rates, the LCM of 144, 120, 100, 90, 60, 50, 48, 30, 25, 24 is 3600.

    If you want to deal with lines for common video modes (480, 720, 768, 1080, 1200, 1440, 2160) at those frequencies. LCM = 207360000

    $ for a in 480 720 768 1080 1200 1440 2160 ; do for b in 144 120 100 90 60 50 48 30 25 24 ; do echo $[$a*$b] ; done ; done | sort | uniq | tr '\n' ' ' ; echo
    103680 108000 110592 11520 12000 120000 129600 14400 144000 155520 17280 172800 18000 18432 19200 194400 207360 21600 216000 23040 24000 25920 259200 27000 28800 30000 311040 32400 34560 36000 36864 38400 43200 46080 48000 51840 54000 57600 60000 64800 69120 72000 76800 86400 92160 97200

    plugging all that into lcm.c and I got 207360000. Which is substantially lower than 705600000, and has some factors not present. (705600000/207360000. is
    3.402778)

  6. Wibbly-wobbly timey-wimey... stuff by ChunderDownunder · · Score: 2

    Did Zuckerberg just invent time travel?

  7. Stupid title by scatbomb · · Score: 4, Interesting

    Facebook did not "invent" a unit of time. They defined a non-standard unit of time based on the already existent S.I. system.

  8. The start of the downfall of a company... by QuietLagoon · · Score: 4, Insightful

    ... when they think they are so self-important that they invent new measurement units.

  9. The Flick is already a unit by Anonymous Coward · · Score: 5, Informative

    Guess they didn't care that the Flick was already a unit of measurement used in radiometry?

    1 Flick = 1 Watt per steradian cm^2 micron.

  10. What about... by viperidaenz · · Score: 4, Insightful

    23.976Hz or 29.97Hz?

    They're both industry standard frame rates.

    1. Re:What about... by sexconker · · Score: 2

      23.976Hz or 29.97Hz?

      They're both industry standard frame rates.

      I think you mean 24000/1001 and 30000/1001.
      Of course, you'll also have to handle 23.976 and 29.97 and (multiples thereof) since so much has been built around those approximations.

    2. Re:What about... by Zontar+The+Mindless · · Score: 3, Funny

      We should create a new standard that covers 23.976, 29.97, and Flicks.

      TFTFY. :-)

      --
      Il n'y a pas de Planet B.
  11. Ignores the most common framerates. by Anonymous Coward · · Score: 2, Informative

    Based on feedback from Simon Eves, who pointed out that the NTSC variations are all actually approximations of 24 * 1000/1001, and 30 * 1000/1001, I dropped support for those variations.

    A unit that claims to make measuring video frame time easier and then goes on to ignore the most common framerates?

  12. Re:Portmanteaus? by Beeftopia · · Score: 2

    Smallest unit of time required for video. A quantum of video. A video quantum. A viq.

  13. Time it takes light to travel 42 centimeters by goombah99 · · Score: 2

    Light travels about 42 cm in one flick.

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:Time it takes light to travel 42 centimeters by Anonymous Coward · · Score: 2, Funny

      42 is the answer to everything. There you go.