GitLab

This CL adds a switch to use libvpx for opaque (no alpha transparency)
VP8. There is no change to the default behavior (using ffmpeg). The
switch will be toggled via finch to compare the performance libvpx and
ffvp8.

Switching to libvpx would workaround a bug we're hitting decoding
vp8 streams from intel hw encoders (bug believed to be in ffmpeg, filed
https://trac.ffmpeg.org/ticket/8069). FFvp8 has better performance
than libvpx, but these gains may not matter on modern systems. Vp8 is
also very uncommon and generally low-resolution on today's web.

FFmpeg and libVPX have different behaviors around mid-stream frame-size
changes. LibVPX simply trusts the container metadata and we scale any
deviation from that is simply scaled. This is also true for hardware
decoders (for other codecs) and VP9 (which already uses libvpx). In
contrast, FFmpeg trusts the frames themselves and changes the size of
the video dynamically. This motivated a re-write of the
video-frame-size-change.html, which is focused on rendered size
changes rather than nuance of a specific codec. Folks desiring a size
change should use MSE to append a new init segment to explicitly signal
the new size. Given very limited use of VP8 today, we expect this
does not break folks (and hope the finch experiment will confirm that).

(https://simpl.info/videoalpha/)

Bug: 992235, 963740, b:138840822
Test: media_unittests and manually verified alpha still works with vpx
Change-Id: I48cec468946eb5a769fb2966da6b92ba28b43d8b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1745711
Commit-Queue: Chrome Cunningham <chcunningham@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#686684}