How can I solve a weird colour range problem?

[bergqvistjl]

I have a blu-ray disc whereby some of the videos appear to have had their color range flagged incorrectly.

First off, my Monitor & Graphics card are both outputting at Full RGB range (0 - 255) & the colours are correctly balanced (i.e. I haven't got one of those on the wrong setting).

When I play one of the videos which isn't having the prolem (m2ts file, h264) in DGAVCIndex, the color is correct, and the YUV->RGB setting is set to PC Scale (i.e. Full).

Yet whenever I play one of the problematic videos in the same manor, the color is darker. However the problem goes away if I switch YUV-RGB to TV Scale (i.e. Limited) in DGAVCIndex. The frames & color level matches up entirely with the unaffected videos (with those playing on PC scale - if i switch those to TV scale, they are unnaturally bright).

So I thought that the prolematic videos have their header flags set incorrectly for the RGB range, yet both them and the unaffected videos have the same color information in the header flags according to MediaInfo: Colorimetry : 4:2:0
Color space : YUV
Chroma subsampling : 4:2:0 - and the video_full_range_flag is set to 0 on both.

So what could be the cause of the color problems in the problematic videos?

And more importantly, can I fix the colour to match that in the unaffected videos, without having to re-encode the h264 streams? (Remuxing is fine).

I've tried to set the video_full_range_flag to true using this tool: http://forum.doom9.org/showthread.php?t=152419 and MediaInfo recognised that the flag had changed, yet it had no effect.

What can I do?

[foxyshadis]

It's quite possible that the video was actually stretched to full range before encoding without being flagged so. The fix in that case would be to edit the full range flag to 1, but you have to use a player that actually honors the flag, like MPDN or MPC-HC with EVR or MadVR, and LAV filters as the decoder.

To verify if that's actually the case, you have to get access to the raw YUV and check its histogram. AvsPmod is a good tool for that, and other editing needs.

[bergqvistjl]

It's quite possible that the video was actually stretched to full range before encoding without being flagged so. The fix in that case would be to edit the full range flag to 1, but you have to use a player that actually honors the flag, like MPDN or MPC-HC with EVR or MadVR, and LAV filters as the decoder.

To verify if that's actually the case, you have to get access to the raw YUV and check its histogram. AvsPmod is a good tool for that, and other editing needs.

That looks to be the case - it was stretched to full range, when it shouldn't have been (the unaffected videos also don't have the full range flag set) Is there a way to fix the colour without having to set the full-range flag to true? Or would I have to re-encode the video track to do this?

[sneaker_ger]

Either you
a) re-encode or
b) set the flag and use a player that cares about it or
c) manually adjust your player (madVR keyboard shortcut Ctrl+Alt+Shift+I or add [levels=PC] (http://forum.doom9.org/showthread.php?p=1709584) to the filename) or display

[bergqvistjl]

The fix in that case would be to edit the full range flag to 1, but you have to use a player that actually honors the flag, like MPDN or MPC-HC with EVR or MadVR, and LAV filters as the decoder.If so many players ignore that flag, how do they determine that the colour is full range or not then?

[vivan]

If so many players ignore that flag, how do they determine that the colour is full range or not then?They don't - they just assume that every video has limited/tv range.

Also use Histogram(mode="levels") (http://avisynth.nl/index.php/Histogram) to figure out if video should be full or limited range.

[bergqvistjl]

They don't - they just assume that every video has limited/tv range.

Also use Histogram(mode="levels") (http://avisynth.nl/index.php/Histogram) to figure out if video should be full or limited range.

Am I right in thinking that for video specifically encoded on blu-ray disc, that the full_range_flag must always be set to false then (as it is in this case)?

[hello_hello]

I don't know about "always set to false" but the video should always be limited range even if the full range flag isn't set at all. Maybe it is always set for Bluray video. I haven't checked.

Mind you that doesn't mean everything was done correctly. I can think of examples where the video was full range, sometimes just in places, or was apparently converted from full range to limited range twice, sometimes just in places. How that happens I don't know, but the PAL DVDs of the "re-imagined and then disappeared up it's own backside" Battlestar Galactica series had a couple of episodes in season three where "space" in the opening credits was grey rather than black. They were the same credits as every other episode and this fixed them. The episodes themselves seemed fine though.

ColorYUV(Levels="TV->PC")

Or for those times when a normal conversion between full and limited range levels doesn't seem quite right.
http://avisynth.nl/index.php/Levels
http://avisynth.nl/index.php/Ylevels

[benwaggoner]

I don't know about "always set to false" but the video should always be limited range even if the full range flag isn't set at all. Maybe it is always set for Bluray video. I haven't checked.
I believe it is supposed to be always set.

And yes, full range seems like such an obvious improvement with so little technical change one would want to assume it'd work everywhere. But it doesn't. I've only been able to use full range successfully when targeting specific players. Some SoC hardware doesn't even have an easy path to get full range video samples into the imaging pipeline even if their decoder can handle full range correctly.

Even in the brave new world of HDR with 10-bit HEVC, where all hardware is by definition very recent, and with a clear spec for full-range HDR, a number of devices only handle limited range.

It's amazing how those little workaround hacks in video last for decades. IIRC, limited range was introduced in the 80's to allow for 8-bit video processing with HW that did rollover instead of clamp. So taking a video value of 3 and reducing by 8 would leave you with 250, not just 0. So <16 and >235 were there just to avoid wraparound errors.

Plus it allowed for preservation of superblacks for luma keying, which was (somewhat unbelievably, in retrospect) a thing.