
In defense of 'flicks' (or how I learned to stop worrying and love 705600000) - slimscsi
https://mux.com/blog/in-defense-of-flicks-or-how-i-learned-to-stop-worrying-and-love-705600000/
======
blackencino
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
can you point us to that single line of code? is it stored in a git somewhere?

~~~
hoseja
It's the

    
    
        using flicks = std::chrono::duration<std::chrono::nanoseconds::rep, std::ratio<1, 705600000>>;

~~~
blackencino
That’s the one!!!

~~~
chrisweekly
" _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)

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

------
fishgoat
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
fixed, thank you!

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

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

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

------
mikorym
> 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/w...](https://docs.microsoft.com/en-
us/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year)

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

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

~~~
slimscsi
My point is, I am comparing temporal dimension to temporal dimension
regardless of how many special dimensions there are. And I don’t understand
the argument that an audio sample is more analogous to a pixel that it is a
frame on a time line.

~~~
kragen
It's analogous to both, from different valid points of view.

~~~
lonelappde
In particular, in data processing, all dimensionality is equivalent, since and
infinite set S the same cardinality as S^n for any whole number n, and any
finite set is smaller than the 1-dimensional set of naturals.

~~~
kragen
Yeah, at least if Hilbert spaces can fuck off, which is why we can approximate
signal processing on digital computers at all. And, because of space-filling
curves, in some sense ℝ _ⁿ_ is equivalent to ℝ. But, to understand signal
processing, a much more useful point of view is that ℝ _ⁿ_ is significantly
different for different values of _n_ , but not completely unrelated; and ℤ
_ⁿ_ is a useful approximation of ℝ _ⁿ_ , as is (ℤ/ _m_ ℤ) _ⁿ_.

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

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

~~~
tlb
Fixed, thanks.

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

~~~
teilo
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
Oh shit, it’s FizzBuzz!

~~~
hermitdev
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
> 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.

------
333c
> 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
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
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.

~~~
kragen
Agreed.

