Issue metadata
Sign in to add a comment
|
Video on twitter.com appears green |
||||||||||||||||||||||||
Issue descriptionGoogle Chrome 59.0.3033.0 (Official Build) canary (64-bit) Revision 264668d2881277a13cd9a52c6a26b592b3502fbd-refs/heads/master@{#455023} OS Mac OS X 10.12.3 (16D32) Hardware: corp mac pro What steps will reproduce the problem? (1) View https://twitter.com/nodeschooloak/status/848970984572858368 The video plays but the colors are shifted and its just green and pink. This behavior happens to me for ALL videos embedded on twitter.com. I haven't seen it elsewhere. I can repro with https://twitter.com/nodeschooloak/status/848970984572858368 in incognito, however I can't in a fresh profile with the same canary build. There it looks fine. It's also fine if I view the video asset directly (https://video.twimg.com/tweet_video/C8gmccFUMAAL0DM.mp4) in a new tab. I've been seeing this bug for about 3 weeks now. GIF of the issue attached. also about:gpu. Let me know what else I can try out
,
Apr 4 2017
I'm not able to reproduce on latest Canary (59.0.3061.0), but that may be because of the profile issue you mentioned. Adding some folks.
,
Apr 4 2017
Can you post about:version so we can see the variations?
,
Apr 4 2017
,
Apr 5 2017
Unable to reproduce the issue on Mac-10.12.3,Windows-7,and Linux Ubuntu-14.04 using Chrome stable version 57.0.2987.133,canary 59.0.3063.0 and reported version 59.0.3033.0. Could you please try in a clean profile without any extensions and let us know your observations. Please find the attached screen cast for reference. Thanks.
,
Apr 6 2017
Do we know if the affected machines are running with --enable-features=video-color-management? Also, is that experiment still generating useful data?
,
Apr 6 2017
We fan find out once they post about:version from the affected machine(s).
,
Apr 6 2017
And yes, that experiment is still providing useful data.
,
Apr 6 2017
paul, are you in MTV today, can we quickly sync up with your machine? This looks like a double-applied YUV to RGB conversion. The fact that this only happens with embedded videos is likely because it's going through a separate render pass there, and hitting YUVToRGBConverter::CopyYUV420ToRGB as a results. When viewing as a separate media file, it ends up as an overlay (and skips YUVToRGBConverter::CopyYUV420ToRGB). If you run with the command-line flag --disable-mac-overlays, does it happen with stand-alone videos? Also, does it happen with --disable-features=video-color-management
,
Apr 6 2017
Also, the "HW video decode not available for profile h264 baseline" errors sound like issue 709099 , where a decode hiccup ends up in us sending incorrect color spaces to the compositor.
,
Apr 6 2017
Also, recording issue 699243 as a possible root cause.
,
Apr 10 2017
Issue 700520 has been merged into this issue.
,
Apr 11 2017
I updated Canary (to 463122) and can no longer repro, so perhaps r462742 did resolve it. My current finch variations (as hashes) are attached. Hopefully they're the same as they were before I restarted Chrome. After resolving, I see "VideoColorManagement-WithColorMgmt" in there, FWIW. I'll proactively close the issue, assuming skyostil's issue is also resolved by the r462742 fix. (If I'm wrong, please reopen :)
,
Apr 11 2017
Seems to be working now on Chrome/59.0.3053.3. Thanks!
,
Apr 13 2017
Merging to 709099. It looks that issue 709099 doesn't need a M58 merge. If anyone who had this issue wants to spin up a M58 and see if it happens there too, that would be great. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by paulir...@chromium.org
, Apr 4 2017