All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=693509

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDguL-w8wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDguPvmswsM


Bot(s) for this bug's original alert(s):

chromium-webrtc-rel-win10

I think this is due to the chromium roll: https://chromium.googlesource.com/external/webrtc/trunk/webrtc/+/0e4be2ad068a797d06432fce5d0809dced7ee7a5

If you look at the FYI bot you can see that the regression occurs without a change in WebRTC: https://chromeperf.appspot.com/report?sid=f4f5c98181b8a8b3cd880522e74e49453cfedacfba5dd94cd69d48004d18562f&start_rev=448187&end_rev=451276

Also, it looks like it only affect win bots.

Hmm, I'm confused here and I this is all I can help out with:

Regressions in Chrome tests cannot be cause by rolls of chromium_revision in WebRTC's DEPS - that only pulls in updated build toolchain and dependencies for standalone WebRTC builds.

AFAICS It must have been something in the WebRTC roll in https://chromium.googlesource.com/chromium/src/+/9508e457da7231dd37343e999b81a4260243a4a2. 
But what contradicts that theory is that we don't see any such change in the FYI bots in that interval. The regression that can be seen in the graph you pointed at points at https://chromium.googlesource.com/external/webrtc/trunk/webrtc/+/c78eb98bfddb7a54352a56cd039558d75fca7ee0 which also cannot affect a Chromium test.

When adding the other FYI bot (we don't have Win8 coverage in that waterfall): 
https://chromeperf.appspot.com/report?sid=0e60bee7a681637c6bfe10dbe90b97f01dc5f245a7b21086dca480ff9a18cce2&start_rev=448187&end_rev=451276
I see there's another:  bug 691562  showing very similar behavior, but started at a much earlier revision. That has a blamelist like this https://chromium.googlesource.com/external/webrtc/trunk/webrtc/+log/c13cf2a46ad25760be2807d74a77f1b4a58c5cde..dfb4f09c4c3b2c30bcc09eaf5a4c18b768af76ed
Are you able to explain how this works? It seems it's impossible to draw any useful conclusions out of this.

It's odd it only affects Windows and H264 as well. Could it be related to the work on getting hardware acceleration working for that platform? Adding emircan@ in case he knows something. 

This seems to affect Mac H264 as well, see below. There hasn't been any changes re Win HW in that range. Also, note that there isn't any real CrOS HW in bots AFAIK, so these platforms are the ones that would show HW codec regressions. 
https://chromeperf.appspot.com/report?sid=c4e9b53cd239178c9621bfc139927e6631d504b5aec663dab43c2fd6c984f0a0&start_rev=450554&end_rev=451833

I don't understand why you are focusing on that webrtc roll in #2, because it is not in the range that graph suggests: https://chromium.googlesource.com/chromium/src/+log/55b05b671a67d43fa952494f7254fafa1b17bdaa%5E..11706d336c17042bfaa75d017a124b85647d4c11?pretty=fuller. Am I missing something there?

It looks like my CL below can be the culprit for it. It is addressing a real bug regarding av sync issue. 
https://chromium.googlesource.com/chromium/src/+/1dd4ccf354c3286647e35ed6e02c36de695901fc

I am cc'ing holmer@, nisse@ and pbos@ in case they can explain the side effects of this. As I pointed on https://codereview.chromium.org/2692853009#msg4, capture_time_ms is used in rtp_header. Would modifying the value cause this regression in stats? Is it Ok or should I revert and look for an alternative solution?

It's logical that your change adds some noise to any values depending on the capture_time_ms_, and that would include the receiver's mapping of rtp time to ntp time. Not sure how goog_target_delay_ms and goog_current_delay_ms are derived, but it's not unreasonable that they are increased in order to accommodate the additional noise.

So I think this works as intended. Then I can see a few different approaches to improve accuracy, but perhaps that can be postponed. 40 ms increased delay for users shouldn't be a big problem.

I agree with nisse's conclusion. That the workaround on Mac affects Windows users is unfortunate... I think we should continue working on this and find a real solution to the problem (although the workaround is probably ok for M57).

Removing R-V-G label (was set upon bug filing because the bot was incorrectly configured as internal)

Marking this as WontFix based on #6 and #7.