mp4 video colors not correct in Chrome
Reported by
xgra...@gmail.com,
Oct 13 2016
|
|||||||||||||||||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Safari/602.1.50 Steps to reproduce the problem: 1. Drag .mp4 file directly into Chrome browser window (no HTML needed) 2. Drag .mp4 file directly into Safari browser window 3. Notice color difference. What is the expected behavior? Colors should be the same in both browsers. What went wrong? Colors are not the same in Chrome. The video color is consistent through my workflow until it hits Chrome. Notice how yellow-ish the chrome+mp4 combo is. The same video encoded as .webm shows the correct colors in Chrome, so something is wrong with the MP4 decode coloring. Maybe Chrome is discarding the color profile? I didn't add one specifically, but I believe HD709 is created by default in Media Encoder. I tried turning of chrome://flags for the hardware accelerated video options and they made no difference. Did this work before? N/A Does this work in other browsers? Yes Chrome version: Version 54.0.2840.59 (64-bit) Channel: n/a OS Version: OS X 10.10.5 Flash Version: N/A Thanks for your time, this is an important issue to me as a digital video professional. Feel free to reach out with any questions.
,
Oct 13 2016
Unable to reproduce the issue in MAC 10.11.16 by using chrome reported version #54.0.2840.59. Steps followed to reproduce the issue are as follows: ----------- 1. Dragged a sample .mp4 file directly into Chrome browser window. 2. Dragged the same .mp4 file directly into Safari and firefox browser window. 3. Did not observe any color difference. Attaching screenshots for reference xgraves@ - Could you please verify the screenshots of different browsers and let us know if it is the expected behavior. Could you please provide a sample color .mp4 file to test this issue.
,
Oct 13 2016
Thanks for looking into this krajshee@ your jpegs look fine to me so far, I'll check them in my browsers. I do have a sample .mp4 in my original post called "reduced-test-case.mp4", can you try that file in your Safari and Chrome? Thanks.
,
Oct 14 2016
Unable to reproduce the issue in MAC 10.11.16 by using chrome stable #54.0.2840.59 and latest canary #56.0.2890.0 Tested this issue as per comment #3. Attaching screenshots for chrome and safari. xgraves@ - Could you please verify the attached screenshots and please let us know if anything missed from our side.
,
Oct 17 2016
,
Oct 17 2016
Wow, that is so strange - your jpegs look fine, but mine still don't! I re-downloaded the test.mp4 from here, and I still see the color shift. The test is pretty simple so I don't think you missed anything. So far the only difference between our machines is you're using OSX 10.11 so maybe it's an OS thing. I'll do some more tests and see what I can find out. Thanks so much for your time. I'm more at ease knowing it's not a pervasive bug. On a related note, do you happen to know how Chrome handles embedded color profiles in videos (mp4 and webm) and in jpegs?
,
Oct 19 2016
Ok, I did some tests and found out the color shift bug happens when the video is over 578px tall. Weird, eh? Attached are 2 mp4 videos of a solid color (#2E7770). One is 400x400 and the other is 600x600. The 400px video looks correct in all browsers and quicktime. The 600px video has a major color shift in Chrome (v54) and Firefox (v49) on OSX 10.10.5 But then I tested on OSX 10.12 Sierra and the color shift does not happen at all (Chrome 53 or 54), which would explain your test results on OSX 10.11 El Capitan. So I guess this is only affecting OSX 10.10 Yosemite.
,
Oct 20 2016
Whatever that is, not a Blink issue. CC:Dale, and Fredrik who works on HDR and color profiles for video
,
Oct 20 2016
This is probably related to what I'm working on, which is accurate color correction for video. It seems that Something is assuming BT601 colors for videos up to a particular size and BT709 colors for videos over that size. This kind of guessing tends to happen a lot when the video is not tagged with the correct color profile. Unfortunately, chrome doesn't always do the right thing even if the video is tagged, which is what I'm trying to fix. I highly recommend setting the color space on the video instead of relying on the defaults, as the defaults can vary from platform to platform and even driver to driver.
,
Oct 20 2016
Thanks Hubbe, that makes sense. I didn't assign a color profile in After Effects, so OSX(quicktime) and each browser would have to guess the color space, which would account for the variation. I can do another test with HD709 profile embedded and see what happens. It sounds like Chrome will use the embedded profile, yes? Thanks.
,
Oct 20 2016
> It sounds like Chrome will use the embedded profile, yes? It's not so much an embedded profile, as few enums that specifies which color profile was used. Chrome makes use of this, but not consistently, which is what I'm working on fixing.
,
Oct 21 2016
Ah yes, thanks. I did some more tests using AE color profiles and two mp4 encoders (Adobe Media Encoder and Apple Compressor). I compared them visually in Safari and Chrome, and checked out the metadata in MediaInfo. Here's what I found: - using color profiles in AE made no difference (sRGB, Rec.709, and "None" all looked the same) - all mp4s are using YUV, 4:2:0, and "Limited" color range - all 400x400 mp4's from MediaEncoder have the BT.601 flags - all 600x600 mp4's from MediaEncoder have the BT.709 flags - all Compressor mp4's have no color profile flags This seems to be exactly what you suspected, that something is adding color profiles based on the dimensions of the video, and it appears to be Media Encoder. Maybe Rec.709 is added to videos it thinks will be played on a TV (over 578px tall), and BT.601 is added to files it thinks will be played on a computer? Anyway, this explains the color shift in Chrome, it's interpreting a color profile that I didn't mean to add, lol. Just to finish the test data, .webm colors looked good in Chrome in both sizes (400 and 600) and had no color flags set. Compressor mp4's looked consistent across sizes (400 and 600) and across browsers (Chrome and Safari). But that color was overall a bit off. I guess Apple's RGB > YUV conversion is different than Adobe's? Anyway thanks for your time, and let me know if you need any help figuring this out, I'd be happy to run more tests, etc.
,
Nov 2 2016
I'm suffering this problem, both mp4 and webm. OS: Windows 10 version 1607 Chrome version: 54.0.2840.87 m (64-bit) I made 12 different mp4 videos for some tests. Original RGB value is (41, 155, 153). - 400x400, encoded as BT.601, with BT.601 flag - 400x400, encoded as BT.601, with no color matrix flag - 400x400, encoded as BT.601, with BT.709 flag (wrong flag) - 400x400, encoded as BT.709, with BT.709 flag - 400x400, encoded as BT.709, with no color matrix flag - 400x400, encoded as BT.709, with BT.601 flag (wrong flag) - 600x600, same as above 6 conditions It seems that Chrome itself doesn't check the resolution for color issues and ignores the color matrix flag. Only the videos "actually" encoded as BT.601 shows the original color. The original RGB value was (41, 155, 153), but is is shifted to (51, 167, 153) on the actual BT.709 videos. I'm wondering if I should post it as a new issue because I'm using Windows.
,
Nov 2 2016
I think we have enough color-management bugs already. :) Anyways, if you're willing to try out the stuff that I'm working on, download chrome canary for windows, run it with --enable-features=video-color-management and see if that works. Depending on what kind of GPU you have you may also need --disable-accelerated-video-decode Some caveats: * chrome video color management will use a gamma of 2.4 for bt601/709 content, which can skew your values if you don't expect it. * the ICC profile of the monitor will be taken into account (if installed on your system) which means that if your monitor is not sRGB, you might not get the RGB values you expect.
,
Nov 3 2016
> Anyways, if you're willing to try out the stuff that I'm working on, download chrome canary for windows, run it with --enable-features=video-color-management and see if that works. Depending on what kind of GPU you have you may also need --disable-accelerated-video-decode Thanks. I tried it and got some results. - Running canary with "--disable-accelerated-video-decode" shows perfectly same result as Edge and IE 11. It applies color matrix as the flag indicates no matter it's right or wrong. If no flag, it applies BT.601. - Running it with "--enable-features=video-color-management" makes BT.709 videos look similar to the original, but slightly darker. Is it related to that gamma issue? (BT.601 videos show totally wrong color.) - Running it with both options makes a mixed result. Close to Edge and IE, but slightly darker. I use an sRGB monitor and the ICC profile provided by its manufacturer is installed. The graphics card is the GeForce GTX 1070.
,
Nov 3 2016
There is a number of issues here, which I am trying to fix, but they can be summarized as: A) Chrome does no gamma correction unless --enable-video-management is on. (This means that the display determines the gamma, which for most people means the sRGB ~2.2 gamma.) When color management is enabled, we apply a gamma of 2.4 (as recommended by itu-r bt 1886) regardless of monitor. B) Chrome fails to read the color information from the file. This problem currently depends on how the file is parsed. It works well for software decoded videos, for hardware-decoded videos it works in some cases, but not all. (This is why --disable-accelerated-video-decode currently makes it work better.) In the last image (5-canary-both.png) it looks like the correctly flagged content show up as the same color as expected. I'm a little concern that it seems to default to BT601, as my intention was to default to BT709 though. Thanks for taking the time to investigate. I will keep updating this bug as my work progresses.
,
Nov 4 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4c2b05e8f0675b31ec399fca5726bd3d4c29a577 commit 4c2b05e8f0675b31ec399fca5726bd3d4c29a577 Author: hubbe <hubbe@chromium.org> Date: Fri Nov 04 06:01:08 2016 preserve color space when copy_nv12_textures_ is true This should make color management work on most nvidia cards (With Win8 and later.) BUG= 576411 , 655417 Review-Url: https://codereview.chromium.org/2470363003 Cr-Commit-Position: refs/heads/master@{#429806} [modify] https://crrev.com/4c2b05e8f0675b31ec399fca5726bd3d4c29a577/media/gpu/dxva_video_decode_accelerator_win.cc
,
Nov 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/070e970240f13d29be8930f9316f39ace711a116 commit 070e970240f13d29be8930f9316f39ace711a116 Author: hubbe <hubbe@chromium.org> Date: Wed Nov 30 21:53:10 2016 This should a bunch of color decoding bugs on windows. For DX9, this means using VideoProcessBlt instead of StretchRect() (There is a fallback path for StretchRect, not sure if that is needed.) This is controlled by "--enable-features=video-blit-color-accuracy" which defaults to off and will be enabled by an experiment. BUG= 655417 , 650977 , 576419 , 576411 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2503063002 Cr-Commit-Position: refs/heads/master@{#435431} [modify] https://crrev.com/070e970240f13d29be8930f9316f39ace711a116/media/base/media_switches.cc [modify] https://crrev.com/070e970240f13d29be8930f9316f39ace711a116/media/base/media_switches.h [modify] https://crrev.com/070e970240f13d29be8930f9316f39ace711a116/media/gpu/dxva_picture_buffer_win.cc [modify] https://crrev.com/070e970240f13d29be8930f9316f39ace711a116/media/gpu/dxva_video_decode_accelerator_win.cc [modify] https://crrev.com/070e970240f13d29be8930f9316f39ace711a116/media/gpu/dxva_video_decode_accelerator_win.h [modify] https://crrev.com/070e970240f13d29be8930f9316f39ace711a116/ui/gfx/BUILD.gn [modify] https://crrev.com/070e970240f13d29be8930f9316f39ace711a116/ui/gfx/color_space.h [add] https://crrev.com/070e970240f13d29be8930f9316f39ace711a116/ui/gfx/color_space_win.cc [add] https://crrev.com/070e970240f13d29be8930f9316f39ace711a116/ui/gfx/color_space_win.h
,
Sep 8 2017
There has been significant improvements in this area. I'm going to close this bug as fixed, feel free to re-open if it still doesn't work for you. |
|||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||||||
Comment 1 by xgra...@gmail.com
, Oct 13 2016