Fix WebRtcFrameScheduler to wait for first key frame request.

Fix WebRtcFrameScheduler to wait for first key frame request.

Previous the scheduler would start capturing before the stream is
negotiated, which was causing first few frames to be dropped. Now it
waits for the first key frame request.

BUG=616637
Committed: https://crrev.com/ad2be8fa3ed226fa3910a13c1261f5ddd42ff385
Cr-Commit-Position: refs/heads/master@{#397669}

[Sergey Ulanov, 2016-06-02 16:26:12]

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

[Irfan, 2016-06-02 19:06:00]

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/connectio...
File remoting/protocol/connection_unittest.cc (right):

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/connectio...
remoting/protocol/connection_unittest.cc:74: // Return black 10x10 frame.
Is this 10x10 comment right ?

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/connectio...
remoting/protocol/connection_unittest.cc:79: first_frame_sent_ = true;
Can you please explain what this does ?

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/connectio...
remoting/protocol/connection_unittest.cc:327:
host_session_->set_signaling_delay(base::TimeDelta::FromMilliseconds(200));
Comment seems to indicate this is ICE specific, but there is no check here for
webrtc ?

Are you trying to simulate delay on ICE alongside webrtc ?

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

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/webrtc_fr...
remoting/protocol/webrtc_frame_scheduler.cc:10: #include "base/location.h"
what is this used for ?

[Sergey Ulanov, 2016-06-03 06:01:23]

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/connectio...
File remoting/protocol/connection_unittest.cc (right):

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/connectio...
remoting/protocol/connection_unittest.cc:74: // Return black 10x10 frame.
On 2016/06/02 19:06:00, Irfan wrote:
> Is this 10x10 comment right ?

Done.

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/connectio...
remoting/protocol/connection_unittest.cc:79: first_frame_sent_ = true;
On 2016/06/02 19:06:00, Irfan wrote:
> Can you please explain what this does ?

added a comment.

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/connectio...
remoting/protocol/connection_unittest.cc:327:
host_session_->set_signaling_delay(base::TimeDelta::FromMilliseconds(200));
On 2016/06/02 19:06:00, Irfan wrote:
> Comment seems to indicate this is ICE specific, but there is no check here for
> webrtc ?
> 
> Are you trying to simulate delay on ICE alongside webrtc ?

ICE is used internally it WebRTC too. But this comment is confusing. Replaced
ICE with "connection handshake"

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

https://codereview.chromium.org/2035803002/diff/1/remoting/protocol/webrtc_fr...
remoting/protocol/webrtc_frame_scheduler.cc:10: #include "base/location.h"
On 2016/06/02 19:06:00, Irfan wrote:
> what is this used for ?

it defines FROM_HERE macro used for PostTask()

[Irfan, 2016-06-03 06:34:27]

lgtm

[Sergey Ulanov, 2016-06-03 08:16:29]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2016-06-03 08:16:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2035803002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2035803002/20001

[commit-bot: I haz the power, 2016-06-03 09:03:37]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-06-03 09:04:36]

Description was changed from

==========
Fix WebRtcFrameScheduler to wait for first key frame request.

Previous the scheduler would start capturing before the stream is
negotiated, which was causing first few frames to be dropped. Now it
waits for the first key frame request.

BUG=616637
==========

to

==========
Fix WebRtcFrameScheduler to wait for first key frame request.

Previous the scheduler would start capturing before the stream is
negotiated, which was causing first few frames to be dropped. Now it
waits for the first key frame request.

BUG=616637

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

[commit-bot: I haz the power, 2016-06-03 09:04:37]

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