31–40 of 94 posts
Its weird to think how John Carmack went from .plan files to Facebook Posts. I think it might be safe to say he had the most widely read .plan file in existence. Wish he would go back to it.
Earlier quoted context omitted.
You think someone is telling Carmack where he can and can't post? Why one earth would they do that? And why on earth would he put up with it?
More that the company’s culture says you should post things using the company’s platform, and to not do so might be making a statement he doesn’t want to make. Otherwise, why would he move away from .plan?
> This is usually visible as ugly banding or blocking in dark scenes. I was just complaining about this a couple weeks ago with some friends after the “Dark” episode of GoT. I was saying the codecs don’t seem to have caught up or they are just being fed at too low a bit rate to really excel at dark scenes. It’s hard to imagine this is just a scaling issue with the color ranges, and if so, how could it possibly not ha…
>I have a high end OLED screen in a very dark room, and I was very disappointed by the picture quality. Unfortunately for you, high end OLED in a very dark room is literally the most likely conditions under which you'd be annoyed by these problems... :-) HDR is the way to go.
Perhaps bitrate compromises have to be made when you’re streaming to so many people at once, but it’s not usually so glaring.
No one is nearly as interested in Carmack's thoughts on codecs as they are about the domain name of the server he's posting to.
And yet, we'd all read his stuff no matter where he puts it. But maybe he reaches more outsiders this way? I doubt it.
Earlier quoted context omitted.
You think someone is telling Carmack where he can and can't post? Why one earth would they do that? And why on earth would he put up with it?
More that the company’s culture says you should post things using the company’s platform, and to not do so might be making a statement he doesn’t want to make. Otherwise, why would he move away from .plan?
> This is usually visible as ugly banding or blocking in dark scenes. I was just complaining about this a couple weeks ago with some friends after the “Dark” episode of GoT. I was saying the codecs don’t seem to have caught up or they are just being fed at too low a bit rate to really excel at dark scenes. It’s hard to imagine this is just a scaling issue with the color ranges, and if so, how could it possibly not ha…
https://news.avclub.com/was-game-of-thrones-the-long-night-t...
The ffmpeg documentation for YouTube videos[1] suggests using `-pix_fmt yuv420p` with H.264 and there are warnings against using other pixel formats (such as yuv444p) for compatibility reasons. Should the documentation instead be suggesting `-pix_fmt yuvj420p`? What are the risks associated with choosing that output format? [1]: https://trac.ffmpeg.org/wiki/Encode/YouTube
The ffmpeg documentation for YouTube videos[1] suggests using `-pix_fmt yuv420p` with H.264 and there are warnings against using other pixel formats (such as yuv444p) for compatibility reasons. Should the documentation instead be suggesting `-pix_fmt yuvj420p`? What are the risks associated with choosing that output format? [1]: https://trac.ffmpeg.org/wiki/Encode/YouTube
No, limited range is the most common and expected range for YUV videos. Many players don't look or respect the container metadata such as nclx in MP4 or the bitstream VUI flags and assume limited range.
> For arcane reasons related to TV broadcast limitations, many video formats restrict the YUV color components to be in the 16..235 or 16..240 range instead of the full 0..255 range. Losing 14% of the already-barely-enough 8 bit dynamic range is bad enough, but it also often results in the black range starting at a quite visible grey value because most players don’t rescale the range. This is usually visible as ugly banding or blocking in dark scenes.
Of course players "rescale" the range. (It's not exactly rescaling, it's just that a value of 235 IS reference white in Rec. 709.) In fact, the thought if them not doing this is kind of crazy, as Rec. 709 (used in Blurays and elsewhere) as well as Rec. 601 explicitly use limited range YUV. Players that don't use limited range correctly would be out of spec and couldn't play a single Bluray disc correctly. So for the overwhelming majority of use cases, you want regular old yuv420p.
The author is picking up on something that actually happens, however. There are Blurays out there that have incorrectly converted YUV values. This happens when for example something is in limited range YUV, and then that data is passed to a converter that treats the data as full range YUV, and compresses it again to fit in limited range YUV. This "doubly compressed" data is embarrassingly common (maybe 5% or so of Blurays have this problem). If you get a Bluray like this, or any video with the same issue, the blacks will be bright grays and the whites will be dull (similar to how the author describes limited range YUV). The player on the end is reading the YUV values correctly, but the data has been doubly compressed so it only undoes one round of this.
The issue is well known in the pirate communities as an example. Reliable release groups always fix these broken Blurays in their encodes. This is usually described as "fixing levels" or something like that.