Strong Magenta Cast with Webm Videos in Chrome
Reported by
aaron.ga...@nike.com,
Nov 28 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Example URL: https://www.nike.com/t/sportswear-tech-fleece-windrunner-mens-full-zip-hoodie-RRT9gXgJ/805144-091 Steps to reproduce the problem: 1. Open URL in Chrome. 2. View the auto-playing/looping product video. 3. Open the URL in Safari. 4. View the auto-playing/looping product video. 5. Compare the two side-by-side. 6. Note that the webm version in Chrome presents a strong magenta cast (most easily noticed in the background coloring). What is the expected behavior? Ideally the webm version presents a similar color profile to the mp4 version. What went wrong? We had our video delivery vendor on site recently and they did an extensive review of this with their senior devs and image experts and indicated that this color issue is related to the way the browser (in this case Chrome) processes the format, which is interesting since it’s Google’s format and browser. The magenta cast doesn’t show up when you view the webm file itself in the VLC player, for example. We are seeing the magenta cast primarily in Chrome. We do not see it when viewing the files in VLC, Quicktime, Premiere or in other browsers such as Safari. Our understanding is that the color difference is rooted to the color management differences between each browser and their support of ICC profiles. Did this work before? No Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? Yes Chrome version: 61.0.3163.100 Channel: stable OS Version: OS X 10.12.6 Flash Version: Contents of chrome://gpu: Note: To properly save this page, select the "Webpage, Complete" option in the Save File dialog. Graphics Feature Status Canvas: Hardware accelerated CheckerImaging: Disabled Flash: Hardware accelerated Flash Stage3D: Hardware accelerated Flash Stage3D Baseline profile: Hardware accelerated Compositing: Hardware accelerated Multiple Raster Threads: Enabled Native GpuMemoryBuffers: Hardware accelerated Rasterization: Hardware accelerated Video Decode: Hardware accelerated Video Encode: Hardware accelerated WebGL: Hardware accelerated WebGL2: Hardware accelerated Driver Bug Workarounds adjust_src_dst_region_for_blitframebuffer decode_encode_srgb_for_generatemipmap disable_framebuffer_cmaa disable_multimonitor_multisampling get_frag_data_info_bug msaa_is_slow pack_parameters_workaround_with_pack_buffer regenerate_struct_names remove_invariant_and_centroid_for_essl3 scalarize_vec_and_mat_constructor_args set_zero_level_before_generating_mipmap unfold_short_circuit_as_ternary_operation unpack_alignment_workaround_with_unpack_buffer use_intermediary_for_copy_texture_image use_unused_standard_shared_blocks Problems Detected Multisampling is buggy on OSX when multiple monitors are connected: 237931 Applied Workarounds: disable_multimonitor_multisampling Unfold short circuit on Mac OS X: 307751 Applied Workarounds: unfold_short_circuit_as_ternary_operation Always rewrite vec/mat constructors to be consistent: 398694 Applied Workarounds: scalarize_vec_and_mat_constructor_args Mac drivers handle struct scopes incorrectly: 403957 Applied Workarounds: regenerate_struct_names glGenerateMipmap fails if the zero texture level is not set on some Mac drivers: 560499 Applied Workarounds: set_zero_level_before_generating_mipmap Pack parameters work incorrectly with pack buffer bound: 563714 Applied Workarounds: pack_parameters_workaround_with_pack_buffer Alignment works incorrectly with unpack buffer bound: 563714 Applied Workarounds: unpack_alignment_workaround_with_unpack_buffer copyTexImage2D fails when reading from IOSurface on multiple GPU types.: 581777 Applied Workarounds: use_intermediary_for_copy_texture_image Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198 Applied Workarounds: disable_framebuffer_cmaa glGetFragData{Location|Index} works incorrectly on Max: 638340 Applied Workarounds: get_frag_data_info_bug Decode and encode before generateMipmap for srgb format textures on macosx: 634519 Applied Workarounds: decode_encode_srgb_for_generatemipmap Insert statements to reference all members in unused std140/shared blocks on Mac: 618464 Applied Workarounds: use_unused_standard_shared_blocks adjust src/dst region if blitting pixels outside read framebuffer on Mac: 644740 Applied Workarounds: adjust_src_dst_region_for_blitframebuffer Mac driver GL 4.1 requires invariant and centroid to match between shaders: 639760, 641129 Applied Workarounds: remove_invariant_and_centroid_for_essl3 Disable KHR_blend_equation_advanced until cc shaders are updated: 661715 On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565, 751919 Applied Workarounds: msaa_is_slow Checker-imaging has been disabled via finch trial or the command line. Disabled Features: checker_imaging Version Information Data exported 11/28/2017, 9:07:02 AM Chrome version Chrome/61.0.3163.100 Operating system Mac OS X 10.12.6 Software rendering list version 13.10 Driver bug list version 10.29 ANGLE commit id 0d2ecb4ea992 2D graphics backend Skia/61 0eefc0552cfb5ac077560b7c2630c5bd475ea585- Command Line /Applications/Google Chrome.app/Contents/MacOS/Google Chrome -psn_0_73746 --restore-last-session --flag-switches-begin --flag-switches-end Driver Information Initialization time 75 In-process GPU false Passthrough Command Decoder false Supports overlays false Sandboxed true GPU0 VENDOR = 0x1002, DEVICE= 0x67ef *ACTIVE* GPU1 VENDOR = 0x8086, DEVICE= 0x191b Optimus false Optimus false AMD switchable true Driver vendor Driver version 1.51.8 Driver date Pixel shader version 4.10 Vertex shader version 4.10 Max. MSAA samples 8 Machine model name MacBookPro Machine model version 13.3 GL_VENDOR ATI Technologies Inc. GL_RENDERER AMD Radeon Pro 460 OpenGL Engine GL_VERSION 4.1 ATI-1.51.8 GL_EXTENSIONS GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier Disabled Extensions GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent Window system binding vendor Window system binding version Window system binding extensions Direct rendering Yes Reset notification strategy 0x0000 GPU process crash count 0 Compositor Information Tile Update Mode Zero-copy Partial Raster Enabled GpuMemoryBuffers Status ATC Software only ATCIA Software only DXT1 Software only DXT5 Software only ETC1 Software only R_8 GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT R_16 Software only RG_88 Software only BGR_565 Software only RGBA_4444 Software only RGBX_8888 Software only RGBA_8888 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE BGRX_8888 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE BGRA_8888 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT RGBA_F16 GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT YVU_420 Software only YUV_420_BIPLANAR GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT UYVY_422 GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT We are currently set to the default VP8 codec, but we're still seeing color issues with VP9 (though they seem to be less pronounced. VP8(Default) https://c.static-nike.com/a/videos/q_90/apdmd0mwvrmapvdrw0ag/video.webm VP9 https://c.static-nike.com/a/videos/vc_vp9/q_90/apdmd0mwvrmapvdrw0ag/video.webm
,
Nov 29 2017
,
Dec 7 2017
As discussed, PTAL.
,
Dec 7 2017
Some questions: 1) Does this happen on chrome canary as well? 2) Do you have an ICC profile? If so, could you attach it to the bug report?
,
Dec 7 2017
This same color cast is observed in Chrome Canary as well. The color profile in the mp4’s we're using is standard HD 1-1-1 (Rec.709).
,
Dec 8 2017
I was wondering what ICC profile is associated with your output monitor on your computer.
,
Dec 8 2017
We use a custom preset on our primary monitors. The color calibration settings associated with our Eizo’s is attached titled "Screen Shot 2017-12-08 at 9.17.31 AM" I've also attached a screen shot of the color profile from my monitor where I'm also observing this issue. That attachment is titled "LG Ultra HD Color Profile".
,
Dec 11 2017
Could you attach the actual ICC/ICM files instead of screenshots of the color profile tool? Also, screen shots of the color changes would be appreciated.
,
Dec 11 2017
I'm following up on the ICC/ICM files. Here are some screenshots of the color differences we're seeing. Color difference example 01 & 02 - file viewed in Quicktime on left, Chrome on right. Color difference example 03 - Safari left, Chrome right (Safari is the more accurate color representation)
,
Dec 11 2017
Color LCD.icc is typically the default display profile for our Macbooks CG247X(22508106)_CN_StudioCAL- Custom preset used for our primary color managed monitors in studio which is where all video is qa’d and color validated.
,
Dec 13 2017
I think there are a few things going on here, but I haven't been able to confirm which one is causing what because I don't have a mac. However, let me summarize my theories: Most video players don't actually support any form of color management, but will get some color management automatically from OSX. However, OpenGL apps (like chrome) has to do their own color management. This video does not have color tags, which means that it's unclear what color primaries and YUV->RGB matrix to use. Some apps will assume bt601, chrome will assume bt709. I'm not sure why the mp4 file behaves differently. It may be because the video playback is hardware accelerated and goes through a different (not color correct) path in chrome, or it may be because the color tag is different. If you run this command: mkvmerge --color-matrix 6 --color-range 1 --color-transfer-characteristics 6 --color-primaries 6 -o video-601.webm video.webm Does the resulting video-601.webm work better?
,
Dec 15 2017
Updated command line: (Run this instead of the previous one, as the previous one didn't actually work.) mkvmerge --colour-matrix 0:6 --colour-range 0:1 --colour-transfer-characteristics 0:6 --colour-primaries 0:6 -o video-601.webm video.webm
,
Dec 15 2017
hubbe@ and I checked this locally on my Mac and it's still busted after that command; hubbe@ is looking into it further
,
Dec 15 2017
I studied the screenshots some more, and I have another theory: I think Safari plays back video content with a 1.95 gamma (BT601/bt709 transfer function) while chrome uses a 2.2 / sRGB transfer function. Chrome does this intentionally to match what TVs do. (TVs generally use transfer functions very close to gamma 2.2) If that is the case, the solution is probably to encode and tag the video using the IEC 61966-2-1 (srgb) transfer function. Assuming that safari pays attention to the tagging, this should make both browsers behave the same.
,
Dec 19 2017
We will test this on our end.
,
Jan 8 2018
I'm back from vacation. How did the tests turn out on your end?
,
Jan 8 2018
The team that will test this hasn't provided results to me yet. I will get back to this thread when they do.
,
Mar 8 2018
,
Oct 17
No feedback in 6 months, closing bug. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dalecur...@chromium.org
, Nov 28 2017