Brave, do you want to take look at this one?

We probably have to add a device blacklist/whitelist, just as we do with echo cancellers. "work" means different things for different devices.

Issue 633360 has been merged into this issue.

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

commit 899bc7e19a29e09965d6954a51dde29999ac815b
Author: braveyao <braveyao@chromium.org>
Date: Mon Oct 17 23:55:09 2016

Android: enable/disable WebRTC HW H264 with a flag.

This cl is to enable/disable HW H264 codec on Android by
expanding an existing flag.
Qcom and Exynos codecs (with given minimum SDKs) are  white-listed at this stage.
Also there is a black list to excludes known models with
poor performance.
This cl also includes some basic performance tuning to make
sure video works normally under most common scenarios.
More study on it will be done in the following working.

BUG =  615108 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2358683002
Cr-Commit-Position: refs/heads/master@{#425819}

[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/chrome/app/generated_resources.grd
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/chrome/browser/about_flags.cc
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/content/public/browser/gpu_utils.cc
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/content/public/common/content_switches.cc
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/content/public/common/content_switches.h
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/content/renderer/media/gpu/rtc_video_encoder_factory.cc
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/content/renderer/media/webrtc/peer_connection_dependency_factory.cc
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/gpu/config/software_rendering_list_json.cc
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/media/base/android/java/src/org/chromium/media/MediaCodecBridge.java
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/media/base/android/media_codec_util.cc
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/media/base/android/media_codec_util.h
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/media/gpu/android_video_encode_accelerator.cc
[modify] https://crrev.com/899bc7e19a29e09965d6954a51dde29999ac815b/media/gpu/android_video_encode_accelerator.h

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

commit 24fb7732dd44b585fac9dd46d5a04678f6eece6c
Author: braveyao <braveyao@chromium.org>
Date: Thu Oct 20 01:05:11 2016

Android: tuning Exynos HW H264 encoding performance.

Exynos H.264 HW encoder implementation assumes constant frame rate and
does not adjust when actual frame rate is different from the original value.
For example,  when encoder is intialized with 30fps and we want to adapt to
1000kbps@15fps now, we will only get 500kbps@15fps. So we will adjust the
target bps to 2000kbps@15fps to achieve the expected 1000kbps.

BUG= 615108 

Review-Url: https://chromiumcodereview.appspot.com/2434053002
Cr-Commit-Position: refs/heads/master@{#426361}

[modify] https://crrev.com/24fb7732dd44b585fac9dd46d5a04678f6eece6c/media/base/android/java/src/org/chromium/media/MediaCodecBridge.java
[modify] https://crrev.com/24fb7732dd44b585fac9dd46d5a04678f6eece6c/media/base/android/java/src/org/chromium/media/MediaCodecUtil.java
[modify] https://crrev.com/24fb7732dd44b585fac9dd46d5a04678f6eece6c/media/base/android/sdk_media_codec_bridge.cc
[modify] https://crrev.com/24fb7732dd44b585fac9dd46d5a04678f6eece6c/media/base/android/sdk_media_codec_bridge.h
[modify] https://crrev.com/24fb7732dd44b585fac9dd46d5a04678f6eece6c/media/gpu/android_video_encode_accelerator.cc

The existing #disable-webrtc-hw-encoding is expanded with multiple values to control VP8 and H264 HW encoding respectively. 
On Android HW encoding is disabled by default. 

Notes: it's a little confusing since it's a double negative choice. 'Disable VPx' means enabling H264, and 'Disable None' means enabling both VPx&H264 :)

Does this affect all RTCVideoEncodeAccelerator users (I'm interested in MediaRecorder).

Also, what exactly is the sequence of flags needed to enable VP8/9 and/or 
H264 using RTCVideoEncodeAccelerator?

What's the RTCVideoEncodeAccelerator you mentioned?
Since HW encoding still be disabled on Android to all by default, I suppose it's YES to your question.

There is only one flag with multiple values, so no sequence thing. Just choose the value you need.

[bulk-edit : please ignore if not applicable]

Could you please set the correct milestone for this issue?

Verified in Pixel in M56 Dev 56.0.2924.18 
I chose "Disable vpx hw encoding" or "Disable none hw encoding" flags to enable H264 and verified that H264 calls (aaprtc loopback and p2p) work as expected