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

Falsehoods programmers believe about video

haasn.xyz

Post reply on HN
Print view View original

101–110 of 139 posts

Re: Falsehoods programmers believe about video

#101

Post by DonHopkins »

deadmutex wrote: post #86
smnscu wrote: post #85

Earlier quoted context omitted.

I have to change my CC settings every damn couple of days because they revert to the same white-on-white 400% bullshit. So thanks for that.

I am not sure, but the screenshot I submitted seems to be the default settings. However, software that is 100% perfect is pretty much impossible to write, and if you think there's a systematic issue, please file a bug, so it can help others in same situation.

I am absolutely sure I never changed my settings, and that they have changed over time without me doing anything. Why would anyone want 50% font size at 25% opacity on a yellow then green background? I didn't ask for that. Yes, this is most definitely a systematic issue.

The bug reports I've submitted to google have been ignored, and that's a frustrating distraction from what I'm paid to do. Maybe if you submit one yourself, somebody will pay attention, because google is paying you to work on youtube, and hopefully they will take you more seriously than their users.

Re: Falsehoods programmers believe about video

#102

Post by simias »

unscaled wrote: post #5
nhaehnle wrote: post #2

This is a good list, but it would be so much better with some (brief) pointers to counter-examples to the beliefs.

This unfortunately follows the conventions of the genre called "Falsehood programmers believe about X": http://spaceninja.com/2015/12/08/falsehoods-programmers-beli... I honestly think this genre is horrible and counterproductive, even though the writer's intentions are good. It gives no examples, no explanations, no guidelines for proper implementations - just a list of condescending gotchas, showing off the superio…

I agree, I think this format works when the subject matter is trivial enough that it's easy to construct counter examples yourself once the contradiction is pointed out.

The "Name" version is a good example of that, I can easily see how most of the examples on this list can be falsehoods.

On the other hand in TFA some of the affirmations leave me more perplexed. For instance, regarding color conversion: "converting from A to B is just the inverse of converting from B to A". I wonder what's meant here. Is it just a matter of rounding or is there more to it than that?

The catch 22 here is that if you understand this list then chances are you already knew about most of these gotchas.

So yeah, a pretty bad format. Now we just have to write "`Falsehood programmers believe about X` considered harmful".

Re: Falsehoods programmers believe about video

#104

Post by pwdisswordfish »

Camillo wrote: post #22
kazagistar wrote: post #12

Earlier quoted context omitted.

Is this a real response to the parent post? As in, is your list curated to provide actual examples and meaningful tips, or is it just an even bigger pile of useless condescension?

Presumably the post being replied to was at the top of the page at the time of the reply.

So what if it was? The reply still doesn't address the point raised by kazagistar. I looked at kdeldycke's list and some examples in fact do address it, but there's nothing in his comment to indicate it. It's not an unreasonable question to make.

Re: Falsehoods programmers believe about video

#106

Post by pwdisswordfish »

unscaled wrote: post #47
mojuba wrote: post #20

Earlier quoted context omitted.

Let's start then: 1. Everything said in every "Falsehoods Programmers Believe..." list is true. The Falsehoods sound like ultimate truths only because of the literary genre. They sound like they were written by an expert who not only knows what's true, but also knows what we think we know, which kind of automatically takes him/her to the next level of expertise.

3. Every falsehood that is true should be accounted for. 4. Every falsehood that is true CAN be accounted for. 5. Making your code compatible with a falsehood doesn't come with a price. 6. There are no falsehoods which are mutually exclusive.

> Every falsehood that is true

Hmm.

Re: Falsehoods programmers believe about video

#107

Post by pedrocr »

the8472 wrote: post #99
pedrocr wrote: post #42

Earlier quoted context omitted.

A single uncompressed frame of 1080p video occupies 28MB in RAM, so 1 minute of 24fps video will take up 40GB. If you want to be able to run 4 cores at once it's 3 times that. You won't be doing that any time soon on your laptop or smartphone.

The maximum number of references frames, i.e. how much the Decoded Picture Buffer has to hold, is 16. So even if a GOP is 1 minute long you would have to hold at most 16 pictures in memory to have enough information to stream over that 1-minute segment. So I still do not see how this would prohibit parallel processing.

Not sure how that would work. You have a thread that's decoding the frames 1 minute in front of where playback is, so if you're not decoding full frames and storing them until you need to display them what is that thread doing?

Re: Falsehoods programmers believe about video

#108

Post by pedrocr »

gkop wrote: post #73
pedrocr wrote: post #42

Earlier quoted context omitted.

A single uncompressed frame of 1080p video occupies 28MB in RAM, so 1 minute of 24fps video will take up 40GB. If you want to be able to run 4 cores at once it's 3 times that. You won't be doing that any time soon on your laptop or smartphone.

Curious as to your math? My naive thinking is 1920 * 1080 * 8 (generous) bytes is around 16MB.

I forgot where I got 28 from but it's indeed a mistake. For normal display you could get away with 1920 * 1080 * 8bit = 6MB. For a 10bit display it would be around 8MB. You do indeed often use 32bit float for high-quality processing but since what we're storing here is the output frame you would finish all that processing and then go down to 8 or 10bit per channel. So recalculating the math that's 8GB for 1 minute of video, still way too impractical.

Re: Falsehoods programmers believe about video

#109

Post by the8472 »

pedrocr wrote: post #107
the8472 wrote: post #99

Earlier quoted context omitted.

The maximum number of references frames, i.e. how much the Decoded Picture Buffer has to hold, is 16. So even if a GOP is 1 minute long you would have to hold at most 16 pictures in memory to have enough information to stream over that 1-minute segment. So I still do not see how this would prohibit parallel processing.

Not sure how that would work. You have a thread that's decoding the frames 1 minute in front of where playback is, so if you're not decoding full frames and storing them until you need to display them what is that thread doing?

transcoding or video editing in slices is a common application.

you cut the video into a handful of parts at keyframes, process the parts individually in a streaming manner and then splice the partial results together.

If we're talking about playback then creating seeking-thumbnails could similarly benefit from parallel processing.

Re: Falsehoods programmers believe about video

#110

Post by the8472 »

derefr wrote: post #26

> rendering subtitles at the output resolution is better than rendering them at the video resolution I would like to know what's wrong with this approach. I watch a lot of commentated speed-run videos: that's often something like ~244p video, plus soft subtitles. The subtitles get rendered at the source resolution (presumably, into the video framebuffer) and then upscaled along with the image, forcing them to be a ti…

In fact, rendering subtitles at the display resolution is one of the big selling points of the xy-subfilter + madvr renderer combination.

The only practical downside I have noticed is that accurate rendering of subs containing complex vector graphics or effects (ASS supports that) at > HD resolutions takes a lot of CPU time, sometimes more than a single core can handle in realtime.

There probably is a lot of potential for optimization, but those are hobby projects for their maintainers.

Post reply on HN