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

71–80 of 139 posts

Re: Falsehoods programmers believe about video

#71

Post by justinlaster »

wstrange wrote: post #9
justinlaster wrote: post #6

> a H.264 hardware decoder can decode all H.264 files and > video decoding is easily parallelizable At a previous job, I don't know if it was just the field I was in or just bad luck, but having to explain this over and over again was kind of a personal nightmare. That being said, this is an excellent list!

Curious - Why is this? Does this assume streaming video, and you can't look ahead in the stream? If you can jump ahead, it would seem to be easy to have multiple threads, starting at key frames to decode the content. You'd have to splice them together, but this seems possible.

> it would seem to be easy to have multiple threads, starting at key frames to decode the content.

It's a resource issue (memory, cpu, etc; and meeting latency requirements between those constraints), versus the subtly different standards "H.264" hardware and software follow, as well as a few other intricacies with how the whole standard works anyways. Again, it's not that it can't be done, but as the article says it can't be done easily or at least in certain situations done consistently.

Key frames are a good anchor around anything you're doing with H264 (and other formats), but it's not the end all and be all -- and they may even cause you trouble if you "trust" them too much. It is perhaps a bit like date time programming. You can create something fairly easily that works for a decent amount of time, and even if it ends up being incorrect your clients may not even notice... or it may breakdown in a catastrophic manner in the future. But doing the latter is certainly not correct and it's certainly not professional. Quite honestly, I'd say date time programming looks like a dream compared to the inconsistent nightmare that is video programming. Date/time logic needs to be sound because many programs rely on consistent and sane output from a program perspective, where as video programming gets to slide as long as the output is generally correct from a human visual perspective.

It's been a few years since I've dived into this stuff, so some things may have changed/gotten cleaned up. But the article seems to indicate that the ecosystem hasn't really changed.

Re: Falsehoods programmers believe about video

#72

Post by gkop »

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.

Yes, this. Working with video is as though there were no such thing as a documented API or standards document, but instead, you find the longest-lived bugs in the popular toolchains and in the clients of your customers, and those bugs are the foundation of the interfaces you implement.

Re: Falsehoods programmers believe about video

#73

Post by gkop »

pedrocr wrote: post #42
the8472 wrote: post #38

Earlier quoted context omitted.

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.

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.

Re: Falsehoods programmers believe about video

#74

Post by tantalor »

CoolGuySteve wrote: post #44
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…

It's also missing the most common error I see: conflating subtitles with closed captions. Closed captions are positioned on the screen to indicate who's talking, have descriptive audio for sound effects, and should be in a high contrast easy to read font (most people with hearing deficiencies also have problems seeing, ie: out of date prescriptions for both hearing aids and eye glasses). As far as I know, QuickTime d…

Okay, so how are subtitles different?

Re: Falsehoods programmers believe about video

#75

Post by TazeTSchnitzel »

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…

Aren't the falsehoods inherently guidelines? They give you an idea of which assumptions aren't safe to make.

Re: Falsehoods programmers believe about video

#76

Post by jeff_tyrrill »

imaginenore wrote: post #53

> interlaced video files no longer exist Interlaced video files should no longer exist. Seriously, f k interlaced video. > upscaling algorithms can invent information that doesn’t exist in the image That's not a falsehood. Upscaling does invent information that doesn't exist in the image.

> Interlaced video files should no longer exist.

Yes, they should, as should silent movies, black and white movies, old game consoles with exotic output formats like vector graphics, and the like.

It is a worthy endeavor to create and maintain video playback software that lets people consume beloved content that was made to the technology of its day, including home videos, sports games, TV shows with special effects edited in 60i, and video games.

Re: Falsehoods programmers believe about video

#77

Post by scottlamb »

From the article:

> I can exclusively use the video clock for timing

Heh. I just finished writing up a design doc to address problems I had with this, and I referenced "Falsehoods programmers believe about time". Then I opened Hacker News and saw this article. So this is very timely for me.

(My doc: https://github.com/scottlamb/moonfire-nvr/blob/new-schema/de...)

Re: Falsehoods programmers believe about video

#78

Post by pvdebbe »

iopq wrote: post #14

> my hardware contexts will survive the user’s coffee break hell, they don't survive alt-tabbing into a game that has a different resolution than the monitor

Heh... for some reason youtube can't survive when I start a video on my monitor and then I switch outputs to TV using an xrandr script by closing one output and opening the other. I thought it was possible to continue the video that way but once I noticed it doesn't work, it made sense immediately.

Mplayer and co, on the other hand can cope with it but my window manager can mess it up so I don't bother.

Re: Falsehoods programmers believe about video

#79

Post by deoxxa »

deadmutex wrote: post #65
CoolGuySteve wrote: post #44

Earlier quoted context omitted.

It's also missing the most common error I see: conflating subtitles with closed captions. Closed captions are positioned on the screen to indicate who's talking, have descriptive audio for sound effects, and should be in a high contrast easy to read font (most people with hearing deficiencies also have problems seeing, ie: out of date prescriptions for both hearing aids and eye glasses). As far as I know, QuickTime d…

AFAIK, The YouTube implementation does all of those. Here is a demo: https://www.youtube.com/watch?v=BbqPe-IceP4 Please do not spread falsehoods. Disclamer: I work at YouTube.

http://take.ms/fwwhx

That is frustratingly poor contrast.

Re: Falsehoods programmers believe about video

#80

Post by sdenton4 »

innocentoldguy wrote: post #61
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.

People's names is one area I think developers constantly bugger up. For example, my last name has a space in it, but half the websites I register on either: 1. Throw an error and won't let me enter my last name as it is supposed to be spelled. 2. Truncate the last part of my last name. 3. Try to be clever and end up shoving the first half of my last name into a middle-name field. My preference for names, addresses, a…

I'm a fourth, and occasionally the IV suffix gets horribly mishandled. I recently booked a flight on Travelocity and had to change arrangements by looking up the reservation on the actual airline air, but it turned out they had dropped the space between my last name and the IV, making it impossible for me to log in until I figured out what had gone wrong...
Post reply on HN