The first-time support for software protected video from the gpu side will limit this feature to Intel hardware overlay only. Underlays and non-Intel GPUs will be enabled later.

The code change is divided into two parts. The first part was out for review.

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

commit cbe1a635c794de30f5c76ffbe031da08b0ef3910
Author: Maggie Chen <magchen@chromium.org>
Date: Thu Nov 15 22:46:35 2018

Support software protected video in Windows

With this support in overlay swap chain, screen capture on protected videos
will no longer work.

Hardware protected video has been supported in Chrome but it requires the
latest Intel GPU hardware for video decoding. Software protected video does
not require any specific hardware. It will be decoded by Chrome. However, the
first-time support of this feature will limit this feature to Intel hardware
overlay only. Underlays and non-Intel GPUs will be enabled later.

This CL replaces the existing flag |is_protected_video| with
|protected_video_type| which includes clear, softwareProtected and
hardwareProtected. The swap chain creation function will set the correct flags
accordingly.

This CL doesn't include the changes from YUV video draw quad and draw quad mojo.
Those changes will be checked in separately.


Bug:903552

Change-Id: I29a5eb021357b34ce15e7af4e85fccf151399583
Reviewed-on: https://chromium-review.googlesource.com/c/1333997
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608560}
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/components/viz/service/display/dc_layer_overlay.cc
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/components/viz/service/display/dc_layer_overlay.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/components/viz/service/display/gl_renderer.cc
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/build_gles2_cmd_buffer.py
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/client/gles2_c_lib_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/client/gles2_cmd_helper_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/client/gles2_implementation.cc
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/client/gles2_implementation_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/client/gles2_interface_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/client/gles2_interface_stub_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/client/gles2_interface_stub_impl_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/client/gles2_trace_implementation_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/client/gles2_trace_implementation_impl_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/common/gles2_cmd_format_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/common/gles2_cmd_format_test_autogen.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/gles2_cmd_buffer_functions.txt
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/service/gles2_cmd_decoder_passthrough_doer_prototypes.h
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/service/gles2_cmd_decoder_passthrough_doers.cc
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/command_buffer/service/gles2_cmd_decoder_passthrough_handlers.cc
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/ipc/service/direct_composition_surface_win.cc
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/gpu/ipc/service/direct_composition_surface_win_unittest.cc
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/ui/gl/dc_renderer_layer_params.cc
[modify] https://crrev.com/cbe1a635c794de30f5c76ffbe031da08b0ef3910/ui/gl/dc_renderer_layer_params.h

Per our offline discussion, once the software protected video bit is wired up at the media side, let's add a pixel test on Windows to make sure screen grabber can't read back video frames.

After this swapchain change, I tried to do the screen shot manually. The video is all black. I think this will be a good test - a normal video frame without a software protected video flag and a black video frame with a flag.

The finished code was tested with a real URL. It worked. The video was all black in the screen capture.

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

commit d615465be19d490289cd0a009885f18be8d96efe
Author: Maggie Chen <magchen@chromium.org>
Date: Tue Nov 20 22:02:19 2018

Support software protected videos in YUVVideoDrawQuad

Screen capture on protected videos will no longer work after software protected
videos are supported.

This CL handles YUVVideoDrawQuad only. The other part of the support on the gpu
side was checked in separately. The main change in this CL is to replace the
existing flag |is_protected_video| with |protected_video_type| which includes
clear, softwareProtected and hardwareProtected.

NOTE: Before this CL, |PROTECTED_VIDEO| means hardware protected video. After
this CL, |PROTECTED_VIDEO| means both software and hardware and |HW_PROTECTED|
will differentiate whether it's protected by software or hardware.

Bug:903552

Change-Id: I8c025bdcbafaed224a5e1f9ea6fa14b42bdfe192
Reviewed-on: https://chromium-review.googlesource.com/c/1334099
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Rintaro Kuroiwa <rkuroiwa@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609818}
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/components/viz/common/quads/DEPS
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/components/viz/common/quads/draw_quad_unittest.cc
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/components/viz/common/quads/yuv_video_draw_quad.cc
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/components/viz/common/quads/yuv_video_draw_quad.h
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/components/viz/service/display/dc_layer_overlay.cc
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/media/base/video_frame_metadata.h
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/media/gpu/windows/d3d11_video_decoder.cc
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/media/renderers/video_resource_updater.cc
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/services/viz/public/cpp/compositing/quads_struct_traits.cc
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/services/viz/public/cpp/compositing/quads_struct_traits.h
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/services/viz/public/cpp/compositing/render_pass.typemap
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/services/viz/public/cpp/compositing/struct_traits_unittest.cc
[modify] https://crrev.com/d615465be19d490289cd0a009885f18be8d96efe/services/viz/public/interfaces/compositing/quads.mojom

Hi Xianhan,

Could you please help clarify our questions about software protected video? 
(1) What is the expected behavior if the overlay swap chain creation fails? Display black video frames? 
(2) The alpha blending on nonroot video is not working (yet) in the swap chain path. What do we expect? Still use swapchain with a wrong video effect or go to GL composition with a correct video but no content protection?

Actually there is a third option on (2). We could a) use swapchain with a wrong video effect b) go to GLRenderer composition with a correct video (high res) but no content protection c) go to GLRenderer composition with a low res video (don't need content protection)

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

commit ea717408810651e5ae521d5c1983c3276bf876db
Author: Maggie Chen <magchen@chromium.org>
Date: Wed Nov 28 09:50:37 2018

Update ShouldUseYUVSwapChain()

When decideing whether a YUV format should be used for swapchain creation,
check the current protected video type instead of the one from the previous
swap chain creation.

Bug: 903552
Change-Id: I028b32dcbcd66763ac8f4220f79fc6674f28bcdf
Reviewed-on: https://chromium-review.googlesource.com/c/1352431
Commit-Queue: Maggie Chen <magchen@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611619}
[modify] https://crrev.com/ea717408810651e5ae521d5c1983c3276bf876db/gpu/ipc/service/direct_composition_surface_win.cc