Configure OpenH264 sSliceArgument.uiSliceNum set to 1.

It seems that if encoder_params.sSpatialLayers[0].sSliceArgument.uiSliceNum is configured to number of cores as determined by openh264 (or any number > 1 in my local tests), frame rate statistics will be mucked up (apparently thousands of frames per second) and quality will bottom out because bits per frame is then very low.

BUG=webrtc:6583
Committed: https://crrev.com/ca27f9d5b9d0121d1a38417268fc2316dcd30d49
Cr-Commit-Position: refs/heads/master@{#14842}

[sprang_webrtc, 2016-10-27 12:31:24]

Description was changed from

==========
Configure OpenH264 slice num with webrtc thread count.

It seems that if encoder_params.iMultipleThreadIdc is 1 but
encoder_params.sSpatialLayers[0].sSliceArgument.uiSliceNum is number of
cores as determined by openh264, frame rate statistics will be mucked up
and quality will bottom out.

BUG=webrtc:6583
==========

to

==========
It seems that if encoder_params.sSpatialLayers[0].sSliceArgument.uiSliceNum is
configured to number of cores as determined by openh264 (or any number > 1 in my
local tests), frame rate statistics will be mucked up (apparently thousands of
frames per second) and quality will bottom out because bits per frame is then
very low.

BUG=webrtc:6583
==========

[sprang_webrtc, 2016-10-27 12:32:08]

sprang@webrtc.org changed reviewers:
+ hbos@webrtc.org

[hbos, 2016-10-28 09:01:03]

LGTM

Remember to do the same change in Chromium so that the other encoder does not
hit the same performance regression.

https://codereview.webrtc.org/2458673002/diff/1/webrtc/modules/video_coding/c...
File webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc (right):

https://codereview.webrtc.org/2458673002/diff/1/webrtc/modules/video_coding/c...
webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc:447:
encoder_params.iMultipleThreadIdc;
Do we know that n works if number of threads are n>1? I.e, should this be 1 or
n? In either case we'll notice when n changes from hard-coded 1.

[sprang_webrtc, 2016-10-31 09:22:29]

https://codereview.webrtc.org/2458673002/diff/1/webrtc/modules/video_coding/c...
File webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc (right):

https://codereview.webrtc.org/2458673002/diff/1/webrtc/modules/video_coding/c...
webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc:447:
encoder_params.iMultipleThreadIdc;
On 2016/10/28 09:01:03, hbos wrote:
> Do we know that n works if number of threads are n>1? I.e, should this be 1 or
> n? In either case we'll notice when n changes from hard-coded 1.

I tried with 4 thread and uiSliceNum 4 and the rate controller is still borked.
Hard-coding to 1 instead and adding todo about following up on seeming OpenH264
bug.

[hbos, 2016-10-31 09:23:34]

https://codereview.webrtc.org/2458673002/diff/1/webrtc/modules/video_coding/c...
File webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc (right):

https://codereview.webrtc.org/2458673002/diff/1/webrtc/modules/video_coding/c...
webrtc/modules/video_coding/codecs/h264/h264_encoder_impl.cc:447:
encoder_params.iMultipleThreadIdc;
On 2016/10/31 09:22:29, språng wrote:
> On 2016/10/28 09:01:03, hbos wrote:
> > Do we know that n works if number of threads are n>1? I.e, should this be 1
or
> > n? In either case we'll notice when n changes from hard-coded 1.
> 
> I tried with 4 thread and uiSliceNum 4 and the rate controller is still
borked.
> Hard-coding to 1 instead and adding todo about following up on seeming
OpenH264
> bug.

sgtm

[sprang_webrtc, 2016-10-31 09:40:17]

The CQ bit was checked by sprang@webrtc.org

[sprang_webrtc, 2016-10-31 09:40:18]

The patchset sent to the CQ was uploaded after l-g-t-m from hbos@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2458673002/#ps20001 (title:
"Set uiSliceNum = 1 until rate controller is fixed")

[commit-bot: I haz the power, 2016-10-31 09:40:20]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2016-10-31 10:43:41]

Description was changed from

==========
It seems that if encoder_params.sSpatialLayers[0].sSliceArgument.uiSliceNum is
configured to number of cores as determined by openh264 (or any number > 1 in my
local tests), frame rate statistics will be mucked up (apparently thousands of
frames per second) and quality will bottom out because bits per frame is then
very low.

BUG=webrtc:6583
==========

to

==========
It seems that if encoder_params.sSpatialLayers[0].sSliceArgument.uiSliceNum is
configured to number of cores as determined by openh264 (or any number > 1 in my
local tests), frame rate statistics will be mucked up (apparently thousands of
frames per second) and quality will bottom out because bits per frame is then
very low.

BUG=webrtc:6583
==========

[commit-bot: I haz the power, 2016-10-31 10:43:41]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-10-31 10:43:52]

Description was changed from

==========
It seems that if encoder_params.sSpatialLayers[0].sSliceArgument.uiSliceNum is
configured to number of cores as determined by openh264 (or any number > 1 in my
local tests), frame rate statistics will be mucked up (apparently thousands of
frames per second) and quality will bottom out because bits per frame is then
very low.

BUG=webrtc:6583
==========

to

==========
It seems that if encoder_params.sSpatialLayers[0].sSliceArgument.uiSliceNum is
configured to number of cores as determined by openh264 (or any number > 1 in my
local tests), frame rate statistics will be mucked up (apparently thousands of
frames per second) and quality will bottom out because bits per frame is then
very low.

BUG=webrtc:6583

Committed: https://crrev.com/ca27f9d5b9d0121d1a38417268fc2316dcd30d49
Cr-Commit-Position: refs/heads/master@{#14842}
==========

[commit-bot: I haz the power, 2016-10-31 10:43:53]

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