Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Facebook Media Social Networks

Facebook Announces That It Has Invented a New Unit of Time ( 188

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.
This discussion has been archived. No new comments can be posted.

Facebook Announces That It Has Invented a New Unit of Time

Comments Filter:
  • Why? (Score:5, Insightful)

    by saloomy ( 2817221 ) on Monday January 22, 2018 @09:29PM (#55982471)

    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.

    • Re:Why? (Score:5, Funny)

      by Anonymous Coward on Monday January 22, 2018 @09:34PM (#55982509)

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

      • by Anonymous Coward

        Nonsense. A flick is obviously the amount of time that Intel CPUs take to execute a nanosecond's worth of code, after their meltdown patch.

      • They apparently invented naming a variable with a value of 1/705,600,000.
      • by Anonymous Coward

        We do not care what facebook bullshit they gonna find today or tomorrow.... fucking kill facebook please! Enough is enough !!

    • by kondro ( 614476 )
      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.
      • 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.
        • 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???

          • And who did Hip Hop Virtual Machine for "Personal Home Page"...oh, it was facebook, they don't eat their own dogfood? Of course, everything is in C at some level, or nearly. Some of us still use a bit of ASM.
      • by tricorn ( 199664 )

        No, fractions of a second don't end up as floats. They end up as some number of smaller units of time unless you're doing it wrong. Typically you'll measure in units of milliseconds, microseconds, nanoseconds, picoseconds, depending on the accuracy of the underlying hardware clock and the number of bits you can easily work with, but measuring time as number of frames also works fine - you just convert time by multiplying and dividing.

        If you use 64 bits (either as a single nanosecond value, or as a pair of

    • Re:Why? (Score:5, Informative)

      by Rosco P. Coltrane ( 209368 ) on Monday January 22, 2018 @09:41PM (#55982557)

      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.

      • Are you overclocking? You got me beat by about 10%

      • Re: (Score:3, Informative)

        by Anonymous Coward

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

    • Re:Why? (Score:5, Interesting)

      by TheCycoONE ( 913189 ) on Monday January 22, 2018 @09:46PM (#55982591)

      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.

      • Re:Why? (Score:5, Informative)

        by Anonymous Coward on Monday January 22, 2018 @10:17PM (#55982793)

        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.

      • Re:Why? (Score:5, Informative)

        by Obfuscant ( 592200 ) on Monday January 22, 2018 @10:58PM (#55982983)

        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?

        • by gfxguy ( 98788 )
          Because good enough isn't good enough.
        • Re: (Score:2, Insightful)

          by Anonymous Coward

          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.

        • by houghi ( 78078 )

          But a frame is not on/of per frame. It is per pixel on a line. So as I see it "frame" is just a group from the moment the first pixel is activated till the moment the pixel right before it (the last pixel on the screen) is activated.
          That first pixel is nice, but not essential. You could do it with a pixel in the middle or any other random pixel.

          Becsue if you take two pixels next to each other, the framerate will be the same. Just one lights up a bit sooner than the other one.

          • But a frame is not on/of per frame. It is per pixel on a line.

            Double buffering means that you do not display each pixel as it is calculated, you calculate them all and then switch the display to the that frame. Each frame is a complete set of pixels.

            Becsue if you take two pixels next to each other, the framerate will be the same. Just one lights up a bit sooner than the other one.

            That depends on the display, not the framerate nor the means of calculating when the next frame should be displayed.

            Becsue if you take two pixels next to each other, the framerate will be the same.

            Of course,

            Just one lights up a bit sooner than the other one.

            Irrelevant to knowing what that frame rate is or determining when the next frame of your video needs to be displayed.

        • Re:Why? (Score:4, Interesting)

          by AmiMoJo ( 196126 ) <> on Tuesday January 23, 2018 @08:49AM (#55984627) Homepage Journal

          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.

          • by Entrope ( 68843 )

            They were wrong about NTSC, though. Because they chose a multiple of 120000 as the denominator, NTSC frame durations are representable with integer flick counts. That inaccuracy seems par for the course of their documentation, sadly.

    • by AHuxley ( 892839 )
      Such efforts can be found in France with []
      Just more messing with politics by people who want to impose their own revolutionary "change".
    • Isn't a Hz effectively a measurement of time?


  • by Quarters ( 18322 ) on Monday January 22, 2018 @09:31PM (#55982487)

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

  • Because programmers are bad at math?

    Or, why is a technique programmers have used since computers were born news again?
  • by ClickOnThis ( 137803 ) on Monday January 22, 2018 @09:35PM (#55982521) Journal

    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.

    • by Entrope ( 68843 ) on Monday January 22, 2018 @09:48PM (#55982617) Homepage

      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.

      • by Anonymous Coward

        Also, unlike many existing standards (SMPTE, QuickTime CoreVideo using rationals with flexible denominator in CMTime), this FaceFriend thing doesn’t exactly support common frame rates like NTSC 59.94i, 29.97p and NTSC conformed film at 23.976 for 3:2 pulldown.

        The exact ratios needed for these are 60000/1001 Hz, 30000/1001 Hz and 24000/1001 Hz. To exactly support this, their arbitrary constant should have been a multiple of 1001.

        Oh well.

      • by gman003 ( 1693318 ) on Monday January 22, 2018 @09:57PM (#55982675)

        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.

        • Re: (Score:2, Informative)

          by Anonymous Coward

          Except it isn’t. They messed up.

          Neither of these is integral:

          705600000 / NTSC_FREQ_APPROX
          705600000 / NTSC_FREQ_EXACT

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

          So they don’t support those frequencies exactly anyway.

          • Re: (Score:3, Insightful)

            by Anonymous Coward

            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.

            • by Muros ( 1167213 )

              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.

              Actually it is x * b / a

        • 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".
        • Aren't these fractions only a result of trying to make things work for NTSC, which has a frame rate of 29.97? PAL for example refreshes at a flat 25Hz, AFAIK.
          • by Entrope ( 68843 )

            No. As an AC or two has pointed out, NTSC-based frame rates would need a factor of 1001 also.

          • by Entrope ( 68843 ) on Tuesday January 23, 2018 @07:53AM (#55984459) Homepage

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

        • 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 w

      • by jmv ( 93421 )

        I suspect they were also trying to cover NTSC's 29.97 Hz and maybe even 44.1/48 kHz audio.

    • Not that not reading the article is uncommon in Slashdot either, but it appears that almost every single poster complaining about it didnâ(TM)t bother to read even the intro page cited in the article. Even the ones who thought they were being clever brining up 29.97fps. Seriously, this seems like a nice solution to a niche problem, and if you donâ(TM)t see the point, itâ(TM)s probably not for you anyway.

      • by Entrope ( 68843 )

        In this case, reading the intro page without careful double-checking would be a bad idea. The "Basics" section of the project's makes two simply wrong claims in three short paragraphs: that a "flick" is the smallest unit of time larger than a nanosecond that can represent 1/24000 s, ..., 1/120000 s as integers (there are many time units between a nanosecond and a flick that evenly divide all of those durations); and that NTSC times are inherently inexact (NTSC frame durations can be exactly repres

  • ...(not knowing a helluva lot, but enough) that this does seem like a pretty innovative thing. Anytime you can shift the perspective of thinking, whether it ends up working or not, is always a Good Thing(TM).
    • It's a pretty common thing I've frequently seen in the past. The difference is normally it's only done between two framerates. This seems like its being done between many more.

  • by Anonymous Coward

    Pretty much what I expect out of idiot millenials

    • It's not stupid, it's practical. Like the historical kilobyte, equivalent to 1024 bytes: it's nonstandard, but it gives a good idea of "something close to 1000 bytes" that's easy to work with in powers of two.

      • by Nutria ( 679911 )

        It's practical, but it sure the hell isn't "the the smallest time unit which is LARGER than a nanosecond".

        (The smallest "1 over" time unit larger than a ns would be 1/999,999,999.)

  • by jenningsthecat ( 1525947 ) on Monday January 22, 2018 @09:46PM (#55982599)

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

    • Re: (Score:2, Funny)

      by Entrope ( 68843 )

      There would be way too many opportunities to complain about Facebook and/or Oculus being fricking stupid.

    • by dohzer ( 867770 )

      We should hit the "thumbs-down" button on this concep... oh wait there isn't one. #democracy

  • I'm a little surprised that this came from FB and not Google/YouTube but I can definitely see its value.

    Does it make sense to clock hardware and GPUs at this rate? A 3GHz GPU would run at 2,822,400,000 Hz and would synchronize to any video (incoming or outgoing) refresh rate allowing for no missed pixels, pixels that are sampled at transitions or maybe some FLICKer.

    Depending on the application, media and its refresh rate, this may not offer a lot of tangible advantages. For instance, in gaming, I don't se

  • by Anonymous Coward

    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 1296

  • If you have to use floating point values to store a number, it has inaccuracy. For example a simple penny counter algorithm that needs to break out of a loop when pennies remaining is less than 1 will misbehave when you're trying to check if .01 .011 if you stored .01 as a float. It will actually store 0.01 as 0.0999999999995 or something and that will cause the loop logic to fail. If you store in whole integers of pennies, you won't have this problem. So this concept of using Flicks allows you to use pr
  • Portmanteaus? (Score:2, Redundant)

    by fahrbot-bot ( 874524 )

    The name (flick) itself is a portmanteau of the phase "frame-tick," ...

    No it isn't as there's no "l" (ell) in either word.

    Apparently, they rejected the following (from :Portmanteaur []):

    • frame tick: frack, frick, frameck, framick, framck, frtick, framtick, frak, framek, fick, fraick, ftick, fratick, framk
    • tick frame: time, tame, ticme, trame, tme, tie, tice

    and "steve".

    Personally, I would have chosen one of: frack, frak, frick, or time - but not sage or rosemary.

  • Wrong (Score:2, Redundant)

    by dohzer ( 867770 )

    The name itself is a portmanteau of the phase "frame-tick," which is also why you might want to use them.

    No it's not! It's a word chosen to sound cool and look *roughly* like those words smooshed together, but where did the 'L' come from?
    It's an engineered one. The portmanteau equivalent of a backronym.

    Also, I don't want to use them, even if they do change the name to "Frick".
    But thanks for asking.

  • by ChunderDownunder ( 709234 ) on Monday January 22, 2018 @09:58PM (#55982685)

    Did Zuckerberg just invent time travel?

  • Stupid title (Score:5, Interesting)

    by scatbomb ( 1099255 ) on Monday January 22, 2018 @10:02PM (#55982715)
    Facebook did not "invent" a unit of time. They defined a non-standard unit of time based on the already existent S.I. system.
    • Are you splitting hairs between "invent" and "defined something that didn't exist prior" on something intangible? It's not just the title of this article that is stupid...

      • So when you develop software, do you invent variables or do you declare them?

        • Declare them obviously. Unless it is you declare the variable of a type that never existed before, in that case you invent them.

  • the smallest time unit which is LARGER than a nanosecond ... For comparison, a nanosecond is 1/1,000,000,000 of a second, making a Flick roughly 1.41723356 nanoseconds long

    I'm confused - why is a flick 1.41723356 ns and not 1.3 ns or 1.41723354 ns? Does this have to do with time being quantized and Planck time? I thought planck time was on a scale much smaller than nanoseconds, but I'm possibly remembering wrong.

  • by QuietLagoon ( 813062 ) on Monday January 22, 2018 @10:10PM (#55982757)
    ... when they think they are so self-important that they invent new measurement units.
  • that someone posted 5 days ago, just becuase some dumbarse 'liked' it today?

  • by Anonymous Coward on Monday January 22, 2018 @10:16PM (#55982787)

    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.

    • For decades a 'Flick' was one page of a flip book. So if you wanted to have so many pages per second you counted the number of Flicks.

  • What about... (Score:5, Insightful)

    by viperidaenz ( 2515578 ) on Monday January 22, 2018 @10:23PM (#55982813)

    23.976Hz or 29.97Hz?

    They're both industry standard frame rates.

  • by Anonymous Coward

    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?

    • Somebody actually looks up the standard and gets it right. Who would do that on Slashdot :-)? 1001 can actually be factored (13 * 11 * 7) and the factors combined with other ratios to get a common tick rate that is about what they came up with (caveat, I did not check if they did the math right). I did this about 15 years ago and reported a bug to Apple that they should use that magic number in quicktime (or more precisely, document that was the appropriate magic number to use, because Quicktime already

  • by Anonymous Coward

    ... the phase "frame-tick" ...

    Until a hardware vendor starts talking in flicks and designing circuits to match, this is meaningless.

    The French, when inventing the metric system, created a decimal circle, calendar, clock: The clock and calendar soon disappeared. People talk about decimal circles (Gradians) but no-one uses them.

    There was Swatch Internet Time (1 beat = 86.4 seconds, 1 Kbeat = 1 day) but nobody else measured time with it, so it's dead.

  • by Anonymous Coward

    A femto-fortnight is larger than a nanosecond and less than the flick. It is 1.2096 ns.

  • Pickles the kitten learned an important lesson today, find out what after the break.

  • Dammit, I'm still trying to get used to Swatch "beat time"...

  • There is no fucking "L" in either of the originating words.

    Basic English fail. Get this shit off Slashdot.

  • Flick is what I do with my middle finger. In this case, in the direction of Facebooks claim to having invented a unit of time.

  • Portmanteau? Frame Tick = Flick? Uh, no. Where the fuck is the L coming in from?

    Facebook are welcome to their stupid, ad-hoc names for subdivisions of seconds. The unit of time is a second, and facebook won't ever change that.

    • It's a reference to an old slang term for movies being 'flicks,' I'd assume, coupled with a 'Puck Man becomes Pac Man' style desire to not use the word 'frick'.
  • In search of a problem
  • The name itself is a portmanteau of the phase "frame-tick,"

    That would be "Frick" or Frack" There is no "L" in either "Frame" or "Tick".

  • but the most exact timing possible in C++ is nanoseconds

    Of course you can get more precise than a nanosecond in C++ (as well as in any other turing-complete language). Double precision is roughly down to 10^-16, so a 1-second video could be processed with a precision of femtoseconds. Storing time as a fixed point value in a long long would get you 19 digits of precision, so you could do femtoseconds for an hour-long video. If that's not good enough, grab an arbitrary precision math library and store it down

"It takes all sorts of in & out-door schooling to get adapted to my kind of fooling" - R. Frost