sRGB shouldn't be used for HDR video

On Intel ICL platform with HDR monitor being connected, we have observed
quite obvious wrong color when playing HDR video. The root cause is that
sRGB is being used in GLRenderer::DrawYUVVideoQuad mistakenly. This CL
fixes it by using the original HDR colorspace instead.


Bug: 1033776
Change-Id: I7739c0afc4d623907571cda866a77c51c1f706e1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1966578Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Reviewed-by: kylechar <kylechar@chromium.org>
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#727252}

components/viz/service/display/gl_renderer.cc

@@ -2310,7 +2310,11 @@ void GLRenderer::DrawYUVVideoQuad(const YUVVideoDrawQuad* quad,
   // Force sRGB output on Windows for overlay candidate video quads to match
   // DirectComposition behavior in case these switch between overlays and
   // compositing. See https://crbug.com/811118 for details.
-  if (supports_dc_layers_ &&
+  // Currently if HDR is supported, OverlayProcessor doesn't promote HDR video
+  // frame as overlay candidate. So it's unnecessary to worry about the
+  // compositing-overlay switch here. In addition drawing a HDR video using sRGB
+  // can cancel the advantages of HDR.
+  if (supports_dc_layers_ && !src_color_space.IsHDR() &&
       resource_provider_->IsOverlayCandidate(quad->y_plane_resource_id())) {
     DCHECK(resource_provider_->IsOverlayCandidate(quad->u_plane_resource_id()));
     dst_color_space = gfx::ColorSpace::CreateSRGB();