commit 01858b076619c89b3db321343f4da4c42f30e1a5
author Dale Curtis <dalecurtis@chromium.org> Wed Jul 20 02:03:48 2022
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Wed Jul 20 02:03:48 2022
tree 6cb87078f46c033ed2a52e446f4a4f9400438ce4
parent 28ed0a357bebc4de235d2ecae5f915387ae6c242

Actually query codec support for NdkVideoEncodeAccelerator.

Implement a real GetSupportedProfiles() using MediaCodecInfo which
is sadly only provided by the SDK :|

This rolls in all support conditionals into GetSupportedProfiles()
so that further checks on the pixel format and hardware acceleration
status aren't necessary.

Unfortunately the functionality required to do this means we must
limit the NDK accelerator to Q+ (since we don't have the hardware
acceleration bit otherwise). Since P ARM usage is ~thousands vs
~millions P ARM64, this is a small loss.

Profiles don't map cleanly to resolutions and frame rates, so we
just attach the same max/min resolution and framerate to every
profile -- similar to what we do for decoding. This means there
is still a gap in what GetSupportedProfiles returns and what can
actually initialize -- it's just smaller after this change.
Android does not expose enough information for us to solve this
statically, so we would need to rearchitect the VEA for dynamic
support queries to solve this fully.

While doing this a bug was found in the code for inserting unique
profiles to the encoder's supported profile list. Duplicates were
matched based on profile only and not profile + resolution + rate.

I've also rounded out the Java code for format detection to include
the previously omitted AV1.

R=eugene

Bug: 1267987, 1215472
Change-Id: I12640645fb723b2321bc6104d5b44f639835fef7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3771071
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Eugene Zemtsov <eugene@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1026063}