https://codereview.chromium.org/1796393002 handles this and cleans up the codec name code a lot.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb7409de2920256bca4a678a030198d6a99f2709

commit fb7409de2920256bca4a678a030198d6a99f2709
Author: dalecurtis <dalecurtis@chromium.org>
Date: Tue Mar 15 21:32:06 2016

Remove Exynos from MediaCodec blacklist. Limit MediaTek blacklist.

MediaCodec has a newer path for limiting the VP8 blacklist more
precisely that should be used instead of a blanket Exynos blacklist.

MediaTek nowadays also has a vp9 decoder, so restrict blacklist to
only vp8 MediaTek devices. Per glaznev@ the MediaTek vp8 decoder is
slower than software, so it kind of makes sense to include it on
the "known unaccelerated" list.

BUG=446974,  594814 
TEST=hardware vp9 on galaxy s6 works with <video>.

Review URL: https://codereview.chromium.org/1796393002

Cr-Commit-Position: refs/heads/master@{#381322}

[modify] https://crrev.com/fb7409de2920256bca4a678a030198d6a99f2709/content/common/gpu/media/android_video_encode_accelerator.cc
[modify] https://crrev.com/fb7409de2920256bca4a678a030198d6a99f2709/media/base/android/media_codec_util.cc
[modify] https://crrev.com/fb7409de2920256bca4a678a030198d6a99f2709/media/base/android/media_codec_util.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5c1bee20afe6113087fc9a5781b5773a8894bbd4

commit 5c1bee20afe6113087fc9a5781b5773a8894bbd4
Author: dalecurtis <dalecurtis@chromium.org>
Date: Thu Mar 17 22:03:35 2016

Cleanup MediaCodecUtil::GetDefaultCodecName().

There's no need to build an entire list of codecs and transport that
across JNI when we always want the first one in the list.

Notably this reduces the cost of GpuChildThread::OnInitialize() by
over 400ms on an N5 running Marshmallow (450.208ms vs 39.64ms)! The
reduction comes from VideoEncodeAccelerator no longer creating ~3
MediaCodec instances to determine the codec name during the call to
VideoEncodeAccelerator::GetSupportedProfiles() during child thread
startup. I suspect this will translate into real GPU process startup
improvements.

BUG= 594814 
TEST=codec lists match before after on KitKat below and above.

Review URL: https://codereview.chromium.org/1805163002

Cr-Commit-Position: refs/heads/master@{#381805}

[modify] https://crrev.com/5c1bee20afe6113087fc9a5781b5773a8894bbd4/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java
[modify] https://crrev.com/5c1bee20afe6113087fc9a5781b5773a8894bbd4/media/base/android/media_codec_util.cc

Merge requesting for both since this should improve GPU startup time and should be a no-op for in terms of the blacklist used by WebRTC.

Your change meets the bar and is auto-approved for M50 (branch: 2661)

M51 dev looks like it's coming up, so will wait for these to roll there and then merge.

M51 dev release today includes the blacklist changes. VP8 decoding is working fine AFAICT. If anyone has old / obscure hardware vp8 devices they want to test let me know :)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e6bfabee5b582487a1e5835c5272ead6878a6c53

commit e6bfabee5b582487a1e5835c5272ead6878a6c53
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Mar 21 18:01:31 2016

Merge M50: "Remove Exynos from MediaCodec blacklist. Limit MediaTek blacklist."

MediaCodec has a newer path for limiting the VP8 blacklist more
precisely that should be used instead of a blanket Exynos blacklist.

MediaTek nowadays also has a vp9 decoder, so restrict blacklist to
only vp8 MediaTek devices. Per glaznev@ the MediaTek vp8 decoder is
slower than software, so it kind of makes sense to include it on
the "known unaccelerated" list.

BUG=446974,  594814 
TEST=hardware vp9 on galaxy s6 works with <video>.

Review URL: https://codereview.chromium.org/1796393002

Cr-Commit-Position: refs/heads/master@{#381322}
(cherry picked from commit fb7409de2920256bca4a678a030198d6a99f2709)

Review URL: https://codereview.chromium.org/1821003002 .

Cr-Commit-Position: refs/branch-heads/2661@{#319}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/e6bfabee5b582487a1e5835c5272ead6878a6c53/content/common/gpu/media/android_video_encode_accelerator.cc
[modify] https://crrev.com/e6bfabee5b582487a1e5835c5272ead6878a6c53/media/base/android/media_codec_util.cc
[modify] https://crrev.com/e6bfabee5b582487a1e5835c5272ead6878a6c53/media/base/android/media_codec_util.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5d1be6b220032081d607aeff1a97a686302dc284

commit 5d1be6b220032081d607aeff1a97a686302dc284
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Mar 21 18:04:31 2016

Merge M50: "Cleanup MediaCodecUtil::GetDefaultCodecName()."

There's no need to build an entire list of codecs and transport that
across JNI when we always want the first one in the list.

Notably this reduces the cost of GpuChildThread::OnInitialize() by
over 400ms on an N5 running Marshmallow (450.208ms vs 39.64ms)! The
reduction comes from VideoEncodeAccelerator no longer creating ~3
MediaCodec instances to determine the codec name during the call to
VideoEncodeAccelerator::GetSupportedProfiles() during child thread
startup. I suspect this will translate into real GPU process startup
improvements.

BUG= 594814 
TEST=codec lists match before after on KitKat below and above.

Review URL: https://codereview.chromium.org/1805163002

Cr-Commit-Position: refs/heads/master@{#381805}
(cherry picked from commit 5c1bee20afe6113087fc9a5781b5773a8894bbd4)

Review URL: https://codereview.chromium.org/1819953002 .

Cr-Commit-Position: refs/branch-heads/2661@{#320}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/5d1be6b220032081d607aeff1a97a686302dc284/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java
[modify] https://crrev.com/5d1be6b220032081d607aeff1a97a686302dc284/media/base/android/media_codec_util.cc