mirror of
https://github.com/mollyim/webrtc.git
synced 2025-05-15 06:40:43 +01:00
7d0cde5117
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} |
||
|---|---|---|
| .. | ||
| bitrate_prober.cc | ||
| bitrate_prober.h | ||
| bitrate_prober_unittest.cc | ||
| BUILD.gn | ||
| DEPS | ||
| interval_budget.cc | ||
| interval_budget.h | ||
| interval_budget_unittest.cc | ||
| OWNERS | ||
| paced_sender.cc | ||
| paced_sender.h | ||
| paced_sender_unittest.cc | ||
| pacing_controller.cc | ||
| pacing_controller.h | ||
| pacing_controller_unittest.cc | ||
| packet_router.cc | ||
| packet_router.h | ||
| packet_router_unittest.cc | ||
| round_robin_packet_queue.cc | ||
| round_robin_packet_queue.h | ||
| rtp_packet_pacer.h | ||
| task_queue_paced_sender.cc | ||
| task_queue_paced_sender.h | ||
| task_queue_paced_sender_unittest.cc | ||