Fix capture ntp time issue introduced with r11187.

Fix capture ntp time issue introduced with r11187.

I think the problem was that I only introduced delay in one direction, and the estimation assumes that the RTT is evenly divided between the send direction and the receive direction, which was true for the old test.

BUG=chromium:576246
R=pbos@webrtc.org

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

[stefan-webrtc, 2016-01-12 15:57:45]

stefan@webrtc.org changed reviewers:
+ pbos@webrtc.org

[stefan-webrtc, 2016-01-12 16:00:18]

Description was changed from

==========
Fix capture ntp time issue introduced with r11187.

BUG=chromium:576246
==========

to

==========
Fix capture ntp time issue introduced with r11187.

I think the problem was that I only introduced delay in one direction, and the
estimation assumes that the RTT is evenly divided between the send direction and
the receive direction, which was true for the old test.

BUG=chromium:576246
==========

[pbos-webrtc, 2016-01-12 16:11:43]

lgtm

[stefan-webrtc, 2016-01-12 16:12:57]

The CQ bit was checked by stefan@webrtc.org

[commit-bot: I haz the power, 2016-01-12 16:13:03]

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

[commit-bot: I haz the power, 2016-01-12 18:13:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-01-12 18:13:19]

Try jobs failed on following builders:
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  linux_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  win_baremetal on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[stefan-webrtc, 2016-01-13 07:58:56]

Description was changed from

==========
Fix capture ntp time issue introduced with r11187.

I think the problem was that I only introduced delay in one direction, and the
estimation assumes that the RTT is evenly divided between the send direction and
the receive direction, which was true for the old test.

BUG=chromium:576246
==========

to

==========
Fix capture ntp time issue introduced with r11187.

I think the problem was that I only introduced delay in one direction, and the
estimation assumes that the RTT is evenly divided between the send direction and
the receive direction, which was true for the old test.

BUG=chromium:576246
R=pbos@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/ea8c0f6fcbd79fd3933cf2f25...
==========

[stefan-webrtc, 2016-01-13 07:58:57]

Committed patchset #1 (id:1) manually as
ea8c0f6fcbd79fd3933cf2f2511a8900c1a9344a (presubmit successful).

[commit-bot: I haz the power, 2016-01-13 07:58:58]

Description was changed from

==========
Fix capture ntp time issue introduced with r11187.

I think the problem was that I only introduced delay in one direction, and the
estimation assumes that the RTT is evenly divided between the send direction and
the receive direction, which was true for the old test.

BUG=chromium:576246
R=pbos@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/ea8c0f6fcbd79fd3933cf2f25...
==========

to

==========
Fix capture ntp time issue introduced with r11187.

I think the problem was that I only introduced delay in one direction, and the
estimation assumes that the RTT is evenly divided between the send direction and
the receive direction, which was true for the old test.

BUG=chromium:576246
R=pbos@webrtc.org

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

[commit-bot: I haz the power, 2016-01-13 07:58:59]

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