Not able to change any advanced video playback settings in VLC or Potplayer

[Russ10]

If I go to preferences in either, and I pick a random setting from "video" in either preferences menu, none of the settings change anything even after saving and restarting the playing video. Is something wrong with my graphics card (AMD Radeon RX 5700)? Am I just missing a save button somewhere? The color controls sliders alone work if I switch to the OpenGL decoder in Potplayer. Specifically, I am trying to control whether the displayed range is limited or full.

That brings me to another question, how come most "8-bit" video ranges from RGB values 16-235, which means it is only using about 97% of the possible color depth in the file? Why does it not use the whole bit depth available?

[butterw]

Please be more precise as to what you are trying to change (and how).
In VLC Tools > Effects and Filters only applies to dx11 Video Output (and you need to restart the player to change the video output).

Limited Range in video is a remnant of the TV/Broadcast era. If your video file/gpu driver/monitor is setup in the correct mode, range expansion will happen automatically at playback.
You can use the full range if you encode your own files (how is limited range 97% color ?).

The best way to check for range is with a SMPTE ColorBarsHD test pattern input: https://github.com/butterw/bShaders/blob/master/test_LimitedRange/Readme.md avs_rec.709_720p-full.png (for full-range 8bit rgb32)
on screen with a RGB pixel picker, and with your eyes/a calibration device.

[jagabo]

none of the settings change anything even after saving and restarting

Try running VLC as admin.

That brings me to another question, how come most "8-bit" video ranges from RGB values 16-235, which means it is only using about 97% of the possible color depth in the file? Why does it not use the whole bit depth available?

Limited range is the international standard. It leaves a little overhead for transient overshoots. Limited range YUV is converted to full range RGB on-the-fly during playback.

[Russ10]

Please be more precise as to what you are trying to change (and how).
In VLC Tools > Effects and Filters only applies to dx11 Video Output (and you need to restart the player to change the video output).

Limited Range in video is a remnant of the TV/Broadcast era. If your video file/gpu driver/monitor is setup in the correct mode, range expansion will happen automatically at playback.
You can use the full range if you encode your own files (how is limited range 97% color ?).

The best way to check for range is with a SMPTE ColorBarsHD test pattern input: https://github.com/butterw/bShaders/blob/master/test_LimitedRange/Readme.md avs_rec.709_720p-full.png (for full-range 8bit rgb32)
on screen with a RGB pixel picker, and with your eyes/a calibration device.

The exact number could range depending on how you calculate it but if you look at the total number of colors, you get a way worse number. 10.5m/16.7m colors = 63% of the possible colors. And even if my monitor displays it correctly, all my stored videos are probably stored like that for no reason, which is kind of confusing.

And I'm not aiming to do anything specific at this point, just get any setting to work. But, if restarting the player is required, that might be where I was going wrong.

[jagabo]

The exact number could range depending on how you calculate it but if you look at the total number of colors, you get a way worse number. 10.5m/16.7m colors = 63% of the possible colors.

It's actually much worse than that. If you look at the RGB cube inside the YUV cube you'll see that even within the limited range (YCbCr) most YUV colors do not lead to valid RGB values:



Only about 1/6 of the 16 million possible YUV combinations map to valid RGB values. Even within the limited range cube only about 1/4 the colors map to valid RGB values.

The stated range for YUV, 16-235 for luma, 16-240 for chroma, correspond to the the eight corners of the RGB cube. For example, at full white, the top of the RGB cube in the diagram, Y=235, only one U and one V value are valid, 128. Any other U or V values will be outside the RGB cube.

[butterw]

It seems to me that with limited range 8bit video, only about 7bit of range are effectively usable for encoding, meaning lower quality for the same bitrate vs full range (ex: with x264).

[jagabo]

It seems to me that with limited range 8bit video, only about 7bit of range are effectively usable for encoding, meaning lower quality for the same bitrate vs full range (ex: with x264).

While that's true, the rest of the world uses limited range YUV: dvd, blu-ray, youtube, vimeo, netflix, all the other commercial streaming services... And players as a rule don't pay attention to the limited/full range flag. You'll have to switch levels manually every time you play one of your own encodings. It's better to stick with the standard. The good news is that limited range 10 bit HEVC is pretty well supported across most platforms now. So you can encode your 8 bit sources as 10 bit HEVC to get better playback. But 10 bit AVC isn't well supported, it's best to avoid that.

[butterw]

Certainly limited range is much more common in current encoded content. But in my experience, PC players (at least) can also handle tagged full range videos without any issues.

[Cornucopia]

The "limited" range was designed to allow for overshoot/undershoot. Full range doesn't allow for that. That's why full is fine for CGI but not necessarily for captured real images.
Now, how limited gets translated to full is another matter (hard clipping vs S-curve graduated knee, etc).

Also, you mentioned "8bit", but remember that's 8bit/color primary (or color channel), which usually equates to 24bit (less if 4:2:2 or even less if 4:2:0). But even if you didn't look at it that way, 2^7 = 128 values, while 2^8 restricted to 16-235 = 219 values. I wouldn't called that "effectively 7bits".

Scott

[butterw]

with limited range: 7.69bit per channel instead of 8.

[Russ10]

It seems to me that with limited range 8bit video, only about 7bit of range are effectively usable for encoding, meaning lower quality for the same bitrate vs full range (ex: with x264).

While that's true, the rest of the world uses limited range YUV: dvd, blu-ray, youtube, vimeo, netflix, all the other commercial streaming services... And players as a rule don't pay attention to the limited/full range flag. You'll have to switch levels manually every time you play one of your own encodings. It's better to stick with the standard. The good news is that limited range 10 bit HEVC is pretty well supported across most platforms now. So you can encode your 8 bit sources as 10 bit HEVC to get better playback. But 10 bit AVC isn't well supported, it's best to avoid that.

What exactly do you mean by encoding 8 bit sources as 10 bit HEVC? Wouldn't recording them at 8 bit already hinder the possible color depth?

[jagabo]

What exactly do you mean by encoding 8 bit sources as 10 bit HEVC? Wouldn't recording them at 8 bit already hinder the possible color depth?

Yes, but deblocking can happen in 10 bit YUV so you'll get smoother gradients. The resulting 10 bit HEVC will be converted to 8 bit RGB with more discreet intermediats. The conversion from 8 bit RGB to 10 bit YUV (even limited range) back to 8 bit RGB can be lossless (aside from compression losses). The conversion from 8 bit RGB to 8 bit YUV (even full range) back to 8 bit RGB cannot be lossless -- it loses ~5 of every 6 colors with limited range YUV, ~3 of every 4 for full range YUV.

[Russ10]

What exactly do you mean by encoding 8 bit sources as 10 bit HEVC? Wouldn't recording them at 8 bit already hinder the possible color depth?

Yes, but deblocking can happen in 10 bit YUV so you'll get smoother gradients. The resulting 10 bit HEVC will be converted to 8 bit RGB with more discreet intermediats. The conversion from 8 bit RGB to 10 bit YUV (even limited range) back to 8 bit RGB can be lossless (aside from compression losses). The conversion from 8 bit RGB to 8 bit YUV (even full range) back to 8 bit RGB cannot be lossless -- it loses ~5 of every 6 colors with limited range YUV, ~3 of every 4 for full range YUV.

I want to understand what you mean but I think I need some kind of visual explanation.

[Sharc]

What does actually happen to Y,Cb,Cr triplets which represent illegal RGB values? Are the values clipped at the RGB inner cube borders, or does some other distortion materialize? Does it depend on the monitor? How do today's TVs handle these? Any easy way to demonstrate the effect?

[jagabo]

What does actually happen to Y,Cb,Cr triplets which represent illegal RGB values? Are the values clipped at the RGB inner cube borders, or does some other distortion materialize? Does it depend on the monitor? How do today's TVs handle these? Any easy way to demonstrate the effect?

These days most software and hardware will clamp the values. Values over 255 are all clamped to 255, values below 0 are all clamped to 0. Some older software and hardware would "wrap around". 256 would become 0, 257 would become 2, 258 would become 3, -1 would become 255, -2 would become 254, -3 would become 253, etc.

[jagabo]

What exactly do you mean by encoding 8 bit sources as 10 bit HEVC? Wouldn't recording them at 8 bit already hinder the possible color depth?

Yes, but deblocking can happen in 10 bit YUV so you'll get smoother gradients. The resulting 10 bit HEVC will be converted to 8 bit RGB with more discreet intermediats. The conversion from 8 bit RGB to 10 bit YUV (even limited range) back to 8 bit RGB can be lossless (aside from compression losses). The conversion from 8 bit RGB to 8 bit YUV (even full range) back to 8 bit RGB cannot be lossless -- it loses ~5 of every 6 colors with limited range YUV, ~3 of every 4 for full range YUV.

I want to understand what you mean but I think I need some kind of visual explanation.

Say you have an 8 bit 8x8 macroblock that has U increasing from 100 at the left edge to 101 at the right edge. The deblocker may interpolate that as:

100 100 100 100 101 101 101 101

With 10 bit components the two edges would be at 400 and 404. The deblocker might give:

400 401 401 402 402 403 403 404

When converted to 8 bit RGB for display, the latter has the possibility of more intermediate shades.

[Sharc]

What does actually happen to Y,Cb,Cr triplets which represent illegal RGB values? Are the values clipped at the RGB inner cube borders, or does some other distortion materialize? Does it depend on the monitor? How do today's TVs handle these? Any easy way to demonstrate the effect?

These days most software and hardware will clamp the values. Values over 255 are all clamped to 255, values below 0 are all clamped to 0. Some older software and hardware would "wrap around". 256 would become 0, 257 would become 2, 258 would become 3, -1 would become 255, -2 would become 254, -3 would become 253, etc.

Thank you. This explains why I experienced the effect differently in the past when the player probably wrapped the values around.

Example for BT.601 (hope I got it right):

[Attachment 56504 - Click to enlarge]

[Sharc]

This brings me to another question:
Can files with legal (and unclipped) Y,Cb,Cr values but partially illegal RGB values be 'adjusted' with the TV settings (brightness, saturation, contrast or whatever the fancy TV settings are called) for correct (or pleasant) playback, or would these files have to be re-encoded to legal RGB colors for undistorted playback?

[jagabo]

This brings me to another question:
Can files with legal (and unclipped) Y,Cb,Cr values but partially illegal RGB values be 'adjusted' with the TV settings (brightness, saturation, contrast or whatever the fancy TV settings are called) for correct (or pleasant) playback...?

Usually, yes.