Falsehoods programmers believe about video (opens in new tab)

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.

Okay, so how are subtitles different?

This comment is pretty much what I was going for. I've reworded it to make it clearer.

The issue you can run into in practice is stuff like softsubbed signs, which can clash and look out of place with the native video if you render them at full res. There's also a related issue, which is that if you're using something like motion interpolation (e.g. “smoothmotion”, “fluidmotion” etc. or even stuff like MVTools/SVP), softsubbed signs will not match the video during pans etc., making them stutter and look very out-of-place - the only way to fix that is to render them on top of the video before applying the relevant motion interpolation algorithms.

Personally I've always wished for a world in which subtitles are split into two files, one for dialogue and for signs, with an ability to distinguish between the two. (Heck, I think softsubbed signs should just be separate transparent video streams that are overlayed on top of the native picture, allowing you to essentially hardsub signs while still being capable of disabling them)

Also, sometimes, rendering at full resolution is prohibitively expensive, e.g. watching heavily softsubbed 720p content on a 4K screen.

> 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.

Sure, you have to transform the coordinates to the output. But still, better to render fonts at the final resolution; they'll always look better than if scaled after rendering.

But sometimes your government expects names to be broken into given and family names (the US, Japan, and China all seem to make this assumption -- every government form I've seen from those countries wants your name fully broken out).

I've no direct experience with, say, Russian or Latin American governments, but cultures that use explicit patronymic or matronymic names might expect that broken out as well.

If you ever need to submit user data to the government (e.g. for tax reasons), and you don't ask your user to break the name apart, then you will necessarily be guessing, which seems strictly worse than just asking them how their name might split.

At the end of the day, if you operate in a given culture, then you need to address those cultural norms. Bending over backwards to support every possible edge case seems unwise if they also happen to disagree with those norms.

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

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

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...

As a Spaniard I have two last names (no middle name, no one last name with space) but 0% of the non-spanish websites I have ever seen accommodate for this.

Normally I just use it with an space in the last name field, but then I get exactly the same problems you mention.

For EMRs, the HL7 FHIR HumanName datatype covers most of what's needed. Patients can have 0 or more names, each of which can have a full string representation plus 0 or more separate family / given / prefix / suffix components. And each name can be tagged with a usage type (official / maiden / nickname / etc) and validity date range.

http://www.hl7.org/FHIR/datatypes.html#HumanName

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".

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

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

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

It's true that examples and explanations would be nice and make for a more helpful guide, but those can usually be found with a bit of legwork, whereas the gotchas themselves are often only discovered by trial and error. In essence, don't look a gift horse in the mouth.

A better approach would be to pick the list up and turn them into a collaborative work. Wiki, maybe?

> Chroma subsampling isn't going anywhere. You'll usually get subjectively better quality with 4:2:0 chroma compared to 4:4:4 at the same bitrate. And this means you can't have everything in RGB, so all the colorspace conversion complexity can't be ignored.

What's more, YCbCr is more efficiently compressed than RGB even if you don't subsample, for the same reason that a DCT saves bits even if you don't quantize: Linearly dependent or redundant information is moved into fewer components, in this case most of the information moves into the Y channel with the Cb and Cr both being very flat in comparison. (Just look at a typical YCbCr image reinterpreted as grayscale to see what I meant)

you are right, there is a weird grainy sharpness kind of 'feeling' when chroma is not subsampled...

but you get the exact same effect from higher resolutions, e.g. going from SD->HD->2K->4K we see the same thing... and we are still doing it, so i would question highly that it is subjectively better in a long-term sense given this continuing trend.

i remember hearing people discuss this sort of thing when HD was new, and they stopped after while - i suspect because they got used to it, and they now realise how low the quality of the SD image was. i noticed this in myself as well...

edit: incidentally there is a discussion about this here (first google thing i found): http://www.neogaf.com/forum/showthread.php?t=1308591

its seems either nobody or very few are taking the perspective that 4:2:0/4:2:2 looks better, and there are even a few descriptions of precisely what they notice as being worse.

er... what? can you explain that a bit i think i must misunderstand?

what i think of as undershooting or overshooting is relative to the range... and besides that, what is wrong with clamping? its how computer graphics has always had to deal with these things... limited range simply doesn't exist in that context, and it doesn't harm anything.

when computer games are forced into limited range for consoles you don't get these unless your tv is applying one of those god awful filters that ruins everything anyway... (i'm still not sure why so many tvs have these - reference monitors never do anything this insane) ... but i can tell you what you do get, a subjectively /and/ measurably worse quality of image than from a monitor.

(i don't think i'm alone in this based on the contents of the ITU-R BT.2100 either... which defines a full range as well as a 'narrow' one)

> 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.

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. 2) You are now going to have to be buffering a couple seconds worth of uncompressed video somewhere, probably not on the GPU, leading to a much higher I/O bandwidth requirement somewhere that isn't good at that, so this is only probably going to be sort of parallel (FWIW, I believe most people who try to do parallel video decoding are assuming that they can have different parts of the encoder concentrate on different sections of the screen, which sounds good until you see how non-local video decoding can be).

seems to be easy, but each frame depends on previous frames... so now you need to share lots of data between threads. its not as embarrassingly parallel as it looks from a naive perspective.

although i contend that most decoders are very threadable - just that the people trying to do it usually lack the time or the skill, more usually the former.

the state of video in programming is a total mess from my experiences.

Decoding frames ahead of time gives no benifit to a user watching the video. The problem is how to decode a single frame in parallel. Contrary to the video expressed elsewhere, hardware decoders run a lot in parallel. As MultiCoreWare pointed out, one of the biggest challenges is latency.

That's like saying fractal images are not information. Just because something is generated by a formula, doesn't mean it's not new information.