Fix WebrtcVideoCapturerAdapter to emit frames even when nothing is changing.

Fix WebrtcVideoCapturerAdapter to emit frames even when nothing is changing.

Previously the adapter was signaling SignalVideoFrame only when the
frame has changes. Video sender in Webrtc stack may drop some frames
because VideoCapturer interface assumes that SignalVideoFrame is called
regularly. As results the changes were sometimes delivered to the
client too late. This change is a stopgap solution until we have
proper frame capture scheduling that integrates with the video sender
in webrtc.

BUG=547158
Committed: https://crrev.com/9885938514890759da65019cbce59c1d637a2c6b
Cr-Commit-Position: refs/heads/master@{#377459}

[Sergey Ulanov, 2016-02-24 21:04:01]

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

[Jamie, 2016-02-24 23:31:38]

lgtm

https://codereview.chromium.org/1740443002/diff/1/remoting/protocol/webrtc_vi...
File remoting/protocol/webrtc_video_capturer_adapter.cc (right):

https://codereview.chromium.org/1740443002/diff/1/remoting/protocol/webrtc_vi...
remoting/protocol/webrtc_video_capturer_adapter.cc:164: if (!frame)
If this is a stop-gap solution, does it warrant a TODO?

[Sergey Ulanov, 2016-02-25 00:50:15]

https://codereview.chromium.org/1740443002/diff/1/remoting/protocol/webrtc_vi...
File remoting/protocol/webrtc_video_capturer_adapter.cc (right):

https://codereview.chromium.org/1740443002/diff/1/remoting/protocol/webrtc_vi...
remoting/protocol/webrtc_video_capturer_adapter.cc:164: if (!frame)
On 2016/02/24 23:31:38, Jamie wrote:
> If this is a stop-gap solution, does it warrant a TODO?

Done.

[Sergey Ulanov, 2016-02-25 00:50:45]

The CQ bit was checked by sergeyu@chromium.org

[Sergey Ulanov, 2016-02-25 00:50:46]

The patchset sent to the CQ was uploaded after l-g-t-m from
jamiewalch@chromium.org
Link to the patchset: https://codereview.chromium.org/1740443002/#ps20001
(title: " ")

[commit-bot: I haz the power, 2016-02-25 00:56:00]

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

[commit-bot: I haz the power, 2016-02-25 01:44:59]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-02-25 01:46:03]

Description was changed from

==========
Fix WebrtcVideoCapturerAdapter to emit frames even when nothing is changing.

Previously the adapter was signaling SignalVideoFrame only when the
frame has changes. Video sender in Webrtc stack may drop some frames
because VideoCapturer interface assumes that SignalVideoFrame is called
regularly. As results the changes were sometimes delivered to the
client too late. This change is a stopgap solution until we have
proper frame capture scheduling that integrates with the video sender
in webrtc.

BUG=547158
==========

to

==========
Fix WebrtcVideoCapturerAdapter to emit frames even when nothing is changing.

Previously the adapter was signaling SignalVideoFrame only when the
frame has changes. Video sender in Webrtc stack may drop some frames
because VideoCapturer interface assumes that SignalVideoFrame is called
regularly. As results the changes were sometimes delivered to the
client too late. This change is a stopgap solution until we have
proper frame capture scheduling that integrates with the video sender
in webrtc.

BUG=547158

Committed: https://crrev.com/9885938514890759da65019cbce59c1d637a2c6b
Cr-Commit-Position: refs/heads/master@{#377459}
==========

[commit-bot: I haz the power, 2016-02-25 01:46:03]

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