Implement a high-QP threshold for Android H.264.

Implement a high-QP threshold for Android H.264.

Android hardware H.264 seems to keep a steady high-QP flow instead of
dropping frames, so framedrops aren't sufficient to detect a bad state
where downscaling would be beneficial.

BUG=webrtc:4968
R=magjed@webrtc.org, stefan@webrtc.org

Committed: https://crrev.com/17417707428816ffb88d9c71dcc8a5d492cf9fdf
Cr-Commit-Position: refs/heads/master@{#10078}

[pbos-webrtc, 2015-09-24 14:24:26]

PTAL again woo

[magjed_webrtc, 2015-09-24 14:38:23]

androidmediaencoder_jni.cc lgtm

[stefan-webrtc, 2015-09-25 14:18:02]

https://codereview.webrtc.org/1364253002/diff/1/talk/app/webrtc/java/jni/andr...
File talk/app/webrtc/java/jni/androidmediaencoder_jni.cc (right):

https://codereview.webrtc.org/1364253002/diff/1/talk/app/webrtc/java/jni/andr...
talk/app/webrtc/java/jni/androidmediaencoder_jni.cc:320: true);
Maybe we should consider disabling this until we have evaluated if it really
improves quality to drop framerate in half? Mostly to avoid getting stuck at low
framerate and things.

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/c...
File webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc (left):

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/c...
webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc:897:
codec_.simulcastStream[0].height = input_image.height();
w00t?

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/c...
File webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc (right):

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/c...
webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc:585: // VP8.
Don't need these comemnts. libvpx handles this

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/u...
File webrtc/modules/video_coding/utility/quality_scaler.cc (right):

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/u...
webrtc/modules/video_coding/utility/quality_scaler.cc:79: avg_qp >
high_qp_threshold_)) {
We should reevaluate if dropping to half framerate actually gives us a
significantly lower qp.

Maybe we should drop frames temporarily to keep QP below max QP. If we can't do
that with a reasonable framerate we go down in resolution?

I think this needs evaluation anyway.

[stefan-webrtc, 2015-09-25 14:18:09]

lgtm

[pbos-webrtc, 2015-09-25 14:24:00]

feedback

[pbos-webrtc, 2015-09-25 14:24:08]

Woo!

https://codereview.webrtc.org/1364253002/diff/1/talk/app/webrtc/java/jni/andr...
File talk/app/webrtc/java/jni/androidmediaencoder_jni.cc (right):

https://codereview.webrtc.org/1364253002/diff/1/talk/app/webrtc/java/jni/andr...
talk/app/webrtc/java/jni/androidmediaencoder_jni.cc:320: true);
On 2015/09/25 14:18:02, stefan-webrtc (holmer) wrote:
> Maybe we should consider disabling this until we have evaluated if it really
> improves quality to drop framerate in half? Mostly to avoid getting stuck at
low
> framerate and things.

Done.

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/c...
File webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc (left):

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/c...
webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc:897:
codec_.simulcastStream[0].height = input_image.height();
On 2015/09/25 14:18:02, stefan-webrtc (holmer) wrote:
> w00t?

Oops, I think I tested some locally. Don't remember, put it back.

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/c...
File webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc (right):

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/c...
webrtc/modules/video_coding/codecs/vp8/vp8_impl.cc:585: // VP8.
On 2015/09/25 14:18:02, stefan-webrtc (holmer) wrote:
> Don't need these comemnts. libvpx handles this

Done.

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/u...
File webrtc/modules/video_coding/utility/quality_scaler.cc (right):

https://codereview.webrtc.org/1364253002/diff/1/webrtc/modules/video_coding/u...
webrtc/modules/video_coding/utility/quality_scaler.cc:79: avg_qp >
high_qp_threshold_)) {
On 2015/09/25 14:18:02, stefan-webrtc (holmer) wrote:
> We should reevaluate if dropping to half framerate actually gives us a
> significantly lower qp.
> 
> Maybe we should drop frames temporarily to keep QP below max QP. If we can't
do
> that with a reasonable framerate we go down in resolution?
> 
> I think this needs evaluation anyway.

Acknowledged.

[pbos-webrtc, 2015-09-25 14:24:18]

The CQ bit was checked by pbos@webrtc.org

[pbos-webrtc, 2015-09-25 14:24:18]

The patchset sent to the CQ was uploaded after l-g-t-m from magjed@webrtc.org,
stefan@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1364253002/#ps20001 (title:
"feedback")

[commit-bot: I haz the power, 2015-09-25 14:24:34]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1364253002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1364253002/20001

[pbos-webrtc, 2015-09-25 15:03:42]

Committed patchset #2 (id:20001) manually as
17417707428816ffb88d9c71dcc8a5d492cf9fdf (presubmit successful).

[commit-bot: I haz the power, 2015-09-25 15:03:48]

Patchset 2 (id:??) landed as
https://crrev.com/17417707428816ffb88d9c71dcc8a5d492cf9fdf
Cr-Commit-Position: refs/heads/master@{#10078}