Account for expected capture and encode latency in WebrtcFrameSchedulerSimple
Previously when scheduling video frames the scheduler was taking into account only expected pacer queue delay, but not the capturer/encoder latency. Now the scheduler keeps queue of 5 most recent samples and uses it to schedule each frame such that it's ready to be sent right after the previous frame leaves the pacer. This change improves bandwidth utilization in the ScrollPerformanceWebrtc test from 30 to 50% without any effect on latency. Review-Url: https://codereview.chromium.org/2366053002 Cr-Commit-Position: refs/heads/master@{#421341}
Showing
Please register or sign in to comment