diff options
| author | pbos@webrtc.org <pbos@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> | 2014-02-12 14:50:29 +0000 |
|---|---|---|
| committer | pbos@webrtc.org <pbos@webrtc.org@4adac7df-926f-26a2-2b94-8c16560cd09d> | 2014-02-12 14:50:29 +0000 |
| commit | 8118f1861fbbcb4f2f450ad9b4a42d4b5c175840 (patch) | |
| tree | cc5140f3d30b2d78048d2b174c16a4f66dd69f6c /webrtc/modules/audio_processing/test/unpack.cc | |
| parent | 67e70442b56fb63b7b9f2079ec19aeed4419ba44 (diff) | |
| download | webrtc-8118f1861fbbcb4f2f450ad9b4a42d4b5c175840.tar.gz | |
Set pacing bitrates in SetEncoder.
Before the change no padding was allowed before the first remote bitrate
estimation was received. This bitrate estimation is based on what's
actually sent. In tests I set codec.startBitrate to 300 instead of
325, which incidentally means that only the first layer gets encoded.
As we only send ~150kbps instead of 300, the first REMB will
significantly pull down the remote bitrate estimate instead of keeping
the existing rate, even though there's no problem with the link.
This was detected in RampUpTest.PacingWithRtx,
(send_config.codec.startBitrate=300), which caused the tests to become a
lot slower, and flake out more. By allowing padding initially we're able
to keep our initial bitrate estimate.
R=stefan@webrtc.org
TEST=Running RampUpTest.WithPacingAndRtx with startBandwidth=300.
BUG=
Review URL: https://webrtc-codereview.appspot.com/8529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5534 4adac7df-926f-26a2-2b94-8c16560cd09d
Diffstat (limited to 'webrtc/modules/audio_processing/test/unpack.cc')
0 files changed, 0 insertions, 0 deletions