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

31–40 of 139 posts

Re: Falsehoods programmers believe about video

#31

Post by Frondo »

kibwen wrote: post #30
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,…

That's easy, it's to make better marketing materials.

"Dear [first name]," flows better than "Dear [opaque string],".

Re: Falsehoods programmers believe about video

#32

Post by kibwen »

Frondo wrote: post #31
kibwen wrote: post #30

Earlier quoted context omitted.

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

That's easy, it's to make better marketing materials. "Dear [first name]," flows better than "Dear [opaque string],".

That's what the marketing department may believe, but in reality that's super creepy. Let's not pretend that I'm on a friendly first-name basis with corporations, or that in reality I'm anything more than an autogenerated numeric ID in a database as far as the corporation is concerned. Furthermore, nobody but my mother calls me by my real first name, and this holds for half of my cohort. And why does any company think that their marketing correspondence is welcome in the first place?

Re: Falsehoods programmers believe about video

#33

Post by JoshTriplett »

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.

Yeah, the same applies to many of the falsehoods in this list. Some of them you have to get right; some of them you can probably ignore without causing practical problems.

Re: Falsehoods programmers believe about video

#34

Post by JoshTriplett »

Frondo wrote: post #31
kibwen wrote: post #30

Earlier quoted context omitted.

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

That's easy, it's to make better marketing materials. "Dear [first name]," flows better than "Dear [opaque string],".

I've run into a couple of sites that ask for "nickname" or "preferred form of address", which you could store as a separate opaque string, if you really want that.

Re: Falsehoods programmers believe about video

#35

Post by the8472 »

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.

Many of the listed points in TFA are not about broken-ness. A good chunk cover rarely-used features or less commonly used codecs for advanced applications.

Re: Falsehoods programmers believe about video

#36

Post by kibwen »

JoshTriplett wrote: post #34
Frondo wrote: post #31

Earlier quoted context omitted.

That's easy, it's to make better marketing materials. "Dear [first name]," flows better than "Dear [opaque string],".

I've run into a couple of sites that ask for "nickname" or "preferred form of address", which you could store as a separate opaque string, if you really want that.

Yes, I'd so much rather have an explicit nickname field if a company wants to insist on calling me anything other than my username.

Re: Falsehoods programmers believe about video

#37

Post by Frondo »

JoshTriplett wrote: post #34
Frondo wrote: post #31

Earlier quoted context omitted.

That's easy, it's to make better marketing materials. "Dear [first name]," flows better than "Dear [opaque string],".

I've run into a couple of sites that ask for "nickname" or "preferred form of address", which you could store as a separate opaque string, if you really want that.

That's great, that's an even better solution. I like that. If I'm ever in a position to make a recommendation about this sort of thing again, I'll use that idea.

Re: Falsehoods programmers believe about video

#38

Post by the8472 »

pdkl95 wrote: post #29
msandford wrote: post #16

Earlier quoted context omitted.

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, decod…

a 1-minute span for I-frames would not be prohibitive for parallel processing that the quotes part was referring to, with a 60-minute video it would still give you 60 segments to process in parallel.

Re: Falsehoods programmers believe about video

#39

Post by kazinator »

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…

Maybe nothing is wrong; just that maybe it's not always strictly better. Suppose you are asked to form a plan for adding subtitle support to some unfamiliar video platform. It's probably best to start with an open mind about where in the pipeline subtitles will be composed with the video.

Re: Falsehoods programmers believe about video

#40

Post by akiselev »

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…

I think that point should be amended to say "rendering subtitles at the output resolution is always better than rendering them at the video resolution." You don't want to upscale 244p soft subtitles to 1080p but you do want to default to giving video authors creative control over how the subtitles are displayed. The ASS subtitle format allows for some very complex styling that can be used as an artistic element in video (or just to make sure there's proper contrast, can be read by color blind people, character differentiation, etc.) so you generally don't want to assume anything. There's also the issue of coordinates for where the subtitles are supposed to be that all go to shit if you render them on a transformed (up/downscaled) frame.
Post reply on HN