Only use paced packets for estimating bitrate probes.

Only use paced packets for estimating bitrate probes.

BUG=webrtc:4778
R=mflodman@webrtc.org, solenberg@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/ff4ea9310e981da6292fb044cff9eeefd986cf2b

[stefan-webrtc, 2015-06-18 08:17:23]

stefan@webrtc.org changed reviewers:
+ mflodman@webrtc.org, solenberg@webrtc.org

[stefan-webrtc, 2015-06-18 08:17:23]

This solves 4778 by assuming that no received audio packets are paced. When BWE
is all on the send-side we can make this smarter since we actually know what
packets have been paced.

This solution is the same as before audio/video BWE was enabled.

[the sun, 2015-06-18 08:25:54]

On 2015/06/18 08:17:23, stefan-webrtc (holmer) wrote:
> This solves 4778 by assuming that no received audio packets are paced. When
BWE
> is all on the send-side we can make this smarter since we actually know what
> packets have been paced.
> 
> This solution is the same as before audio/video BWE was enabled.

IIUC this is blanket disabling combined BWE?

Then why don't we just do that instead, while working out the long term solution
(pacing audio packets)?

[the sun, 2015-06-18 08:27:05]

On 2015/06/18 08:25:54, the sun wrote:
> On 2015/06/18 08:17:23, stefan-webrtc (holmer) wrote:
> > This solves 4778 by assuming that no received audio packets are paced. When
> BWE
> > is all on the send-side we can make this smarter since we actually know what
> > packets have been paced.
> > 
> > This solution is the same as before audio/video BWE was enabled.
> 
> IIUC this is blanket disabling combined BWE?
> 
> Then why don't we just do that instead, while working out the long term
solution
> (pacing audio packets)?

Ah no, sorry, it's only during probing.

LGTM

[stefan-webrtc, 2015-06-18 08:28:02]

On 2015/06/18 08:25:54, the sun wrote:
> On 2015/06/18 08:17:23, stefan-webrtc (holmer) wrote:
> > This solves 4778 by assuming that no received audio packets are paced. When
> BWE
> > is all on the send-side we can make this smarter since we actually know what
> > packets have been paced.
> > 
> > This solution is the same as before audio/video BWE was enabled.
> 
> IIUC this is blanket disabling combined BWE?
> 
> Then why don't we just do that instead, while working out the long term
solution
> (pacing audio packets)?

No, that shouldn't be the case. It only disables it for the bitrate probing
part, where we pace packets at 3x and 6x the initial bitrate to get an earlier
estimate of what the link can handle. The regular BWE should still use audio
packets as before.

[stefan-webrtc, 2015-06-18 08:28:52]

https://codereview.webrtc.org/1188823007/diff/1/webrtc/modules/remote_bitrate...
File
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.cc
(right):

https://codereview.webrtc.org/1188823007/diff/1/webrtc/modules/remote_bitrate...
webrtc/modules/remote_bitrate_estimator/remote_bitrate_estimator_abs_send_time.cc:405:
}
Note that all code below this line still will be executed for non-paced packets.

[mflodman, 2015-06-18 12:24:59]

LG, but there are no unittest added for this.

[stefan-webrtc, 2015-06-18 13:11:28]

Unittest added, thanks for reminding. :)

[mflodman, 2015-06-18 13:34:00]

Thanks, LGTM!

[stefan-webrtc, 2015-06-18 14:01:50]

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