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

21–30 of 139 posts

Re: Falsehoods programmers believe about video

#21

Post by agumonkey »

franciscop wrote: post #18

The original one ( http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... ) left me bafled. Then I realized you have to strike a balance; otherwise you cannot deal with names at all. The point where drawing the line depends on your industry/customers, but I'd safely say that it's too restrictive nowadays so these lists are useful somewhat and of course they are interesting.

Wasn't there one about time and timezones ?

So many mundane things have the "how hard can this be" ..

Re: Falsehoods programmers believe about video

#22

Post by Camillo »

kazagistar wrote: post #12
kdeldycke wrote: post #7

Earlier quoted context omitted.

Managed to compile a list of these at: https://github.com/kdeldycke/awesome-falsehood#awesome-false...

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.

Re: Falsehoods programmers believe about video

#23

Post by kirillkh »

mojuba wrote: post #20
inopinatus wrote: post #8

Earlier quoted context omitted.

Perhaps there is scope for a list of Falsehoods Programmers Believe About Falsehoods Programmers Believe.

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.

2. There exists a "Falsehoods Programmers Believe" list that is entirely true.

Re: Falsehoods programmers believe about video

#25

Post by progval »

agumonkey wrote: post #21
franciscop wrote: post #18

The original one ( http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... ) left me bafled. Then I realized you have to strike a balance; otherwise you cannot deal with names at all. The point where drawing the line depends on your industry/customers, but I'd safely say that it's too restrictive nowadays so these lists are useful somewhat and of course they are interesting.

Wasn't there one about time and timezones ? So many mundane things have the "how hard can this be" ..

http://infiniteundo.com/post/25509354022/more-falsehoods-pro...

Re: Falsehoods programmers believe about video

#26

Post by derefr »

> 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 tiny blurry mess instead of the crisp, readable text they could be.

Re: Falsehoods programmers believe about video

#29

Post by pdkl95 »

msandford wrote: post #16
the8472 wrote: post #13

Earlier quoted context omitted.

> 1) You are now assuming that "seeking to a position will produce the same output as decoding to a position"; even if the video is well-formed (and you don't end up with massive issues where the key frames just don't work correctly) you are likely going to end up with subtle discontinuities between every segment. Wouldn't "the keyframes just don't work correctly" result in corrupted output anyway? If we're worrying…

I think the point is that video definitely is that broken and the only reason video does work is because everyone has work-arounds for everyone else's bugs. At least that's my experience with video. It's all a disaster.

I believe[1] this isn't necessarily about broken files. There is a lot of variation allowed by the spec. One example that I've seen in the wild is extra-long (> 60 seconds) periods between I-frames. Seeking to an arbitrary point either requires searching backwards from the seek-point for an I-frame and storing a massive amount of RAM. As this usually isn't possible and would require decoding hundreds of frames, decoding may cheat and make do with as many P and B frames as it can handle.

[1] I haven't actually read most of the h.265 spec. It's possible these are technically invalid files.

Re: Falsehoods programmers believe about video

#30

Post by kibwen »

franciscop wrote: post #18

The original one ( http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... ) left me bafled. Then I realized you have to strike a balance; otherwise you cannot deal with names at all. The point where drawing the line depends on your industry/customers, but I'd safely say that it's too restrictive nowadays so these lists are useful somewhat and of course they are interesting.

It's true that you have to draw a line somewhere based on technical and business constraints, but an important takeaway of the names article is that you almost certainly don't need to do anything with a name other than treat it as an opaque string that can be displayed back to the user. For example, I'm struggling to think of a good reason why user registration would require separate first name and last name fields, and yet this practice is overwhelmingly common. For that matter, why do you want my real name at all, considering that it can't be used as a unique ID anyway?
Post reply on HN