6 ms·

In defense of 'flicks' (or how I learned to stop worrying and love 705600000)

141 points by slimscsi 7y ago

mensetmanusman 7y ago
Computer scientists with a physics background might recognize the syncing problem to the challenge of describing simultaneous events. https://en.wikipedia.org/wiki/Relativity_of_simultaneity https://en.wikipedia.org/wiki/Relativity_of_simultaneity
robolange 7y ago
Did you leave that unbalanced paren in the [Hacker News] title just to drive Lisp users mad? Edit: Thanks for the fix!
- tlb 7y ago
  Fixed, thanks.
0x0 7y ago
The article's leap year rules seem wrong. Pretty sure year 2000 did have a leap day, but 1900 didn't.
- colechristensen 7y ago
  >Every 4 years, we get an extra day at the end of February, unless the year is divisible by 400 (there was no leap day in the year 2000). The article has it backwards. Years divisible by 400 get leap days, others divisible by 100 do not.
- teilo 7y ago
  Yep. The algorithm is: there is a leap day for every year divisible by 4, unless the year is also divisible by 100. But if the year is divisible by 400, then there is a still leap day.
  - jacksnipe 7y ago
    Oh shit, it’s FizzBuzz!
    - hermitdev 7y ago
      Yeah, you really dont want to be implementing a date/time library yourself. It is a far more complex problem than Fizzbuzz. There is so much nuance and easy to overlook details. Just determining whether or not a year is a leap year is about discuss complexity. I wrote a friendlier abstraction over top Boost DateTime in C++ at a previous employer. Adding things like cross platform support of using the Olson database for historical timezone info, a friendlier interface (more akin to Python's datetime lib, which is probably the friendliest datetime lib Ive used across any language) and cross platform strptime. So, didn't do the heavy lifting myself, but rather supplied the timezone info. There were so many subtle details. Like, what does it mean to add 1 day to a timestamp? Do you increment year/month/day as needed to be the next day? Or do you add 24 hours? This matters because if you increment the date only, you can end up with an invalid or ambiguous time. I also appreciate the author mentioning how many hours are there in a day. 23, 24 and 25 are most common for jurisdictions observing daylight saving time, but arbitrary shifts are possible. It depends on the jurisdiction. Take the US for example. It depends not just on the state, but sometimes even the county within a state. Some states dont observe DST (Arizona and Hawaii, maybe others). Parts of Indiana do, some don't (maybe this has changed). Compound this with changes to when DST starts/ends. Its entirely political and can change on a whim. I know there are clocks that are still wrong 12 years later for 6 weeks of the year because of the 2007 US DST change, because of embedded rules for when to change. Sorry for the rant. Spent over 18 months on that project, and I know there are bugs in there nobody bothered to fix after I left that company (fractional seconds handling in strptime I ported from NetBSD, I'm looking at you).
      - jancsika 7y ago
        > Yeah, you really dont want to be implementing a date/time library yourself. Someone should make a date/time "meta library" which iterates through all possible system time values while calling each extant language's date/time method at each iteration. Then report the system time values for which there are discrepancies in the output.
- slimscsi 7y ago
  You are correct! I will fix that
- quickthrower2 7y ago
  I pity those born on 29/02/00
fishgoat 7y ago
Good article, with a couple of minor errors: "Audio recorded at 44100khz" should be 44.100 kHz or 44100 Hz. "there was no leap day in the year 2000" - false. 2000 is divisible by both 400 and 100, so it was a leap year.
- slimscsi 7y ago
  fixed, thank you!
- lonelappde 7y ago
  > divisible by both 400 OK > and 100 We'd be in real trouble if not!
escardin 7y ago
The reason you don't see flicks used all that much is because media encoding is incredibly proprietary in the space where it matters most, live broadcast. Selling into the broadcast space, every broadcaster has petabytes of video in their own chosen format. You have to support EVERY format to sell broadly, and they're not going to let you transcode everything into your format. Using flicks gives you the ability to support as many combinations as possible with the least effort. It matters very little when users are trained to tolerate slow transitions between videos, formats, etc... It also doesn't matter a whole lot when doing offline transcoding either, as you can afford to do the more expensive calculation.
- mike_hock 7y ago
  Even for live broadcast, how can a few integer instructions matter? If you have to compare timestamps every audio sample, that's a few multiplications every 22 microseconds (common denominator can be computed once). Or am I completely off here?
  - escardin 7y ago
    Trying to realtime encode 4k into AVC using pure software encoders takes about 80 cores/hyperthreads. Then you need to meet the tight 70ns? timings of the SMPTE 2022-6/7 protocols (i.e. 12gbps without using jumbo frames because reasons). It's also necessary for clip switching. If you want frame accurate clip switching (i.e. show->ad->ad->show) you need consistent and precise pointers into your files.
kazinator 7y ago
> That is 367.5 times more audio samples than video frames. Okay, but an audio sample is not comparable to a frame of video, which by itself means something to the viewer. (But, on the other hand which probably doesn't differ much from the previous or next one, especially at 120 Hz). An audio sample is sort of more comparable to a pixel.
- slimscsi 7y ago
  Its comparing 1 dimensional space to 2 demential space. So, any comparison is gong to be a little hand wavy. But temporally, I believe the comparison is apt.
  - kragen 7y ago
    > Its comparing 1 dimensional space to 2 demential space Although I love the coinage "2 demential space", I think you mean "comparing one-dimensional space [audio] to three-dimensional space [video]". A two-dimensional signal might be a still image or a temporal sequence of samples from a one-dimensional array of sensors, such as those in a single slice of a CT machine or a linear MIMO antenna array. A video signal is three-dimensional, not two-dimensional, and probably not "2 demential" either.
    - slimscsi 7y ago
      Including pixel intensity, you are correct. Infact it has thee planes, so you could even call it 9 demential If you break it down that way.
      - kragen 7y ago
        No, wavelength is just one more dimension along which intensity may vary (in addition to X, and Y, and time), not five or six more dimensions, so a multi-band image is only three-dimensional, regardless of whether there are three wavelength bands (like RGB or YCbCr), four (like RGBA), 8 (like Landsat), or 210 (like HYDICE, AVIRIS, and other imaging spectrometers).
333c 7y ago
> The number result is 0.008333333333 with the 3 repeating forever. For a computer to store a number that repeats forever would require an infinite amount of memory This is very much not true, as I'm sure other HN readers will notice. The number is rational (it's equivalent to 1/120). Now, it is true that a floating point number may not be able to represent it exactly, but by no means does this number require "infinite memory." In fact I have represented the number exactly in this comment, which does not take up infinite space. For irrational numbers, sure, they cannot be exactly represented. But there are no irrationals involved in this article. I got hung up at this point in the article, so I haven't finished it yet, but it looks like the author goes on to argue that because numbers like the above cannot be represented in computer memory at all, errors will always accumulate in representations of audio/video. This makes me question whether the author understands the problem they are writing about. Edit: the author does in fact state that rational numbers can be represented by a numerator and a denominator. The article is actually about errors the accumulate during floating point operations. It ends up making a decent argument despite false claims about representing numbers in memory.
- slimscsi 7y ago
  Thanks for the comment. For the record, I am very aware of iee 754, And I am aware that some numbers that have infinite repetition in decimal can have an exact representation. I actually thought about pointing that out. However I decided that it didn't add much to the post. It was written for more of a general audience and diving into those details, while would make the post more technically correct, would not actually add any value for the average reader.
  - saagarjha 7y ago
    I don't want to come off as combative, but I would argue that a correction would add quite a bit to the post. What you have is straight-up incorrect and wouldn't even take that much effort to fix. "For a computer to store the decimal representation a number that repeats forever would require an infinite amount of memory, so the number is approximated" would be correct and it's just a couple words more.
blackencino 7y ago
Hi! I'm Chris Horvath, the author of Flicks, formerly of Facebook/Oculus, currently at Cruise Automation. I'm happy to answer any questions about my most-talked-about-single-line-of-code.
- enriquto 7y ago
  can you point us to that single line of code? is it stored in a git somewhere?
  - speps 7y ago
    https://github.com/OculusVR/Flicks https://github.com/OculusVR/Flicks
  - hoseja 7y ago
    It's the using flicks = std::chrono::duration<std::chrono::nanoseconds::rep, std::ratio<1, 705600000>>;
    - blackencino 7y ago
      That’s the one!!!
      - chrisweekly 7y ago
        "A flick (frame-tick) is a very small unit of time. It is 1/705600000 of a second, exactly. 1 flick = 1/705600000 second This unit of time is the smallest time unit which is LARGER than a nanosecond, and can in integer quantities exactly represent a single frame duration for 24 Hz, 25 Hz, 30 Hz, 48 Hz, 50 Hz, 60 Hz, 90 Hz, 100 Hz, 120 Hz, and also 1/1000 divisions of each, as well as a single sample duration for 8 kHz, 16 kHz, 22.05 kHz, 24 kHz, 32 kHz, 44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz, and 192kHz, as well as the NTSC frame durations for 24 (1000/1001) Hz, 30 * (1000/1001) Hz, 60 * (1000/1001) Hz, and 120 * (1000/1001) Hz.* That above was one hell of a run-on sentence, but it's strictly and completely correct in its description of the unit. This makes flicks suitable for use via std::chrono::duration and std::ratio for doing timing work against the system high resolution clock, which is in nanoseconds, but doesn't get slightly out of sync when doing common frame rates." https://github.com/OculusVR/Flicks https://github.com/OculusVR/Flicks
anonymfus 7y ago
In real modern video files every frame has its own timecode, and mobile phones typically record with variable framerate when these timecodes are placed highly irregularly (the reason can be a lack of performance or an attempt to sync with light source of the different frequency than camera's settings). Any new video editing software is expected to deal with such files, and flicks are useless here.
- slimscsi 7y ago
  I’m not sure I’d agree here. RTPM is probably the most popular live streaming protocol, and it typically has huge variations in instantaneous frames rates. However it’s time base is hard coded to 1/1000. Which means it can’t even accurately represent 30fps. Flicks would be at least a massive improvement here. And even given variable frame rate, a time base must be chosen in advance, so flicks is at least as good as any other value.
Brett_S 7y ago
For those looking for the original news article here is a link to it on HN https://news.ycombinator.com/item?id=16210670 https://news.ycombinator.com/item?id=16210670.
jcelerier 7y ago
Heh, I've started to use it in https://ossia.io https://ossia.io just two weeks ago. Works fine for what it is.
kidintech 7y ago
why is a least common multiple news and a concept that we love/hate??
mikorym 7y ago
> there was no leap day in the year 1900 Tell that to the management over at Microsoft. [1] [1] https://docs.microsoft.com/en-us/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year https://docs.microsoft.com/en-us/office/troubleshoot/excel/w...

141 points by slimscsi 7y ago

Computer scientists with a physics background might recognize the syncing problem to the challenge of describing simultaneous events. https://en.wikipedia.org/wiki/Relativity_of_simultaneity https://en.wikipedia.org/wiki/Relativity_of_simultaneity

robolange 7y ago

Did you leave that unbalanced paren in the [Hacker News] title just to drive Lisp users mad? Edit: Thanks for the fix!

tlb 7y ago
Fixed, thanks.

0x0 7y ago

The article's leap year rules seem wrong. Pretty sure year 2000 did have a leap day, but 1900 didn't.

colechristensen 7y ago
>Every 4 years, we get an extra day at the end of February, unless the year is divisible by 400 (there was no leap day in the year 2000). The article has it backwards. Years divisible by 400 get leap days, others divisible by 100 do not.
teilo 7y ago
Yep. The algorithm is: there is a leap day for every year divisible by 4, unless the year is also divisible by 100. But if the year is divisible by 400, then there is a still leap day.
- jacksnipe 7y ago
  Oh shit, it’s FizzBuzz!
  - hermitdev 7y ago
    Yeah, you really dont want to be implementing a date/time library yourself. It is a far more complex problem than Fizzbuzz. There is so much nuance and easy to overlook details. Just determining whether or not a year is a leap year is about discuss complexity. I wrote a friendlier abstraction over top Boost DateTime in C++ at a previous employer. Adding things like cross platform support of using the Olson database for historical timezone info, a friendlier interface (more akin to Python's datetime lib, which is probably the friendliest datetime lib Ive used across any language) and cross platform strptime. So, didn't do the heavy lifting myself, but rather supplied the timezone info. There were so many subtle details. Like, what does it mean to add 1 day to a timestamp? Do you increment year/month/day as needed to be the next day? Or do you add 24 hours? This matters because if you increment the date only, you can end up with an invalid or ambiguous time. I also appreciate the author mentioning how many hours are there in a day. 23, 24 and 25 are most common for jurisdictions observing daylight saving time, but arbitrary shifts are possible. It depends on the jurisdiction. Take the US for example. It depends not just on the state, but sometimes even the county within a state. Some states dont observe DST (Arizona and Hawaii, maybe others). Parts of Indiana do, some don't (maybe this has changed). Compound this with changes to when DST starts/ends. Its entirely political and can change on a whim. I know there are clocks that are still wrong 12 years later for 6 weeks of the year because of the 2007 US DST change, because of embedded rules for when to change. Sorry for the rant. Spent over 18 months on that project, and I know there are bugs in there nobody bothered to fix after I left that company (fractional seconds handling in strptime I ported from NetBSD, I'm looking at you).
    - jancsika 7y ago
      > Yeah, you really dont want to be implementing a date/time library yourself. Someone should make a date/time "meta library" which iterates through all possible system time values while calling each extant language's date/time method at each iteration. Then report the system time values for which there are discrepancies in the output.
slimscsi 7y ago
You are correct! I will fix that
quickthrower2 7y ago
I pity those born on 29/02/00

fishgoat 7y ago

Good article, with a couple of minor errors: "Audio recorded at 44100khz" should be 44.100 kHz or 44100 Hz. "there was no leap day in the year 2000" - false. 2000 is divisible by both 400 and 100, so it was a leap year.

slimscsi 7y ago
fixed, thank you!
lonelappde 7y ago
> divisible by both 400 OK > and 100 We'd be in real trouble if not!

escardin 7y ago

The reason you don't see flicks used all that much is because media encoding is incredibly proprietary in the space where it matters most, live broadcast. Selling into the broadcast space, every broadcaster has petabytes of video in their own chosen format. You have to support EVERY format to sell broadly, and they're not going to let you transcode everything into your format. Using flicks gives you the ability to support as many combinations as possible with the least effort. It matters very little when users are trained to tolerate slow transitions between videos, formats, etc... It also doesn't matter a whole lot when doing offline transcoding either, as you can afford to do the more expensive calculation.

mike_hock 7y ago
Even for live broadcast, how can a few integer instructions matter? If you have to compare timestamps every audio sample, that's a few multiplications every 22 microseconds (common denominator can be computed once). Or am I completely off here?
- escardin 7y ago
  Trying to realtime encode 4k into AVC using pure software encoders takes about 80 cores/hyperthreads. Then you need to meet the tight 70ns? timings of the SMPTE 2022-6/7 protocols (i.e. 12gbps without using jumbo frames because reasons). It's also necessary for clip switching. If you want frame accurate clip switching (i.e. show->ad->ad->show) you need consistent and precise pointers into your files.

kazinator 7y ago

> That is 367.5 times more audio samples than video frames. Okay, but an audio sample is not comparable to a frame of video, which by itself means something to the viewer. (But, on the other hand which probably doesn't differ much from the previous or next one, especially at 120 Hz). An audio sample is sort of more comparable to a pixel.

slimscsi 7y ago
Its comparing 1 dimensional space to 2 demential space. So, any comparison is gong to be a little hand wavy. But temporally, I believe the comparison is apt.
- kragen 7y ago
  > Its comparing 1 dimensional space to 2 demential space Although I love the coinage "2 demential space", I think you mean "comparing one-dimensional space [audio] to three-dimensional space [video]". A two-dimensional signal might be a still image or a temporal sequence of samples from a one-dimensional array of sensors, such as those in a single slice of a CT machine or a linear MIMO antenna array. A video signal is three-dimensional, not two-dimensional, and probably not "2 demential" either.
  - slimscsi 7y ago
    Including pixel intensity, you are correct. Infact it has thee planes, so you could even call it 9 demential If you break it down that way.
    - kragen 7y ago
      No, wavelength is just one more dimension along which intensity may vary (in addition to X, and Y, and time), not five or six more dimensions, so a multi-band image is only three-dimensional, regardless of whether there are three wavelength bands (like RGB or YCbCr), four (like RGBA), 8 (like Landsat), or 210 (like HYDICE, AVIRIS, and other imaging spectrometers).

333c 7y ago

> The number result is 0.008333333333 with the 3 repeating forever. For a computer to store a number that repeats forever would require an infinite amount of memory This is very much not true, as I'm sure other HN readers will notice. The number is rational (it's equivalent to 1/120). Now, it is true that a floating point number may not be able to represent it exactly, but by no means does this number require "infinite memory." In fact I have represented the number exactly in this comment, which does not take up infinite space. For irrational numbers, sure, they cannot be exactly represented. But there are no irrationals involved in this article. I got hung up at this point in the article, so I haven't finished it yet, but it looks like the author goes on to argue that because numbers like the above cannot be represented in computer memory at all, errors will always accumulate in representations of audio/video. This makes me question whether the author understands the problem they are writing about. Edit: the author does in fact state that rational numbers can be represented by a numerator and a denominator. The article is actually about errors the accumulate during floating point operations. It ends up making a decent argument despite false claims about representing numbers in memory.

slimscsi 7y ago
Thanks for the comment. For the record, I am very aware of iee 754, And I am aware that some numbers that have infinite repetition in decimal can have an exact representation. I actually thought about pointing that out. However I decided that it didn't add much to the post. It was written for more of a general audience and diving into those details, while would make the post more technically correct, would not actually add any value for the average reader.
- saagarjha 7y ago
  I don't want to come off as combative, but I would argue that a correction would add quite a bit to the post. What you have is straight-up incorrect and wouldn't even take that much effort to fix. "For a computer to store the decimal representation a number that repeats forever would require an infinite amount of memory, so the number is approximated" would be correct and it's just a couple words more.

blackencino 7y ago

Hi! I'm Chris Horvath, the author of Flicks, formerly of Facebook/Oculus, currently at Cruise Automation. I'm happy to answer any questions about my most-talked-about-single-line-of-code.

enriquto 7y ago
can you point us to that single line of code? is it stored in a git somewhere?
- speps 7y ago
  https://github.com/OculusVR/Flicks https://github.com/OculusVR/Flicks
- hoseja 7y ago
  It's the using flicks = std::chrono::duration<std::chrono::nanoseconds::rep, std::ratio<1, 705600000>>;
  - blackencino 7y ago
    That’s the one!!!
    - chrisweekly 7y ago
      "A flick (frame-tick) is a very small unit of time. It is 1/705600000 of a second, exactly. 1 flick = 1/705600000 second This unit of time is the smallest time unit which is LARGER than a nanosecond, and can in integer quantities exactly represent a single frame duration for 24 Hz, 25 Hz, 30 Hz, 48 Hz, 50 Hz, 60 Hz, 90 Hz, 100 Hz, 120 Hz, and also 1/1000 divisions of each, as well as a single sample duration for 8 kHz, 16 kHz, 22.05 kHz, 24 kHz, 32 kHz, 44.1 kHz, 48 kHz, 88.2 kHz, 96 kHz, and 192kHz, as well as the NTSC frame durations for 24 (1000/1001) Hz, 30 * (1000/1001) Hz, 60 * (1000/1001) Hz, and 120 * (1000/1001) Hz.* That above was one hell of a run-on sentence, but it's strictly and completely correct in its description of the unit. This makes flicks suitable for use via std::chrono::duration and std::ratio for doing timing work against the system high resolution clock, which is in nanoseconds, but doesn't get slightly out of sync when doing common frame rates." https://github.com/OculusVR/Flicks https://github.com/OculusVR/Flicks

anonymfus 7y ago

In real modern video files every frame has its own timecode, and mobile phones typically record with variable framerate when these timecodes are placed highly irregularly (the reason can be a lack of performance or an attempt to sync with light source of the different frequency than camera's settings). Any new video editing software is expected to deal with such files, and flicks are useless here.

slimscsi 7y ago
I’m not sure I’d agree here. RTPM is probably the most popular live streaming protocol, and it typically has huge variations in instantaneous frames rates. However it’s time base is hard coded to 1/1000. Which means it can’t even accurately represent 30fps. Flicks would be at least a massive improvement here. And even given variable frame rate, a time base must be chosen in advance, so flicks is at least as good as any other value.

Brett_S 7y ago

For those looking for the original news article here is a link to it on HN https://news.ycombinator.com/item?id=16210670 https://news.ycombinator.com/item?id=16210670.

jcelerier 7y ago

Heh, I've started to use it in https://ossia.io https://ossia.io just two weeks ago. Works fine for what it is.

kidintech 7y ago

why is a least common multiple news and a concept that we love/hate??

mikorym 7y ago

> there was no leap day in the year 1900 Tell that to the management over at Microsoft. [1] [1] https://docs.microsoft.com/en-us/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year https://docs.microsoft.com/en-us/office/troubleshoot/excel/w...