GitLab

The HtmlVideoElementCapturerSource was unnecessarily rendering
media::VideoFrames to a RGBA canvas then converting them back to
YUV based media::VideoFrames. We can instead just pass the frame
directly through and avoid this process.

Clients which need this conversion (e.g., MediaRecorder) already
have mechanisms for converting texture backed VideoFrame objects
to YUV. They weren't comprehensive, so I've made them so in this
change.

Future optimizations could be done to allow the encoders to
actually handle I422, I44 and HBD content. Right now they are
just turned into I420 frames like they were in the capturer.

This change also moves the VideoFramePool from the capturer to the
encoder where one was missing previously; which should improve
allocation efficiency and overhead.

This change also fixes some paths of video capture not respecting
the no-protected-content capture.

Bug: None
Test: All existing tests pass.
Change-Id: I6f58f80e6137807fbf0be817be20f03928a1da23
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2464916Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Markus Handell <handellm@google.com>
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#817226}