Video: Support bitstream HDR metadata extraction for Windows

There are several places a HDR metadata may appears:
1. Container 2. Bitstream 3. Both container and bitstream

Our previous logic only use the HDR metadata extracted from
the container, which is okey for VP9 since VP9 doesn't allow
HDR metadata wrote to the bitstream, container is the only
place. but for HEVC/AV1/H264, since the spec allow HDR metadata
wrote to the bitstream, and some muxers choose only write the
metadata to the bitstream, thus if it is the case, then we
will miss the information.

The H264/HEVC/AV1 spec doesn't specify which one should be
preferred, and if both HDR metadata appears in the bitstream
and container, then they should be the same value theoretically.

The CL allow us extract HDR metadata from the bitstream, and
prefer HDR metadata from the bitstream if it appears. Otherwise
use HDR metadata from the container which will make sure we can
get the information completely.

Bug: 1386299

Change-Id: I3ca8c20bf4e964834163fb79b7f082bc8f3f18f1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4066720
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: 朱思达 <zhusida@bytedance.com>
Cr-Commit-Position: refs/heads/main@{#1078901}

diff --git a/media/gpu/vp9_decoder.cc b/media/gpu/vp9_decoder.cc
index a2cf762..d8974e0 100644
--- a/media/gpu/vp9_decoder.cc
+++ b/media/gpu/vp9_decoder.cc

@@ -443,6 +443,11 @@
   return chroma_sampling_;
 }
 
+absl::optional<gfx::HDRMetadata> VP9Decoder::GetHDRMetadata() const {
+  // VP9 only allow HDR metadata exists in the container.
+  return absl::nullopt;
+}
+
 size_t VP9Decoder::GetRequiredNumOfPictures() const {
   constexpr size_t kPicsInPipeline = limits::kMaxVideoFrames + 1;
   return kPicsInPipeline + GetNumReferenceFrames();