commit 7d0cde5117f98bdfce7fa79a75d48644fb54b1c0
author Erik Språng <sprang@webrtc.org> Sun Jul 19 10:48:16 2020
committer Commit Bot <commit-bot@chromium.org> Wed Jul 22 00:58:49 2020
tree 06df9b2f50fd8b5862cd3d68d90f4e6c7cf7aa01
parent 708b22cd0384ba5ceafd153c47e28f541c215ea6

Minimizes risk of probes being late when using TaskQueuePacedSender.

The time precision of delayed tasks is one millisecond, so the
TaskQueuePacedSender makes sure that is the minimum sleep time, and
then allows sending prior data as if it was on time.

Furthermore, if there already exists a pending task within 1ms of a
new desired process time - we don't schedule a new one with the same
motivation as above.

These two facts clashes somewhat with how BitrateProber works, and
especially if they coincide it can result in scheduled ProcessPackets()
that is 2ms late. The default timeout set in BitrateProber is 3ms, so
there is a higher risk of probes timing out.

This CL changes the TaskQueuePacedSender to allow scheduling a
ProcesPackets() call as soon as possible if we are probing - even if
that means executing up to 1ms earlier than expected (the BitrateProber
will compensate for that). The PacingController is updated in order to
allow early execution in this one case.

Bug: webrtc:10809
Change-Id: Ia5097ddc39aa80c05ebfe56369310c94ef0e0baf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178901
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31778}