Issue metadata
Sign in to add a comment
|
Videos are displayed with the wrong colormatrix
Reported by
1234andr...@gmail.com,
Nov 23 2017
|
||||||||||||||||||||
Issue descriptionChrome Version : 64.0.3273.0 (Canary) URLs (if applicable) : http://hr-a.akamaihd.net/test/colorspaceTest/videoplayer.html OS version : OS X 10.12.6 Audio/Video format (if applicable): Mpeg4 / h.264 Behavior in Safari (if known): OK Behavior in Firefox (if known):Also wrong. Video issue Flash or HTML5? HTML5 What steps will reproduce the problem? (1) Open http://hr-a.akamaihd.net/test/colorspaceTest/videoplayer.html (2) Press Test all I wrote a small test tool, wich is checking, if the right colorspace is used. http://hr-a.akamaihd.net/test/colorspaceTest/videoplayer.html All Colorbars are from the same Souce, but coded with different colospaces and resolutions. The used colospaces is signaled in the h.264 SPS/PPS headers Expected ColorBar-RGB-Values: White:255,255,255 Yellow:192,192,000 Cyan:000,192,192 Green:000,192,000 Pink:192,000,192 Red:192,000,000 Blue:000,000,192 Black:000,000,000 (+-2 is still ok) bt709 is ok: White:255,255,255 Yellow:192,190,001 Cyan:001,191,191 Green:001,190,000 Pink:192,000,193 Red:192,000,002 Blue:001,000,192 Black:001,000,001 What went wrong? For videos with bt601, the wrong Colorspace is used: White:255,255,255 Yellow:195,179,000 Cyan:000,172,194 Green:000,161,000 Pink:206,030,199 Red:209,018,000 Blue:000,011,201 Black:001,000,001 Any other comments? Chrome Canary on Android does it the other way around wrong. So it uses always the bt601 color matrix Firefox does it also wrong. Safari is ok. Chrome Canary on Windows works ok.
,
Nov 24 2017
Thanks for the fast response! Should I file an other Bug for Chrome Canary on Android 7.1.1?
,
Nov 27 2017
,
Nov 27 2017
This one bug should be enough.
,
Dec 7 2017
hubbe, chris, ping on this one as well.
,
Dec 8 2017
How were these files created? I noticed that the bt601 file is tagged as 240M instead of the more common 170M, but I'm not sure if that's causing any problems or not yet.
,
Dec 14 2017
This is a recent regression, can we get a fix during M65 time frame? Adding an RB label for tracking purpose, please change if needed.
,
Dec 21 2017
Probably an issue with YUVToRGBConverter -- this is reading the video back in a canvas?
,
Dec 21 2017
This isn't a recent regression.
,
Jan 3 2018
Just to update: Still we are seeing the same issue on Mac 10.12.6 using chrome latest Canary-65.0.3309.0.As hubbe & Cameron seems OOO,could someone from GPU/Media team please take a look into this issue as it is marked as stable blocker. Thanks in advance..!
,
Jan 9 2018
Friendly ping to get an update on this issue. Thanks..!
,
Jan 9 2018
Dropping RBS since this shipped in M62; hubbe@ can you take a look?
,
Jan 9 2018
Looking...
,
Jan 9 2018
Back in office now, let me want to take this on.
,
Jan 9 2018
Sure, let me know if you want me to do anything, as I actually have a mac now. :)
,
Oct 17
,
Oct 26
This is a <canvas> issue. In canvas elements, we aren't as precise about video color spaces as we are when compositing. I suspect that we hardcode bt709 somewhere. ->fserb |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, Nov 24 2017Labels: -Type-Bug -Pri-3 hasbisect-per-revision Needs-Triage-M62 Triaged-ET M-62 OS-Mac Pri-1 Type-Bug-Regression
Owner: ccameron@chromium.org
Status: Assigned (was: Unconfirmed)