8 ms·

Falsehoods programmers believe about video

250 points by pomfpomfpomf3 10y ago

nhaehnle 10y ago
This is a good list, but it would be so much better with some (brief) pointers to counter-examples to the beliefs.
- unscaled 10y ago
  This unfortunately follows the conventions of the genre called "Falsehood programmers believe about X": http://spaceninja.com/2015/12/08/falsehoods-programmers-believe/ 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 superior intellect and perception of the author.
  - kdeldycke 10y ago
    Managed to compile a list of these at: https://github.com/kdeldycke/awesome-falsehood#awesome-falsehood- https://github.com/kdeldycke/awesome-falsehood#awesome-false...
    - kazagistar 10y ago
      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?
      - deleted 10y ago
        [deleted]
      - Camillo 10y ago
        Presumably the post being replied to was at the top of the page at the time of the reply.
        pwdisswordfish 10y ago
        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.
  - inopinatus 10y ago
    Perhaps there is scope for a list of Falsehoods Programmers Believe About Falsehoods Programmers Believe.
    - mojuba 10y ago
      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.
      - kirillkh 10y ago
        2. There exists a "Falsehoods Programmers Believe" list that is entirely true.
      - unscaled 10y ago
        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.
        pwdisswordfish 10y ago
        > Every falsehood that is true Hmm.
    - kdeldycke 10y ago
      Love that idea! Please help me compile a list there: https://github.com/kdeldycke/kevin-deldycke-blog/blob/master/content/posts/falsehoods-programmers-believe-about-falsehoods-lists.md https://github.com/kdeldycke/kevin-deldycke-blog/blob/master... :)
  - icebraining 10y ago
    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?
  - TazeTSchnitzel 10y ago
    Aren't the falsehoods inherently guidelines? They give you an idea of which assumptions aren't safe to make.
  - simias 10y ago
    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".
    - dom0 10y ago
      > I wonder what's meant here. Is it just a matter of rounding or is there more to it than that? Many colour spaces are non-overlapping, ie. one colour space has colours a different colour space simply doesn't have, so converting between them is often lossy and thus non-invertible.
      - dragonwriter 10y ago
        > Many colour spaces are non-overlapping, ie. one colour space has colours a different colour space simply doesn't have Wouldn't that be overlapping but non-coextensive? Non-overlapping would be no colors in common between color spaces, which would be odd.
        dom0 10y ago
        Yes. I didn't realize that difference between my intermediate language and the output language of these comments :)
- tedunangst 10y ago
  Just reimagine it as "implicit assumptions to check for". From my limited experience in the field, a lot of these are things I know (or knew) but could easily forget in the midst of trying to get code to work.
- imsofuture 10y ago
  I hate the smug attitude of things like this. I get they're trying to raise awareness of a thing, but maybe take a moment to educate, instead of just smugly dunking on people about how much more you know about a thing that they don't.
smallnamespace 10y ago
This article would be infinitely better if it any provided counterexamples.
tuxidomasx 10y ago
This list makes me not want to program any [video stuff]
justinlaster 10y ago
> 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!
- wstrange 10y ago
  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.
  - saurik 10y ago
    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).
    - the8472 10y ago
      > 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 about already-broken situations then it is quite obvious that additional breakage may occur in related features.
iopq 10y ago
> 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
- pvdebbe 10y ago
  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.
donatj 10y ago
- "all subtitle files are UTF-8 encoded" Hah, this strikes really close to home. I've had to work with so so many subtile files in Eastern European and Turkish Windows codepages mostly but not entirely compatible with Win-1252. There's no way to tell them apart programmatically, so you check that the extended characters make sense. It's a bit of a nightmare.
franciscop 10y ago
The original one ( http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ 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.
- agumonkey 10y ago
  Wasn't there one about time and timezones ? So many mundane things have the "how hard can this be" ..
  - progval 10y ago
    http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time http://infiniteundo.com/post/25509354022/more-falsehoods-pro...
- JoshTriplett 10y ago
  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.
- kibwen 10y ago
  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?
  - Frondo 10y ago
lolc 10y ago
And this is why I don't do video. (And have lots of respect for the people who write the libraries I use.)
AznHisoka 10y ago
can we have falsehoods programmers believe besides video that are more common? this list probably is relevant for 1% of programmers here.
- greenyoda 10y ago
  Just type "falsehoods programmers believe" into the search box at the bottom of the page and you'll get a ton of previous articles on falsehoods in various domains that have been posted here over the years: https://hn.algolia.com/?query=falsehoods%20programmers%20believe&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=falsehoods%20programmers%20bel... And while this topic is not personally relevant to me since I don't work with video decoding, I do find learning about different technologies interesting. Reading this gives me an appreciation for how much effort goes into making video, something we all take for granted, work. If people only posted articles that were relevant to a majority of readers, HN would be a much less interesting place.
- fgandiya 10y ago
  Here's a whole list! https://github.com/kdeldycke/awesome-falsehood/blob/master/README.md https://github.com/kdeldycke/awesome-falsehood/blob/master/R...
derefr 10y ago
> 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.
- kazinator 10y ago
  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.
- akiselev 10y ago
  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.
  - haasn 10y ago
    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.
FranOntanaya 10y ago
Could write an entire page just on subtitles.
milansuk 10y ago
Nice one! Now I would like to see article like this, but about ciphers, hashes, digital signitures, etc.
jheriko 10y ago
it is true, video is a nightmare mess littered with weird functionality nobody needs. (limited range only just disappeared in rec 2100, optionally??? really??? i'm not worried about my electron gun in my CRT from 1975 these days...nor do i want to know what a Y or a Cb or a Cr means because everything is RGB and B&W TV is long dead... and 4:2:2 is not exactly compression so much as computational overhead etc.. etc.) its a nightmare, but the reason for these observations is precisely that it shouldn't be a nightmare. this area of programming is a wasteland ... nobody that good wants to solve these trivial problems :/
- mrob 10y ago
  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. Try experimenting with chroma subsampling in JPGs, but note that not all image viewers have good chroma upscaling. MPV can display still images as well as video and you can choose the chroma scaling algorithm.
  - haasn 10y ago
    > 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)
    - jheriko 10y ago
      isn't it the case that amount of data required to store the result of a lossless DCT is bounded below by the size of the data, and this is why lossless JPG compression does not use such a scheme?
imaginenore 10y ago
> interlaced video files no longer exist Interlaced video files should no longer exist. Seriously, fk 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.
- mrob 10y ago
  "Information" in the information theory sense. The output of a deterministic upscaling algorithm can be exactly described by the input and the algorithm. There's no added information, only a different way of presenting the original information.
- emcq 10y ago
  Perhaps that author was being pendantic, but from an information theroetic perspective it is correct that you cannot invent information with upscaling. The upscaled image does not have more information than what was in the original image; you can reconstruct the upscaled image given only the information available in the original image, the output resolution dimensions, and upscaling algorithm.
  - imaginenore 10y ago
    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.
- jeff_tyrrill 10y ago
  > 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.
ryanmarsh 10y ago
Well video programming just sounds delightful. /sarcasm
scottlamb 10y ago
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/design/time.md https://github.com/scottlamb/moonfire-nvr/blob/new-schema/de...)
microcolonel 10y ago
I don't think programmers believe any of the video decoding falsehoods; not because they know any better, but because they know they don't know. Also, none of these unfounded preconceptions make intuitive sense, so I don't see why people would believe them.
the_duke 10y ago
An explanation for each 'falsehood' would have been nice
deleted 10y ago
[deleted]
antirez 10y ago
There is a lot of potential information in such a list. But in this form is quite a "trust me" thing that does not really add to the reader knowledge.

250 points by pomfpomfpomf3 10y ago

nhaehnle 10y ago

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

unscaled 10y ago
This unfortunately follows the conventions of the genre called "Falsehood programmers believe about X": http://spaceninja.com/2015/12/08/falsehoods-programmers-believe/ 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 superior intellect and perception of the author.
- kdeldycke 10y ago
  Managed to compile a list of these at: https://github.com/kdeldycke/awesome-falsehood#awesome-falsehood- https://github.com/kdeldycke/awesome-falsehood#awesome-false...
  - kazagistar 10y ago
    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?
    - deleted 10y ago
      [deleted]
    - Camillo 10y ago
      Presumably the post being replied to was at the top of the page at the time of the reply.
      - pwdisswordfish 10y ago
        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.
- inopinatus 10y ago
  Perhaps there is scope for a list of Falsehoods Programmers Believe About Falsehoods Programmers Believe.
  - mojuba 10y ago
    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.
    - kirillkh 10y ago
      2. There exists a "Falsehoods Programmers Believe" list that is entirely true.
    - unscaled 10y ago
      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.
      - pwdisswordfish 10y ago
        > Every falsehood that is true Hmm.
  - kdeldycke 10y ago
    Love that idea! Please help me compile a list there: https://github.com/kdeldycke/kevin-deldycke-blog/blob/master/content/posts/falsehoods-programmers-believe-about-falsehoods-lists.md https://github.com/kdeldycke/kevin-deldycke-blog/blob/master... :)
- icebraining 10y ago
  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?
- TazeTSchnitzel 10y ago
  Aren't the falsehoods inherently guidelines? They give you an idea of which assumptions aren't safe to make.
- simias 10y ago
  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".
  - dom0 10y ago
    > I wonder what's meant here. Is it just a matter of rounding or is there more to it than that? Many colour spaces are non-overlapping, ie. one colour space has colours a different colour space simply doesn't have, so converting between them is often lossy and thus non-invertible.
    - dragonwriter 10y ago
      > Many colour spaces are non-overlapping, ie. one colour space has colours a different colour space simply doesn't have Wouldn't that be overlapping but non-coextensive? Non-overlapping would be no colors in common between color spaces, which would be odd.
      - dom0 10y ago
        Yes. I didn't realize that difference between my intermediate language and the output language of these comments :)
tedunangst 10y ago
Just reimagine it as "implicit assumptions to check for". From my limited experience in the field, a lot of these are things I know (or knew) but could easily forget in the midst of trying to get code to work.
imsofuture 10y ago
I hate the smug attitude of things like this. I get they're trying to raise awareness of a thing, but maybe take a moment to educate, instead of just smugly dunking on people about how much more you know about a thing that they don't.

smallnamespace 10y ago

This article would be infinitely better if it any provided counterexamples.

tuxidomasx 10y ago

This list makes me not want to program any [video stuff]

justinlaster 10y ago

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

wstrange 10y ago
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.
- saurik 10y ago
  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).
  - the8472 10y ago
    > 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 about already-broken situations then it is quite obvious that additional breakage may occur in related features.

iopq 10y ago

> 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

pvdebbe 10y ago
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.

donatj 10y ago

- "all subtitle files are UTF-8 encoded" Hah, this strikes really close to home. I've had to work with so so many subtile files in Eastern European and Turkish Windows codepages mostly but not entirely compatible with Win-1252. There's no way to tell them apart programmatically, so you check that the extended characters make sense. It's a bit of a nightmare.

franciscop 10y ago

The original one ( http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ 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.

agumonkey 10y ago
Wasn't there one about time and timezones ? So many mundane things have the "how hard can this be" ..
- progval 10y ago
  http://infiniteundo.com/post/25509354022/more-falsehoods-programmers-believe-about-time http://infiniteundo.com/post/25509354022/more-falsehoods-pro...
JoshTriplett 10y ago
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.
kibwen 10y ago
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?
- Frondo 10y ago

lolc 10y ago

And this is why I don't do video. (And have lots of respect for the people who write the libraries I use.)

AznHisoka 10y ago

can we have falsehoods programmers believe besides video that are more common? this list probably is relevant for 1% of programmers here.

greenyoda 10y ago
Just type "falsehoods programmers believe" into the search box at the bottom of the page and you'll get a ton of previous articles on falsehoods in various domains that have been posted here over the years: https://hn.algolia.com/?query=falsehoods%20programmers%20believe&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=falsehoods%20programmers%20bel... And while this topic is not personally relevant to me since I don't work with video decoding, I do find learning about different technologies interesting. Reading this gives me an appreciation for how much effort goes into making video, something we all take for granted, work. If people only posted articles that were relevant to a majority of readers, HN would be a much less interesting place.
fgandiya 10y ago
Here's a whole list! https://github.com/kdeldycke/awesome-falsehood/blob/master/README.md https://github.com/kdeldycke/awesome-falsehood/blob/master/R...

derefr 10y ago

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

kazinator 10y ago
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.
akiselev 10y ago
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.
- haasn 10y ago
  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.

FranOntanaya 10y ago

Could write an entire page just on subtitles.

milansuk 10y ago

Nice one! Now I would like to see article like this, but about ciphers, hashes, digital signitures, etc.

jheriko 10y ago

it is true, video is a nightmare mess littered with weird functionality nobody needs. (limited range only just disappeared in rec 2100, optionally??? really??? i'm not worried about my electron gun in my CRT from 1975 these days...nor do i want to know what a Y or a Cb or a Cr means because everything is RGB and B&W TV is long dead... and 4:2:2 is not exactly compression so much as computational overhead etc.. etc.) its a nightmare, but the reason for these observations is precisely that it shouldn't be a nightmare. this area of programming is a wasteland ... nobody that good wants to solve these trivial problems :/

mrob 10y ago
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. Try experimenting with chroma subsampling in JPGs, but note that not all image viewers have good chroma upscaling. MPV can display still images as well as video and you can choose the chroma scaling algorithm.
- haasn 10y ago
  > 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)
  - jheriko 10y ago
    isn't it the case that amount of data required to store the result of a lossless DCT is bounded below by the size of the data, and this is why lossless JPG compression does not use such a scheme?

imaginenore 10y ago

> interlaced video files no longer exist Interlaced video files should no longer exist. Seriously, fk 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.

mrob 10y ago
"Information" in the information theory sense. The output of a deterministic upscaling algorithm can be exactly described by the input and the algorithm. There's no added information, only a different way of presenting the original information.
emcq 10y ago
Perhaps that author was being pendantic, but from an information theroetic perspective it is correct that you cannot invent information with upscaling. The upscaled image does not have more information than what was in the original image; you can reconstruct the upscaled image given only the information available in the original image, the output resolution dimensions, and upscaling algorithm.
- imaginenore 10y ago
  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.
jeff_tyrrill 10y ago
> 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.

ryanmarsh 10y ago

Well video programming just sounds delightful. /sarcasm

scottlamb 10y ago

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/design/time.md https://github.com/scottlamb/moonfire-nvr/blob/new-schema/de...)

microcolonel 10y ago

I don't think programmers believe any of the video decoding falsehoods; not because they know any better, but because they know they don't know. Also, none of these unfounded preconceptions make intuitive sense, so I don't see why people would believe them.

the_duke 10y ago

An explanation for each 'falsehood' would have been nice

deleted 10y ago

[deleted]

antirez 10y ago

There is a lot of potential information in such a list. But in this form is quite a "trust me" thing that does not really add to the reader knowledge.