Fix flake in TwoStreamsSendAndReceive.

Fix flake in TwoStreamsSendAndReceive.

Whether two streams get 300k or 150k as initial bitrate is flaky, since
InitEncode may happen asynchronously either before or after two streams
have shared the 300k, meaning that the first sender either thinks it
should start at 300k or at 150k.

This should ideally be fixed by reconfiguring encoders to use QVGA if a
lower estimate arrives before the first frame is encoded, but right now
that would require reconfigure logic in all VideoEncoder wrappers, which
is also less than ideal. It would be good to revisit this once
QualityScaler moves outside the VideoEncoder implementations (into
GenericEncoder).

BUG=webrtc:5678
R=stefan@webrtc.org

Committed: https://crrev.com/d1f584bb06a0c042a17408072d4c7691915db6b9
Cr-Commit-Position: refs/heads/master@{#12448}

[pbos-webrtc, 2016-04-20 14:17:35]

Description was changed from

==========
Fix flake in TwoStreamsSendAndReceive.

Whether two streams get 300k or 150k as initial bitrate is flaky, since
InitEncode may happen asynchronously either before or after two streams
have shared the 300k, meaning that the first sender either thinks it
should start at 300k or 150k.

This should ideally be fixed by reconfiguring encoders to use QVGA if a
lower estimate arrives before the first frame is encoded, but right now
that would require reconfigure logic in all VideoEncoder wrappers, which
is also less than ideal. It would be good to revisit this once
QualityScaler moves outside the VideoEncoder implementations (into
GenericEncoder).

BUG=webrtc:5678
R=stefan@webrtc.org
==========

to

==========
Fix flake in TwoStreamsSendAndReceive.

Whether two streams get 300k or 150k as initial bitrate is flaky, since
InitEncode may happen asynchronously either before or after two streams
have shared the 300k, meaning that the first sender either thinks it
should start at 300k or at 150k.

This should ideally be fixed by reconfiguring encoders to use QVGA if a
lower estimate arrives before the first frame is encoded, but right now
that would require reconfigure logic in all VideoEncoder wrappers, which
is also less than ideal. It would be good to revisit this once
QualityScaler moves outside the VideoEncoder implementations (into
GenericEncoder).

BUG=webrtc:5678
R=stefan@webrtc.org
==========

[pbos-webrtc, 2016-04-20 14:17:51]

PTAL

[stefan-webrtc, 2016-04-20 14:26:59]

lgtm

https://codereview.webrtc.org/1902413002/diff/1/webrtc/media/engine/webrtcvid...
File webrtc/media/engine/webrtcvideoengine2_unittest.cc (right):

https://codereview.webrtc.org/1902413002/diff/1/webrtc/media/engine/webrtcvid...
webrtc/media/engine/webrtcvideoengine2_unittest.cc:876: // initially will use
QVGA instead of VGA initially.
Remove one "initially"

[pbos-webrtc, 2016-04-20 14:30:56]

remove one initially

[pbos-webrtc, 2016-04-20 14:32:05]

Description was changed from

==========
Fix flake in TwoStreamsSendAndReceive.

Whether two streams get 300k or 150k as initial bitrate is flaky, since
InitEncode may happen asynchronously either before or after two streams
have shared the 300k, meaning that the first sender either thinks it
should start at 300k or at 150k.

This should ideally be fixed by reconfiguring encoders to use QVGA if a
lower estimate arrives before the first frame is encoded, but right now
that would require reconfigure logic in all VideoEncoder wrappers, which
is also less than ideal. It would be good to revisit this once
QualityScaler moves outside the VideoEncoder implementations (into
GenericEncoder).

BUG=webrtc:5678
R=stefan@webrtc.org
==========

to

==========
Fix flake in TwoStreamsSendAndReceive.

Whether two streams get 300k or 150k as initial bitrate is flaky, since
InitEncode may happen asynchronously either before or after two streams
have shared the 300k, meaning that the first sender either thinks it
should start at 300k or at 150k.

This should ideally be fixed by reconfiguring encoders to use QVGA if a
lower estimate arrives before the first frame is encoded, but right now
that would require reconfigure logic in all VideoEncoder wrappers, which
is also less than ideal. It would be good to revisit this once
QualityScaler moves outside the VideoEncoder implementations (into
GenericEncoder).

BUG=webrtc:5678
R=stefan@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/d1f584bb06a0c042a17408072...
==========

[pbos-webrtc, 2016-04-20 14:32:06]

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

[commit-bot: I haz the power, 2016-04-20 14:58:55]

Description was changed from

==========
Fix flake in TwoStreamsSendAndReceive.

Whether two streams get 300k or 150k as initial bitrate is flaky, since
InitEncode may happen asynchronously either before or after two streams
have shared the 300k, meaning that the first sender either thinks it
should start at 300k or at 150k.

This should ideally be fixed by reconfiguring encoders to use QVGA if a
lower estimate arrives before the first frame is encoded, but right now
that would require reconfigure logic in all VideoEncoder wrappers, which
is also less than ideal. It would be good to revisit this once
QualityScaler moves outside the VideoEncoder implementations (into
GenericEncoder).

BUG=webrtc:5678
R=stefan@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/d1f584bb06a0c042a17408072...
==========

to

==========
Fix flake in TwoStreamsSendAndReceive.

Whether two streams get 300k or 150k as initial bitrate is flaky, since
InitEncode may happen asynchronously either before or after two streams
have shared the 300k, meaning that the first sender either thinks it
should start at 300k or at 150k.

This should ideally be fixed by reconfiguring encoders to use QVGA if a
lower estimate arrives before the first frame is encoded, but right now
that would require reconfigure logic in all VideoEncoder wrappers, which
is also less than ideal. It would be good to revisit this once
QualityScaler moves outside the VideoEncoder implementations (into
GenericEncoder).

BUG=webrtc:5678
R=stefan@webrtc.org

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

[commit-bot: I haz the power, 2016-04-20 14:58:55]

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