Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th December 2015, 20:27   #1  |  Link
bergqvistjl
Registered User
 
Join Date: Jun 2014
Posts: 13
How can I solve a weird colour range problem?

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:
Quote:
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?
bergqvistjl is offline   Reply With Quote
Old 18th December 2015, 05:42   #2  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,563
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.

Last edited by foxyshadis; 18th December 2015 at 05:46.
foxyshadis is offline   Reply With Quote
Old 18th December 2015, 09:23   #3  |  Link
bergqvistjl
Registered User
 
Join Date: Jun 2014
Posts: 13
Quote:
Originally Posted by foxyshadis View Post
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?

Last edited by bergqvistjl; 18th December 2015 at 09:27.
bergqvistjl is offline   Reply With Quote
Old 18th December 2015, 09:32   #4  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,569
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] to the filename) or display
sneaker_ger is offline   Reply With Quote
Old 20th December 2015, 13:40   #5  |  Link
bergqvistjl
Registered User
 
Join Date: Jun 2014
Posts: 13
Quote:
Originally Posted by foxyshadis View Post
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?
bergqvistjl is offline   Reply With Quote
Old 20th December 2015, 16:28   #6  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 649
Quote:
Originally Posted by bergqvistjl View Post
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") to figure out if video should be full or limited range.

Last edited by vivan; 20th December 2015 at 16:30.
vivan is offline   Reply With Quote
Old 21st December 2015, 09:27   #7  |  Link
bergqvistjl
Registered User
 
Join Date: Jun 2014
Posts: 13
Quote:
Originally Posted by vivan View Post
They don't - they just assume that every video has limited/tv range.

Also use Histogram(mode="levels") 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)?
bergqvistjl is offline   Reply With Quote
Old 22nd December 2015, 08:05   #8  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,568
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

Last edited by hello_hello; 22nd December 2015 at 08:10.
hello_hello is offline   Reply With Quote
Old 27th December 2015, 19:34   #9  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 3,981
Quote:
Originally Posted by hello_hello View Post
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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:59.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.