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.
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.<p>It matters very little when users are trained to tolerate slow transitions between videos, formats, etc...<p>It also doesn't matter a whole lot when doing offline transcoding either, as you can afford to do the more expensive calculation.
Good article, with a couple of minor errors:<p>"Audio recorded at 44100khz" should be 44.100 kHz or 44100 Hz.<p>"there was no leap day in the year 2000" - false. 2000 is divisible by both 400 and 100, so it was a leap year.
Computer scientists with a physics background might recognize the syncing problem to the challenge of describing simultaneous events.<p><a href="https://en.wikipedia.org/wiki/Relativity_of_simultaneity" rel="nofollow">https://en.wikipedia.org/wiki/Relativity_of_simultaneity</a>
For those looking for the original news article here is a link to it on HN <a href="https://news.ycombinator.com/item?id=16210670" rel="nofollow">https://news.ycombinator.com/item?id=16210670</a>.
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.
> there was no leap day in the year 1900<p>Tell that to the management over at Microsoft. [1]<p>[1] <a href="https://docs.microsoft.com/en-us/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year" rel="nofollow">https://docs.microsoft.com/en-us/office/troubleshoot/excel/w...</a>
Heh, I've started to use it in <a href="https://ossia.io" rel="nofollow">https://ossia.io</a> just two weeks ago. Works fine for what it is.
> <i>That is 367.5 times more audio samples than video frames.</i><p>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).<p>An audio sample is sort of more comparable to a pixel.
> 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<p>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 <i>not</i> take up infinite space.<p>For irrational numbers, sure, they cannot be exactly represented. But there are no irrationals involved in this article.<p>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.<p>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.