Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mux.com

Post reply on HN
Print view View original

61–66 of 66 posts

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

#61

Post by escardin »

mike_hock wrote: post #46
escardin wrote: post #12

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 su…

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?

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.

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

#62

Post by swiley »

jwilk wrote: post #57
swiley wrote: post #36

Earlier quoted context omitted.

You can represent most useful irrational numbers on computers via programs that calculate them to the required degree of precision: You can represent pi: 4*atan(1) e: log(1) Now I feel like you could make arguments about non-computable numbers, although I feel like you could still “represent” them.

log(1) = 0 I think you meant exp(1).

Darn, as much as I hate editing posts that old I do wish I could correct that.

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

#63

Post by chrisweekly »

blackencino wrote: post #53
hoseja wrote: post #50

Earlier quoted context omitted.

It's the using flicks = std::chrono::duration >;

That’s the one!!!

"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

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

#64

Post by lonelappde »

fishgoat wrote: post #8

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.

> divisible by both 400

OK

> and 100

We'd be in real trouble if not!

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

#65

Post by lonelappde »

kragen wrote: post #60
slimscsi wrote: post #33

Earlier quoted context omitted.

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.

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

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.

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

#66

Post by kragen »

lonelappde wrote: post #65
kragen wrote: post #60

Earlier quoted context omitted.

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

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.

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ℤ)ⁿ.
Post reply on HN