New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 888873 link

Starred by 6 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

Blocked on:
issue 784610



Sign in to add a comment

VP9 4:4:4 video appears black with hardware acceleration and Nvidia GTX 950 or 1080

Reported by jan.goyv...@gmail.com, Sep 25

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Example URL:
https://www.deploymaster.com/demos/noquestions.webm

Steps to reproduce the problem:
1. Use a Windows PC with an Nvidia GTX 950 or 1080 GPU or similar GPU that supports VP9 in hardware but not 4:4:4 chroma subsampling.
2. Make sure hardware acceleration is enabled in Chrome.
3. Navigate to the .webm URL shown above, which is encoded using VP9 profile 1 with 4:4:4 chroma subsampling

What is the expected behavior?
Video plays with image and sound (which it does if hardware acceleration is disabled or not available)

What went wrong?
Video plays with sound only; image remains black

Did this work before? No 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? No
 Firefox 62

Chrome version: 69.0.3497.100  Channel: stable
OS Version: 10.0
Flash Version: 

Contents of chrome://gpu: 

Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Unavailable
Rasterization: Hardware accelerated
Skia Deferred Display List: Disabled
Skia Renderer: Disabled
Surface Synchronization: Enabled
Video Decode: Hardware accelerated
Viz Service Display Compositor: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
clear_uniforms_before_first_program_use
decode_encode_srgb_for_generatemipmap
disable_delayed_copy_nv12
disable_discard_framebuffer
disable_framebuffer_cmaa
exit_on_context_lost
force_cube_complete
scalarize_vec_and_mat_constructor_args
texsubimage_faster_than_teximage
Problems Detected
Protected video decoding with swap chain is for Windows and Intel only
Disabled Features: protected_video_decode
Some drivers are unable to reset the D3D device in the GPU process sandbox
Applied Workarounds: exit_on_context_lost
TexSubImage is faster for full uploads on ANGLE
Applied Workarounds: texsubimage_faster_than_teximage
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
ANGLE crash on glReadPixels from incomplete cube map texture: 518889
Applied Workarounds: force_cube_complete
Framebuffer discarding can hurt performance on non-tilers: 570897
Applied Workarounds: disable_discard_framebuffer
Use GL_INTEL_framebuffer_CMAA on ChromeOS: 535198
Applied Workarounds: disable_framebuffer_cmaa
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Decode and Encode before generateMipmap for srgb format textures on Windows: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Delayed copy NV12 displays incorrect colors on NVIDIA drivers.: 728670
Applied Workarounds: disable_delayed_copy_nv12
Don't expose disjoint_timer_query extensions to WebGL: 808744
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
Disabled Features: native_gpu_memory_buffers
Viz service display compositor is not enabled by default.
Disabled Features: viz_display_compositor
Skia renderer is not used by default.
Disabled Features: skia_renderer
Skia deferred display list is not used by default.
Disabled Features: skia_deferred_display_list
Version Information
Data exported	2018-09-25T03:05:12.976Z
Chrome version	Chrome/69.0.3497.100
Operating system	Windows NT 10.0.17134
Software rendering list URL	https://chromium.googlesource.com/chromium/src/+/8920e690dd011895672947112477d10d5c8afb09/gpu/config/software_rendering_list.json
Driver bug list URL	https://chromium.googlesource.com/chromium/src/+/8920e690dd011895672947112477d10d5c8afb09/gpu/config/gpu_driver_bug_list.json
ANGLE commit id	6ffc489d4f18
2D graphics backend	Skia/69 e110fd1ebd2d559838c49a8821ebf18986bd6ec2-
Command Line	"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	241
In-process GPU	false
Passthrough Command Decoder	false
Sandboxed	true
GPU0	VENDOR = 0x10de [Google Inc.], DEVICE= 0x1b80 [ANGLE (NVIDIA GeForce GTX 1080 Direct3D11 vs_5_0 ps_5_0)] *ACTIVE*
Optimus	false
AMD switchable	false
Desktop compositing	Aero Glass
Direct Composition	true
Supports overlays	false
Overlay capabilities
Diagonal Monitor Size of \\.\DISPLAY2	26.9"
Diagonal Monitor Size of \\.\DISPLAY1	26.9"
Diagonal Monitor Size of \\.\DISPLAY3	26.9"
Driver D3D12 feature level	D3D 12.1
Driver Vulkan API version	Vulkan API 1.1.0
Driver vendor	NVIDIA
Driver version	24.21.14.1163
Driver date	9-18-2018
Pixel shader version	5.0
Vertex shader version	5.0
Max. MSAA samples	8
Machine model name	
Machine model version	
GL_VENDOR	Google Inc.
GL_RENDERER	ANGLE (NVIDIA GeForce GTX 1080 Direct3D11 vs_5_0 ps_5_0)
GL_VERSION	OpenGL ES 2.0 (ANGLE 2.1.0.6ffc489d4f18)
GL_EXTENSIONS	GL_ANGLE_client_arrays GL_ANGLE_depth_texture GL_ANGLE_explicit_context GL_ANGLE_explicit_context_gles1 GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_pack_reverse_row_order GL_ANGLE_program_cache_control GL_ANGLE_request_extension GL_ANGLE_robust_client_memory GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_color_buffer_float_rgb GL_CHROMIUM_color_buffer_float_rgba GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_sync_query GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_frag_depth GL_EXT_map_buffer_range GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc_srgb GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_KHR_parallel_shader_compile GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth32 GL_OES_element_index_uint GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_vertex_array_object OES_compressed_EAC_R11_signed_texture OES_compressed_EAC_R11_unsigned_texture OES_compressed_EAC_RG11_signed_texture OES_compressed_EAC_RG11_unsigned_texture OES_compressed_ETC2_RGB8_texture OES_compressed_ETC2_RGBA8_texture OES_compressed_ETC2_punchthroughA_RGBA8_texture OES_compressed_ETC2_punchthroughA_sRGB8_alpha_texture OES_compressed_ETC2_sRGB8_alpha8_texture OES_compressed_ETC2_sRGB8_texture
Disabled Extensions	GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Disabled WebGL Extensions	EXT_disjoint_timer_query EXT_disjoint_timer_query_webgl2
Window system binding vendor	Google Inc. (adapter LUID: 0000000000faccd2)
Window system binding version	1.4 (ANGLE 2.1.0.6ffc489d4f18)
Window system binding extensions	EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_ANGLE_direct_composition EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_EXT_device_query EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_CHROMIUM_sync_control EGL_EXT_pixel_format_float EGL_KHR_surfaceless_context EGL_ANGLE_display_texture_share_group EGL_ANGLE_create_context_client_arrays EGL_ANGLE_program_cache_control EGL_ANGLE_robust_resource_initialization EGL_ANGLE_create_context_extensions_enabled
Direct rendering	Yes
Reset notification strategy	0x8252
GPU process crash count	0
Compositor Information
Tile Update Mode	One-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
ATC	Software only
ATCIA	Software only
DXT1	Software only
DXT5	Software only
ETC1	Software only
R_8	Software only
R_16	Software only
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	GPU_READ, SCANOUT
RGBA_8888	GPU_READ, SCANOUT
BGRX_8888	Software only
BGRX_1010102	Software only
RGBX_1010102	Software only
BGRA_8888	Software only
RGBA_F16	Software only
YVU_420	Software only
YUV_420_BIPLANAR	Software only
UYVY_422	Software only
Display(s) Information
Info	Display[2528732444] bounds=[0,0 2560x1440], workarea=[0,0 2409x1440], scale=1.5, external.
Color space information	{primaries_d50_referred: [[0.6636, 0.3231], [0.3264, 0.6039], [0.1420, 0.0849]], transfer:0.1895*x + 0.0000 if x < 0.2500 else (0.9994*x + 0.0006)**2.2016 + -0.0001, matrix:RGB, range:FULL}
Bits per color component	8
Bits per pixel	24
Info	Display[2841568472] bounds=[2560,0 2560x1440], workarea=[2560,0 2560x1440], scale=1.5, external.
Color space information	{primaries_d50_referred: [[0.6636, 0.3231], [0.3264, 0.6039], [0.1420, 0.0849]], transfer:0.1895*x + 0.0000 if x < 0.2500 else (0.9994*x + 0.0006)**2.2016 + -0.0001, matrix:RGB, range:FULL}
Bits per color component	8
Bits per pixel	24
Info	Display[2779098405] bounds=[-2560,0 2560x1440], workarea=[-2560,0 2560x1440], scale=1.5, external.
Color space information	{primaries_d50_referred: [[0.6636, 0.3231], [0.3264, 0.6039], [0.1420, 0.0849]], transfer:0.1895*x + 0.0000 if x < 0.2500 else (0.9994*x + 0.0006)**2.2016 + -0.0001, matrix:RGB, range:FULL}
Bits per color component	8
Bits per pixel	24
Video Acceleration Information
Decode h264 baseline	up to 4096x2304 pixels
Decode h264 baseline	up to 2304x4096 pixels
Decode h264 main	up to 4096x2304 pixels
Decode h264 main	up to 2304x4096 pixels
Decode h264 high	up to 4096x2304 pixels
Decode h264 high	up to 2304x4096 pixels
Decode vp8	up to 7680x4320 pixels
Decode vp8	up to 4320x7680 pixels
Decode vp9 profile0	up to 7680x4320 pixels
Decode vp9 profile0	up to 4320x7680 pixels
Decode vp9 profile1	up to 7680x4320 pixels
Decode vp9 profile1	up to 4320x7680 pixels
Decode vp9 profile2	up to 7680x4320 pixels
Decode vp9 profile2	up to 4320x7680 pixels
Decode vp9 profile3	up to 7680x4320 pixels
Decode vp9 profile3	up to 4320x7680 pixels
Encode h264 baseline	up to 3840x2176 pixels and/or 30.000 fps
Encode h264 main	up to 3840x2176 pixels and/or 30.000 fps
Encode h264 high	up to 3840x2176 pixels and/or 30.000 fps
Diagnostics
... loading ...
Log Messages
GpuProcessHostUIShim: The GPU process exited normally. Everything is okay.
[10812:6756:0925/093105.248:ERROR:gles2_cmd_decoder.cc(18047)] : [.BrowserCompositor-0000024353887DA0]GL ERROR :GL_INVALID_OPERATION : glCreateAndConsumeTextureCHROMIUM: invalid mailbox name
[10812:6756:0925/093105.248:ERROR:gles2_cmd_decoder.cc(10168)] : [.BrowserCompositor-0000024353887DA0]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
[10812:6756:0925/100216.970:ERROR:mf_helpers.cc(14)] : Error in dxva_video_decode_accelerator_win.cc on line 1630
[10812:6756:0925/100216.970:ERROR:mf_helpers.cc(14)] : Error in dxva_video_decode_accelerator_win.cc on line 860
[10812:6756:0925/100216.970:ERROR:gpu_video_decode_accelerator.cc(369)] : HW video decode not available for profile vp8
[10812:9400:0925/100239.700:WARNING:angle_platform_impl.cc(59)] : compileToBinary(228): C:\fakepath(57,8-58): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them C:\fakepath(65,8-42): warning X3571: pow(f, e) will not work for negative f, use abs(f) or conditionally handle negative values if you expect them
[10812:6756:0925/100247.634:ERROR:mf_helpers.cc(14)] : Error in dxva_video_decode_accelerator_win.cc on line 1630
[10812:6756:0925/100247.634:ERROR:mf_helpers.cc(14)] : Error in dxva_video_decode_accelerator_win.cc on line 860
[10812:6756:0925/100247.634:ERROR:gpu_video_decode_accelerator.cc(369)] : HW video decode not available for profile vp8

Chrome should be able to determine that the video uses 4:4:4 chroma subsampling and fall back to software playback when the hardware does not support 4:4:4 chroma subsampling even if the hardware claim support for VP9.
 
Chrome is perfectly capable of playing VP9 4:4:4 video when VP9 hardware acceleration is not available at all, or if hardware acceleration is disabled in the settings.  The problem only occurs when VP9 hardware acceleration is available.  Chrome should be able to determine that the video uses 4:4:4 chroma subsampling and fall back to software playback if the hardware supports VP9 but not 4:4:4.

On my own (Windows) systems, VP9 4:4:4 videos appear black if hardware acceleration is enabled and the video card is a GTX 950 or GTX 1080.  On systems with older Nvidia cards, which do not support VP9 in hardware at all, VP9 4:4:4 videos always play correctly in Chrome.

What makes this issue annoying is that hardware acceleration is enabled by default even if the PC is more than powerful enough to handle playback in software.

4:4:4 subsampling is very useful for videos that show a lot of fine detail, such as screen recordings of applications showing small text.  Text on colored backgrounds (think syntax highlighting or "acrylic material") is much crisper with 4:4:4 subsampling.
Labels: Needs-Triage-M69
Cc: hubbe@chromium.org liber...@chromium.org
Owner: tmathmeyer@chromium.org
Status: Assigned (was: Unconfirmed)
Interesting. https://www.webmproject.org/vp9/profiles/ -- I wonder if they support 4:2:2, if not we probably need to limit the Windows decoder to profile_0 -- though some cards do support profile_2 I think. I'm not sure how to test that though. +hubbe, liberato, tmathmeyer. 

=>ted since it should be a fairly small change, but in an area you're looking at.
Cc: sande...@chromium.org
I talked to hubbe about this after the standup - it seems like limiting to profile_0 would disable hardware accelerated HDR for vp9 on windows.

Hubbe proposed that I use VP9ConfigChangeDetector::DetectConfig to base playback support off of subsampling_x and subsampling_y, which apparently can be mapped to 4:2:2 vs 4:4:4. He mentioned that Dan would be a good person to get input from on whether failing out of the decoder at this stage would be the right thing to do.
I couldn't recall if we actually have vp9.2 hardware decode support? Either way, we could limit to profile_0||profile_2 and just not profile_1||profile_3 if such support is uncommon. We don't have access to the config change detector at the time you need to make this decision. You need to make it before we even know the target bitstream; i.e., we need the decoder to expressly say which profiles it supports.
Since you asked about 4:2:2, I encoded the same video as VP9 4:2:2:
https://www.deploymaster.com/demos/noquestions422.webm

I can't get this to play at all in Chrome 69.  It stays stuck at 0:00, showing a black image.  Doesn't matter if hardware acceleration is enabled or disabled.  Should I report this as a separate issue?

As I mentioned in my original report, Firefox has the same issue with VP9 4:4:4 video when hardware acceleration is enabled.  Firefox will play the 4:2:2 video if hardware acceleration is disabled.  With hardware acceleation enabled and using a Nvidia GTX 1080, Firefox plays the 4:2:2 video with sound but with a black image.  From this I conclude that the GTX 1080 does not support hardware acceleration for 4:2:2 video either.
After closing all Chrome windows (instead of using the Relaunch button in the settings when changing hardware acceleration), I can play the 4:2:2 video in Chrome when hardware acceleration is disabled.  If I enable it (still using GTX 1080), the image is black but sound can be heard.  So VP9 4:2:2 has the same issue as VP9 4:4:4.
I don't have any HDR videos to work with.  But I can convert my video to a greater bit depth to force a higher VP9 profile.

VP9 profile 2:
https://www.deploymaster.com/demos/noquestions420_10.webm (10-bit)
https://www.deploymaster.com/demos/noquestions420_12.webm (12-bit)

VP9 profile 3:
https://www.deploymaster.com/demos/noquestions444_10.webm (10-bit)
https://www.deploymaster.com/demos/noquestions444_12.webm (12-bit)

All 4 videos play correctly when hardware acceleration is disabled.

With hardware acceleration enabled and an Nvidia GTX 1080 in the PC, both 10-bit videos play correctly.  The 12-bit videos play the sound correctly, but the image is distorted.  But I do not think that hardware acceleration is actually being used.  The "video decode" graph in the Windows Task Manager stays at precisely 0% for the entire video.  Yet, turning on hardware acceleration does corrupt the 12-bit videos.  (Perhaps you're still relying on the GPU to do YUV->RGB even when VP9 is being decoded in software.)
Thanks for all the tests, the 422 issue was just fixed so that would explain why it doesn't work on stable. It definitely sounds like we should limit to profile 0,2 only for the hardware decoders and send 1,3 to software decoder only.

The trick will be making sure we get the correct profile information when demuxing the content. I'm not sure it's parsed accurately, so we'll need to make sure each type returns the proper profile at time of demux in mse and src=.
FWIW, I added samples for all types of images here, including odd sizes one that the windows decoder can't do:
https://jyavenard.github.io/htmltests/tests/webm-hdr.html

nvidia doesn't do profile 1 and 3, only 0 and 2.
same with intel.

worse bit is that it never errors, it only returns garbage.
Labels: -Pri-2 M-72 Pri-1
Branch cut for 71 is today, but lets try to get a fix out for this soon and see if it's something we might be able to merge back to M-71.

Ted can you scrub 1,3 from the supported profiles of the DXVA/D3D11 decoders and ensure we're demuxing the correct profile type for the linked media in both FFmpegDemuxer and ChunkDemuxer.

It's probably worth testing this on Android to see if MediaCodec is busted as well.
Blockedon: 784610
So D3D11VP9Accelerator will fail to decode a profile 1 or 3 video already, and fall back to DXVAVideoDecoder, which in it's current state does not play correctly.

I just uploaded a small patch for review which allows the ConfigChangeDetector to understand profiles and try a config change if the profile changes from default (which is currently set to PROFILE0, since that is what is hardcoded in AVStreamToVideoDecoderConfig). Then DXVA fails to re-initialize, and a final fallback occurs to the VpxVideoDecoder. It will definitely impact startup time, but I am not sure what else can be done before https://bugs.chromium.org/p/chromium/issues/detail?id=784610 being fixed.

I've set that as a blocker
Project Member

Comment 13 by bugdroid1@chromium.org, Oct 22

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f71098198f9adbb2d7eb2eed350e864d81bf77fd

commit f71098198f9adbb2d7eb2eed350e864d81bf77fd
Author: Ted Meyer <tmathmeyer@chromium.org>
Date: Mon Oct 22 21:59:09 2018

Blacklist VP9Profile{1,3} in GPU Decoders

D3D11 crashes when trying to play a profile 1 or 3 video,
DXVA renders the video incorrectly.
This change causes these decoders to fail out during initialization
if either of these profiles is in use.

Bug: 888873
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: Ibe3d57df4a4564098523e396291a0e8ba8dbbd98
Reviewed-on: https://chromium-review.googlesource.com/c/1286190
Commit-Queue: Ted Meyer <tmathmeyer@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601742}
[modify] https://crrev.com/f71098198f9adbb2d7eb2eed350e864d81bf77fd/media/gpu/windows/d3d11_video_decoder.cc
[modify] https://crrev.com/f71098198f9adbb2d7eb2eed350e864d81bf77fd/media/gpu/windows/dxva_video_decode_accelerator_win.cc

Sign in to add a comment