+posciak@ for VEA wiring state of the world, I think it's present if not already enabled for VP8 through VEA. Not sure what the state of the world is for VP9 but we I believe VAAPI VP9 single-stream quality was better than WebRTC-configured (realtime + quality levels) libvpx VP9.
After working with Intel we got VP8 over VAAPI at decent quality (comparable to software/Kepler), it didn't have per-temporal-layer bitrate controls at the time, but that's never been wired up to Kepler which has been running for years.
No tests were done for screencast content, so YMMV.
pbos@:
> I think it's present if not already enabled for VP8 through VEA.
Neither VP8 nor VP9 are wired or enabled in VaVEA. Like I said in
the description, VaVEA seems on a first pass that would support
formats beyond h264, but it has many h264-specific vaapi structures
and function calls.
This is marked Mac but it sounds like it's about ChromeOS? -Mac +ChromeOS
Can this be Assigned or Available, instead of Untriaged? Assigning to mcasas to decide what the state should be.
My crrev.com/2768783002 is the first stage of the redesign that makes VaapiVEA codec-agnostic and addresses the above comments.
I also have a follow up CL that I planned to publish subsequently, which adds VPx encoding classes.
Given the above, I agree it should be useful to revisit this work. Taking over. Thank you!
I would like to request merge for https://chromium-review.googlesource.com/1072215 to M68 please.
This would not change functionality in default builds as this is disabled via a feature flag.
Thank you!
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!
If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!
If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
cde93ca43f6b10bf65f5b315ce78da8f7f4cc72e was merged to refs/branch-heads/3497 branch with no merge approval from a TPM!
Please explain why this change was merged to the branch!
I can see merge approval for M68 but not M69. Thanks!
Merge approval for revert in M69 of the original CL, which was approved here for M68, was given in b/111781384.
I'm sorry for any confusion, should I have requested separately here? Thanks!
Please explicit request merge approval for all branches on the "crbug" issue the CL is associated with. Since the merge for M69 was approved, we are all good here.
Comment 1 by mattfrazier@google.com
, Dec 13 2017