I don't see this issue on YouTube+Wi7, or maybe the difference is too sutle to tell. Hubbe, by looking at the screenshot, do you think it's a real bug? 

There are lots of bugs with color in chrome. Not sure if this one is real or not, since "should look the same as firefox" is not really a great quality indicator.

I'm working on a CL right now that might help this, but it would be helpful to know what chrome:media-internals say about the video. (Is it VP9? is it hardware accelerated?)

Sure whatever you need just ask. As I mentioned it's not just Firefox, Chrome setups on identical OS don't have the problem either. I've compared my Win 7 x64 Enterprise w/ Chrome 54.0.2840.99 to another and looked at the media-internals. They are both the same (vp9 and opus) but the one with the good color (ie that looks like Firefox) has render id 18 and the one with the washed out color has render id 12.

Property	Value
audio_codec_name	opus
audio_dds	false
audio_decoder	OpusAudioDecoder
duration	825.041
event	PAUSE
found_audio_stream	true
found_video_stream	true
pipeline_state	kSuspended
player_id	32
render_id	12
url	blob:https://www.youtube.com/8e96b2cd-52bf-46f9-9993-adcca8c694ef
video_codec_name	vp9
video_dds	false
video_decoder	VpxVideoDecoder

I also tried https://www.youtube.com/watch?v=amy-4jDlYgo (just random since it happens on other videos) and it's the same issue but there the good color one has player/render 57/26 and the bad washed out color has player/render 57/4

Do they both say VpxVideoDecoder in media-internals?
That would mean that this is software-decoded VP9, and the opportunities for messing up the colors in chrome are fairly limited.
I tried reproducing this on my win7 machine, but could not.
It's possible that this is some sort of youtube experiment. I think you can see what youtube experiments are currently active by going to youtube.com/experiments

Yes, they both say VpxVideoDecoder. Everything in both comparisons except the render_id varies. I went to youtube.com/experiments but it says not found.

Also I copied the Chrome folder from the Win 7 computer without the problem to my desktop on the one with the problem, then I ran from that chrome.exe (checked procexp to confirm) and I still have the same problem.

I'm a bit confused as to what could be causing this.
I think the next steps are:

1) Attach the contents of chrome://gpu
2) test it on local (non-youtube) content to rule out youtube doing something.

The contents of chrome://gpu is attached. I tried with hardware acceleration disabled and the color was still washed out. I tried the same video but as a local MP4 to rule out YouTube and the color was still washed out.

Deleted: chromegpu.txt 11.8 KB

chromegpu.txt 11.8 KB View Download

I don't know why, but it seems like chrome is converting YUV to RGB using a software path which assumes full-range video. This path has recently been changed to assume limited-range video (which is far more common), once this fix goes live, your colors will be better.

However, it would be nice to understand why your chrome isn't using gpu-accelerated YUV to RGB conversion. It says compositing is hardware accelerated, which I thought would mean YUV->RGB. Options include:

1. Your graphics card driver is old and buggy
2. You started chrome with some flag(s)
3. You made some changes in in about:flags

I am using an integrated graphics card Intel HD Graphics 3000. The driver is the default one included and updated by Windows. It was last updated 2014. As far as the flags go I only use --force-device-scale-factor=1 but removing it doesn't make a difference. Also as I mentioned this happens even in a clean profile, but it does not happen with Chromium for some reason.

If there is a fix or build you would like me to try it's no problem, let me at it!

I think the reason it "works" on chromium is that the software color conversion has been fixed there, so even though it uses software color conversion it doesn't wash out the colors.

In chrome://gpu  this line makes me a bit suspicious:

    In-process GPU	true

When you use chromium, does it say that too?
In fact, could you post the chrome://gpu from chromium so that I can compare them?

Actually, I think this is the problem:

 Drivers older than 2009-01 on Windows are possibly unreliable: 72979, 89802, 315205
    Disabled Features: all

This causes chrome to use software rendering only, and that path has some issues with color transformations.

Looks like you can get newer drivers from intel.com.

In-process GPU is true for both Chrome and Chromium. The Intel Driver I have is 9.17.10.3347 which was released in 2013 and came on Windows Update in 2014. I don't know why it says 2009 in Chrome/Chromium. The system is pretty stable and I don't notice any problems otherwise.

Chromium is using software rendering by default. Chrome is not. Both have the notice for 'Drivers older than 2009'. In Chromium if I use --ignore-gpu-blacklist I can get it to use hardware rendering and there is no difference in color (normal). However I've just discovered that in Chrome when I use that switch the colors will look normal like in Chromium and Firefox.

So I guess I would either have to upgrade my graphics card, wait for the YUV->RGB update or use --ignore-gpu-blacklist. For now I will use --ignore-gpu-blacklist.

I have several shortcuts to Chrome and it is also the default browser, do you happen to know if there is any way I can default the configuration to  --force-device-scale-factor=1  --ignore-gpu-blacklist without modifying the shortcuts, so that no matter how Chrome is started it will use that configuration?

This doesn't work for all flags, but for ignore-gpu-blacklist you can go to about:flags and set the flag there, which will save it to your profile.

There seems to be a newer driver here:
https://downloadcenter.intel.com/download/24971/Intel-HD-Graphics-Driver-for-Windows-7-8-64-bit

Not sure why Windows wouldn't give you that driver automatically though.

For what it's worth, I'm working on making color rendering better in chrome, but software mode is unfortunately not near the top of my todo list right now.

zmo, do you know why this driver from 2013 would be blacklisted?

If you look at "Problems detected" in about:gpu, it tells you the reason and the related bug ID.

jbauman: I noticed an inconsistency in about:gpu.  In "Problems detected", I saw several entries that disabled accelerated_vpx_decode, but in the "Graphics Feature Status", it still says "VPx Video Decode: Hardware accelerated." This seems like a bug to me (not related to this specific bug here though). Can you take a look?

The YUV -> RGB update landed a while ago.
I don't think we'll be adding additional color management to the software path, so the rest is WontFix.

I understand. The workaround I have is working well so far. Thanks