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.

This is correct. In fact, the following statement from the post is nonsense:

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

Interesting post!

I have one question about terminology though: when you refer to “players“, do you mean all kinds of players or just physical hardware devices like Blu-ray players?

I ask because I haven’t had/observed any issues or defects with colour in software/PC-based desktop serious at all.

Disclaimer: not in the Blu-ray-authoring business.

It’s pretty easy to verify: create a uniform white png and convert it to yuv420p h264 via ffmpeg:

ffmpeg -i input.png -pix_fmt yuv420p movie.mp4

Open in VLC or your favourite player and take a screenshot. Now check with a color picker whether you have white as 255 or 235.

Update: checked with VLC and QuickTime Player, both handled it correctly and displayed white as 255.

I'm referring to both. It's more likely, I suppose, that software players could have problems in this area, but that's simply because many of them are free and they don't have to pass any kind of certification process. As a matter of fact, all well known software players I've encountered seem to do this right. Regular limited range YUV works pretty much everywhere. Doubly compressed YUV (the encoding mistake I was talking about) works nowhere because the data in the file is incorrect and has to be manually filtered to repair the damage.

Wow! Talladega nights was the first movie I saw on a Bluray setup. (PS3 at a friends.) I was shocked at how badly mastered it was. It sounds exactly like that problem. Everything was washed out.

Yeah, that was one of the first Blurays that ever came out, as I recall. Another issue that you often see with those early ones is that they're actually encoded with the MPEG-2 video codec (H.262), same as DVDs. That's allowed under the Bluray spec, but of course anything released these days is going to use H.264 with vastly better picture quality as a result.

I didn’t know about MPEG2 in Bluray. Still, with higher bitrate?

This.

Carmack is in the wrong here.