Account for expected capture and encode latency in WebrtcFrameSchedulerSimple

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.

Committed: https://crrev.com/b6c1d4353b508fb6cb2d28dfd33d847499e982f1
Cr-Commit-Position: refs/heads/master@{#421341}

[Sergey Ulanov, 2016-09-23 22:26:36]

Description was changed from

==========
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.
==========

to

==========
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.
==========

[Sergey Ulanov, 2016-09-23 22:26:36]

sergeyu@chromium.org changed reviewers:
+ isheriff@chromium.org

[Sergey Ulanov, 2016-09-23 23:40:51]

Description was changed from

==========
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.
==========

to

==========
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.
==========

[Irfan, 2016-09-27 18:04:51]

https://codereview.chromium.org/2366053002/diff/1/remoting/protocol/webrtc_fr...
File remoting/protocol/webrtc_frame_scheduler_simple.cc (right):

https://codereview.chromium.org/2366053002/diff/1/remoting/protocol/webrtc_fr...
remoting/protocol/webrtc_frame_scheduler_simple.cc:115:
base::TimeDelta::FromMicroseconds(frame_processing_delay_us_.Max());
assigning expected value to Max() seems confusing. Do we want average or median
here ?

[Sergey Ulanov, 2016-09-27 18:49:09]

https://codereview.chromium.org/2366053002/diff/1/remoting/protocol/webrtc_fr...
File remoting/protocol/webrtc_frame_scheduler_simple.cc (right):

https://codereview.chromium.org/2366053002/diff/1/remoting/protocol/webrtc_fr...
remoting/protocol/webrtc_frame_scheduler_simple.cc:115:
base::TimeDelta::FromMicroseconds(frame_processing_delay_us_.Max());
On 2016/09/27 18:04:51, Irfan wrote:
> assigning expected value to Max() seems confusing. Do we want average or
median
> here ?

I think we want to approximate the upper bound of the expected capture/encode
time. This will make it more likely the frame will be ready to sent right after
the previous frame. I actually first tried Average() here, and Max() works
better in tests (at least with current BWE logic).

[Irfan, 2016-09-27 20:54:07]

lgtm

[Sergey Ulanov, 2016-09-27 21:04:39]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2016-09-27 21:05:03]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-27 21:34:13]

Description was changed from

==========
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.
==========

to

==========
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.
==========

[commit-bot: I haz the power, 2016-09-27 21:34:14]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-27 21:37:39]

Description was changed from

==========
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.
==========

to

==========
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.

Committed: https://crrev.com/b6c1d4353b508fb6cb2d28dfd33d847499e982f1
Cr-Commit-Position: refs/heads/master@{#421341}
==========

[commit-bot: I haz the power, 2016-09-27 21:37:39]

Patchset 1 (id:??) landed as
https://crrev.com/b6c1d4353b508fb6cb2d28dfd33d847499e982f1
Cr-Commit-Position: refs/heads/master@{#421341}