From a separate chat with asapersson@, the main problem is that on Windows, the reported one-way delay values are so high that they look inaccurate. I'm adding the ReleaseBlock-Beta label to ensure this gets reverted before M51 is rolled out to the larger beta population (i.e. avoid getting a large number of incorrect stats or stat reports)

Questions for asapersson@:
a) Where can we see the affected delay values? As an entry in chrome://histograms, or as a stat in chrome://webrtc-internals?
b) In, say, a 2 person call, can you give an example of what kind of one-way delay values you're seeing that look incorrect, and what kind of values you expected to see instead?

a) chrome://histograms
b) Delay values are around 500 ms while expecting around 200 ms.

> a) chrome://histograms
Specifically, WebRTC.Video.OnewayDelayInMs.

Thanks asapersson@! And FWIW, in the UMA graph you sent me, I see a similar spike in WebRTC.Video.OnewayDelayInMs on Mac and Linux.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/a186288fd0ab5dfc7a1306e7a72b8872230bfdb5

commit a186288fd0ab5dfc7a1306e7a72b8872230bfdb5
Author: asapersson <asapersson@webrtc.org>
Date: Mon Apr 18 07:41:05 2016

Revert of Update histogram "WebRTC.Video.OnewayDelayInMs" to use the estimated one-way delay. (patchset #4 id:60001 of https://codereview.webrtc.org/1688143003/ )

Reason for revert:
The delay stats are high.

Original issue's description:
> Update histogram "WebRTC.Video.OnewayDelayInMs" to use the estimated one-way delay.
> Previous logged delay was: network delay (rtt/2) + jitter delay + decode time + render delay.
>
> Make capture time in local timebase available for decoded VP9 video frames (propagate ntp_time_ms from EncodedImage to decoded VideoFrame).
>
> BUG=
>
> Committed: https://crrev.com/5249599a9b69ad9c2d513210d694719f1011f977
> Cr-Commit-Position: refs/heads/master@{#11901}

TBR=stefan@webrtc.org,pbos@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= chromium:603838 

Review URL: https://codereview.webrtc.org/1893543003

Cr-Commit-Position: refs/heads/master@{#12400}

[modify] https://crrev.com/a186288fd0ab5dfc7a1306e7a72b8872230bfdb5/webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc
[modify] https://crrev.com/a186288fd0ab5dfc7a1306e7a72b8872230bfdb5/webrtc/modules/video_coding/codecs/vp9/vp9_impl.h
[modify] https://crrev.com/a186288fd0ab5dfc7a1306e7a72b8872230bfdb5/webrtc/video/end_to_end_tests.cc
[modify] https://crrev.com/a186288fd0ab5dfc7a1306e7a72b8872230bfdb5/webrtc/video/receive_statistics_proxy.cc
[modify] https://crrev.com/a186288fd0ab5dfc7a1306e7a72b8872230bfdb5/webrtc/video/receive_statistics_proxy.h
[modify] https://crrev.com/a186288fd0ab5dfc7a1306e7a72b8872230bfdb5/webrtc/video/video_receive_stream.cc

Thanks for the revert, asapersson@! If you haven't already, can you work with a sheriff to get a new WebRTC roll with your revert landed in Chrome? 
(I'm also clearing the Mac and Linux OS flags per separate chat - the increases shown in those graphs are expected, and not nearly as high as the corresponding Windows graph)

This bug as been marked as M51 Beta blocker. We've VERY close to M51 beta candidate cut. Please try to resolve this ASAP. Thank you.

While a fix/revert has landed in ToT, I'm not sure we'll have time to verify and merge before this week's M51 beta cut. I'm therefore moving this to RB-Stable.

Have verified that the reported delay now have expected values in ToT after the revert of https://codereview.webrtc.org/1688143003/

Your change meets the bar and is auto-approved for M51 (branch: 2704)

Please merge your change to M51 branch 2704 before 5:00 PM PST Monday (04/25/16) so we can take it for Next week M51 Beta candidate cut. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/8ec8471f8b72ca54af9d923d1af48a041c115f1a

commit 8ec8471f8b72ca54af9d923d1af48a041c115f1a
Author: Asa Persson <asapersson@chromium.org>
Date: Fri Apr 22 11:27:04 2016

Revert of Update histogram "WebRTC.Video.OnewayDelayInMs" to use the estimated one-way delay. (patchset #4 id:60001 of https://codereview.webrtc.org/1688143003/ )

Reason for revert:
The delay stats are high.

Original issue's description:
> Update histogram "WebRTC.Video.OnewayDelayInMs" to use the estimated one-way delay.
> Previous logged delay was: network delay (rtt/2) + jitter delay + decode time + render delay.
>
> Make capture time in local timebase available for decoded VP9 video frames (propagate ntp_time_ms from EncodedImage to decoded VideoFrame).
>
> BUG=
>
> Committed: https://crrev.com/5249599a9b69ad9c2d513210d694719f1011f977
> Cr-Commit-Position: refs/heads/master@{#11901}

TBR=stefan@webrtc.org,pbos@webrtc.org
BUG= chromium:603838 

Review URL: https://codereview.webrtc.org/1893543003

Cr-Commit-Position: refs/heads/master@{#12400}
(cherry picked from commit a186288fd0ab5dfc7a1306e7a72b8872230bfdb5)

Review URL: https://codereview.webrtc.org/1910423002 .

Cr-Commit-Position: refs/branch-heads/51@{#4}
Cr-Branched-From: 5045337133d1da4a657b99e0590eb401515163bd-refs/heads/master@{#12279}

[modify] https://crrev.com/8ec8471f8b72ca54af9d923d1af48a041c115f1a/webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc
[modify] https://crrev.com/8ec8471f8b72ca54af9d923d1af48a041c115f1a/webrtc/modules/video_coding/codecs/vp9/vp9_impl.h
[modify] https://crrev.com/8ec8471f8b72ca54af9d923d1af48a041c115f1a/webrtc/video/end_to_end_tests.cc
[modify] https://crrev.com/8ec8471f8b72ca54af9d923d1af48a041c115f1a/webrtc/video/receive_statistics_proxy.cc
[modify] https://crrev.com/8ec8471f8b72ca54af9d923d1af48a041c115f1a/webrtc/video/receive_statistics_proxy.h
[modify] https://crrev.com/8ec8471f8b72ca54af9d923d1af48a041c115f1a/webrtc/video/video_receive_stream.cc

Per Comment #11, this is already merged to M51. So removing "Merge-Approved-51" label. Thank you.

Verified in M51 51.0.2704.26 in Windows
For a 2 way apprtc/hangout call, WebRTC.Video.OnewayDelayInMs hovers around 85-102 ms