Also chrome://media-internals/ shows this (attached "bug.png").
On latest stable version when muted video wasn't delayed it looked like this (attached "ok.png").

Deleted: bug.png 60.0 KB

	bug.png 60.0 KB View Download

Deleted: ok.png 76.9 KB

	ok.png 76.9 KB View Download

Since no audio is being played and the tab is in the background it's given a low priority; which on your system seems to be insufficient for maintaining the live edge. In this case we'll pause and buffer as necessary to try and keep our audio buffer filled. Over time this leads to falling further and further behind the live edge.

I feel this is working as intended / a minor issue, but resolving issue 764133 in a way that keeps a clock running instead of pausing for no selected tracks would make the experience here better. +mlamouri, johnpallett since this has some UX implications.

(Thanks for the great bug report with media-internals included!)

Thanks for your reply.

But when I watch live stream I suppose video is always in actual state without any delay when I didn't pause it myself. So when I switching back to it I want to see it in the same actual state as other people (and chat) see it.

It was working as intended in latest stable version, skipping video track and lowering CPU usage because of that. And it was working fine.

But in current beta/canary Chrome is pausing muted live stream so watching several live streams in different tabs is nearly impossible.
I hope it will be fixed before next stable release.

The log you provide don't indicate that there's any real pausing; only pausing for when the audio decoder runs out of buffers. This is something that can happen even if you had the tab in the foreground and the machine becomes overloaded or the page does something too expensive on the main thread.

Are you seeing any cases where the stream is completely paused and requires you to play it again when you return?

I tested both versions and both have kind of similar CPU load when twitch live stream is playing in the background.

Also the live stream is delayed exactly for the time the tab was inactive minus ~5 sec. So when tab was inactive for 1 min, twitch live stream was delayed for ~55 sec. And if tab was inactive for 2 mins, live video was behind for ~115 sec.

So seems like it's not because some random CPU overloads are causing this pauses, live video is just paused totally in background muted tab in latest beta/canary.

Youtube live streams behave the same, but it's not so frustrating there because at least youtube have "live" indicator with ability to seek forward to the actual time.

Hmm, something weird is happening there. There is repeated play/pause without any buffering events in between... Will see where those events are coming from.

Twitch seems to have a bunch of issues with muted background streams. Because there's no active audio it does not get enough CPU time to run effectively; we thus underflow the audio renderer and by the time we are about to come out of it Twitch invokes a seek to try and catch back up to the live head.

I'm not sure how to reconcile this behavior with your report evolgr@, every time my playback falls behind the live head Twitch starts issuing seeks to catch back up. Are you using any extensions which might effect this?

Actually I just noticed that you said this is occurring on canary and not stable; which has all the code I've been investigating. Do you see this on Chrome Beta (63)? Can you paste the contents of the variations field in chrome://version/ ?

Finally you have read my report :)


I had beta version which was using user data from regular Chrome. I removed it yesterday and installed regular Chrome as it was impossible to watch live streams in that beta.

Now after I installed current beta I see it's using separate user data storage and seems like I got other variations in it. That's good, it will be easier to test stable/beta versions now (without reinstalling).


In current beta original bug happens not so often, but still after few tries I can reproduce it.
Also in current beta live stream sometimes is not resumed at all (another bug).

So at the moment I have beta and canary versions which have this bug, but it happens more often in canary.


My current beta version with original bug and not-resuming-at-all-bug:

Google Chrome	63.0.3239.18 (Official Build) beta (64-bit) (cohort: Beta)
Revision	975787a36cf8dbe16eaf42134aaee20fe9504ba2-refs/branch-heads/3239@{#188}
OS	Windows
JavaScript	V8 6.3.292.15
Flash	24.0.0.189 internal-not-yet-present
User Agent	Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.18 Safari/537.36
Command Line	"C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Executable Path	C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe
Profile Path	C:\Users\Administrator\AppData\Local\Google\Chrome Beta\User Data\Default
Variations	c134752e-b8b72c88
1e528f0f-f23d1dea
38eb801c-3f4a17df
7c1bc906-f55a7974
47e5d3db-3d47f4f4
1210a805-ecd831c
776de70c-e0278d3d
79616653-f23d1dea
9e201a2b-38d7ffb9
b21cf1cf-803f8fc4
68812885-4d2fac87
5e3a236d-59e286d0
f347910c-3d47f4f4
9773d3bd-f23d1dea
99144bc3-dc4a3f77
9e5c75f1-1ece8db1
f79cb77b-3f4a17df
d92562a9-ca7d8d80
447469ba-13d9f35f
7aa46da5-c946b150
25fc488a-3f4a17df
1bced4a3-d61b43f8
ad6d27cc-15e2aa9a
b2f0086-93053e47
ef25c1eb-f23d1dea
4bc337ce-77afc4fd
1354da85-f34af386
3ac60855-486e2a9c
f296190c-45641d72
4442aae2-6e597ede
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-bca011b3
e7e71889-e1cc0f14
94e68624-803f8fc4
f141d4bc-f23d1dea
da4aaa01-3f4a17df
Compiler	MSVC 2017 (PGO)



My canary version with original bug only:

Google Chrome	64.0.3254.1 (Official Build) canary SyzyASan (32-bit) (cohort: ASAN)
Revision	547684c177a5db734e35d3a6e258b1e51da7fbdf-refs/branch-heads/3254@{#1}
OS	Windows
JavaScript	V8 6.4.168
Flash	24.0.0.189 internal-not-yet-present
User Agent	Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3254.1 Safari/537.36
Command Line	"C:\Users\Administrator\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Executable Path	C:\Users\Administrator\AppData\Local\Google\Chrome SxS\Application\chrome.exe
Profile Path	C:\Users\Administrator\AppData\Local\Google\Chrome SxS\User Data\Default
Variations	c134752e-f23d1dea
da89714-5e283afd
1e528f0f-3b7f37f3
b130ecb8-1410f10
6025934e-3f4a17df
7c1bc906-b5809d46
47e5d3db-3d47f4f4
1210a805-ecd831c
41e765a5-3f4a17df
776de70c-e0278d3d
34d450b1-f23d1dea
79616653-3f4a17df
19c1fdaf-3d47f4f4
f9884634-a3b30566
3042ad4b-ca7d8d80
9e201a2b-38d7ffb9
591576c8-ace4e138
44c96c7b-92bf7ff7
57f575bb-f23d1dea
2e5ffa4b-3f4a17df
e4e9ce8f-3f4a17df
b72f69e9-3f4a17df
4b61504a-a8ff754b
5485fc4d-ca7d8d80
9773d3bd-7c7ea110
8fa604e0-dac4d430
99144bc3-c3f822de
9e5c75f1-77b2f434
f79cb77b-3f4a17df
47edb3-566ebc9b
4ea303a6-2108e188
d92562a9-ca7d8d80
447469ba-13d9f35f
7aa46da5-c946b150
2b33233e-62e2c3f0
25fc488a-f23d1dea
1aecb842-f23d1dea
ad6d27cc-7075cd8
757a5d98-f23d1dea
f3ea30a0-84708353
23496387-4ea78229
796ee5fe-f23d1dea
b2f0086-3f907e47
ef25c1eb-3f4a17df
4bc337ce-77afc4fd
3ac60855-486e2a9c
f296190c-6e3b1976
4442aae2-e1cc0f14
ed1d377-e1cc0f14
75f0f0a0-d7f6b13c
e2b18481-d7f6b13c
e7e71889-e1cc0f14
f5fff3a2-3f4a17df
f141d4bc-f23d1dea
e9ce63c1-5bda69fd
9cade933-fbb4ab19
da4aaa01-3f4a17df
Compiler	MSVC 2017

Can you try with --disable-features=BackgroundVideoTrackOptimization  and then with --disable-features=BackgroundVideoPauseOptimization to see if either has any effect on M63?

To be clear the original bug is when playback resumes but it's far behind the live edge?

Right, the original bug is when playback resumes but it's far behind the live edge.


Tested next on updated beta version "63.0.3239.30 (Official Build) beta (64-bit) (cohort: Beta)":

With "--disable-features=BackgroundVideoTrackOptimization" flag result is the same: playback resumes but it's far behind the live edge.

With command line (because I can't find the flag) '"C:\Program Files (x86)\Google\Chrome Beta\Application\chrome.exe" --disable-features=BackgroundVideoPauseOptimization --flag-switches-begin --flag-switches-end' result is still the same: playback resumes but it's far behind the live edge.

With both result is still the same: playback resumes but it's far behind the live edge.



Maybe if this switches didn't make any difference this could mean it's not related to media/video/audio part but instead related to some increased background JS optimizations?

Hmm, yes this is strange. Can you try disabling hardware video decode in chrome://flags and see if that changes anything?

Tried in beta and result is still the same: playback resumes but it's far behind the live edge.

Are you using any extensions in your beta profile? I'm not able to reproduce the same behavior as you with M63 beta. I just get constant seeking to live edge in the background.

From logging locally it looks like muted streams don't get enough JS time to buffer enough audio.

[1:27:1102/135101.417747:ERROR:renderer_impl.cc(801)] OnBufferingStateChange audio BUFFERING_HAVE_NOTHING -> BUFFERING_HAVE_ENOUGH
[1:27:1102/135101.417829:ERROR:renderer_impl.cc(914)] StartPlayback
[1:27:1102/135101.417903:ERROR:audio_renderer_impl.cc(114)] StartTicking
[1:27:1102/135101.417972:ERROR:audio_renderer_impl.cc(132)] StartRendering_Locked
[1:1:1102/135101.420699:ERROR:webmediaplayer_impl.cc(1308)] OnPipelineSeeked
[1:1:1102/135101.421092:ERROR:webmediaplayer_impl.cc(1588)] OnBufferingStateChange(1) 34.6438 s
[1:1:1102/135101.421262:ERROR:webmediaplayer_impl.cc(946)] Buffered ranges #0, [0 s, 34.6987 s]
[1:30:1102/135103.812098:ERROR:audio_renderer_impl.cc(1103)] SetBufferingState_Locked : 1 -> 0
[1:27:1102/135103.812423:ERROR:renderer_impl.cc(801)] OnBufferingStateChange audio BUFFERING_HAVE_ENOUGH -> BUFFERING_HAVE_NOTHING
[1:27:1102/135103.812604:ERROR:renderer_impl.cc(879)] PausePlayback
[1:27:1102/135103.812685:ERROR:audio_renderer_impl.cc(146)] StopTicking
[1:1:1102/135103.812846:ERROR:webmediaplayer_impl.cc(1588)] OnBufferingStateChange(0) 36.9817 s
[1:1:1102/135103.812972:ERROR:webmediaplayer_impl.cc(946)] Buffered ranges #0, [0 s, 34.8317 s]

I'm still unable to reproduce the lag from the live edge, but I did figure out the never resumes issue and filed that as  issue 781010 , which I'll land a fix to M63 for.

Sometimes I can't reproduce the bug too, in this case restarting Chrome helps.

Recorded next screencast with 2nd try (on first try video resume worked just fine).
I added CPU load graph so you could see there is not 100% CPU load. Also CPU load without recording would be much less, so please ignore slightly higher values.

Deleted: bug.mp4 9.2 MB

	bug.mp4 9.2 MB View Download

Thanks for the video, that helped a lot. I didn't realize you were specifically referring to the "latency to broadcaster" bit. The root cause here seems to be us throttling background no-audio renderers so significantly in M63 that they underflow repeatedly and cause Twitch to start buffering more data to avoid the underflow.

+Scheduling folks to see if they've changed throttling for renderers in M63 from M62.

I'll forward this thread to our Twitch contacts to see if they can make some changes to their code to improve this. Triggering a pause from the pause-button on the player seems to correctly jump you back to live edge after pressing play again, but if we internally pause and then play on the page becoming visible again you still get the long delay.

I don't think there's anything we can do on our end besides throttle less, but Chrome is under a lot of pressure to not waste resources in background tabs like this. So I think we'll need Twitch to do something on their side when they detect page visible changes here.

Please note that this is not only the Twitch problem, the same happens with Youtube live streams too. I didn't test Youtube lately though.

+strobe for the YouTube side of things. See video in c#17 for the problem description on Twitch and c#6 for the description on YouTube.

If it's can't be fixed and this is the only way Chrome can go then it would be nice to have a flag to disable this unneeded hardcore throttling on desktops.

Try flipping #expensive-background-timer-throttling in chrome://flags to see if that helps.

Hmm, none of the throttling/background interventions seem to do anything to make this better, so not sure which one it is. +altimin in case he has ideas.

I don't think we made any changes to throttling between M62 and M63.

You could try using --disabled-background-timer-throttling to see if it makes anything any better.

Traces could be useful too (with renderer.scheduler and disabled-by-default-renderer.scheduler categories).

Command line option "--disabled-background-timer-throttling" didn't help.

Tried to do tracing on current beta with URL chrome://tracing/ with next steps:
1) started twitch live stream and turned on video stats
2) switched to tracing tab and started recording with options like on the attached files "tracing1.png" and "tracing2.png"
3) switched to twitch tab, muted playing video
4) switched to chrome://media-internals/ tab and waited for "suspicious" messages
5) switched back to twitch tab and noticed stats show that playback resumed but it's behind the live edge
6) switched to tracing tab and stopped recording (buffer usage was at 50%), got error like on the attached "error.png" file, seems to be the same error when you try to load saved trace
7) saved trace as "trace_trace.json.gz" with "Save" button

Please let me know if I should record trace in different way to avoid error message on trace open.

Deleted: tracing1.png 4.8 KB

	tracing1.png 4.8 KB View Download

Deleted: tracing2.png 7.3 KB

	tracing2.png 7.3 KB View Download

Deleted: error.png 14.3 KB

	error.png 14.3 KB View Download

Deleted: trace_trace.json.gz 921 KB

trace_trace.json.gz 921 KB Download

Canary, 64.0.3261.0 should fix the issues where the stream never resumes. Let me know if you can still reproduce that issue. I'll merge that back to M63 shortly. Still unable to figure out what has changed in terms of scheduling time though.

+brucedawson for the issue in c#25, not sure why tracing is complaining in EtwImporter.

I haven't actually worked on this aspect of ETW and chrome tracing. The area I worked on was Chrome emitting ETW events (to be recorded externally), and this is Chrome recording ETW events (to be recorded in a chrome trace).

My understanding, from looking at third_party\catapult\tracing\tracing\extras\importer\etw\etw_importer.html, is that the ETW events are recorded when System Tracing is enabled and when Chrome is elevated. System Tracing seems to default to being checked, but does nothing (that I can tell) when Chrome is not elevated. Or, at least, this bug is avoided. I was able to reproduce a similar failure in Chrome canary by running it elevated and recording a trace.

So, to avoid the problem one should either not run Chrome elevated (always a wise idea anyway) or uncheck System tracing, or both. I'll file a catapult bug.

https://github.com/catapult-project/catapult/issues/4028

If it helps, here is tracing without "System Tracing" checked in canary "64.0.3262.0 (Official Build) canary (64-bit) (cohort: Clang-64)".

Deleted: trace_live_video_bug.json.gz 869 KB

trace_live_video_bug.json.gz 869 KB Download

Thanks for the trace, altimin@ can you take a look? The render thread seems to be only waking up every ~2 seconds. Is that expected for a background tab these days?

evolgr@ are you able to confirm that on canary you don't see permanent pauses on Twitch anymore? I'd like to get external confirmation before I merge to M63 for  issue 781010 

Re #30: Could you also include toplevel categories into the trace — it is need to identify tasks (disabled-by-default-renderer.scheduler.debug can be useful, but it might be too verbose)?

Re #31: It looks to me that the timers are running once a second, which is expected in a background tab without audio. I need toplevel category to understand what's going on.

dalecurtis@ tried 5 times to reproduce that bug and wasn't able to do it. Seems like  issue 781010  is fixed now. Good job!

altimin@ attaching similar trace with "toplevel" and "disabled-by-default-toplevel.flow" categories added.

Deleted: trace_with_toplevel.json.gz 3.6 MB

trace_with_toplevel.json.gz 3.6 MB Download

altimin@ and previous trace + "disabled-by-default-renderer.scheduler.debug".

Also here is the link to the similar trace in stable version with no bug (if it helps): https://mega.nz/#!eZdx1KZa!4xhQUcARt_zWz5Io1vDngn06O4wjvzq1Vx4Ego8vJ84

Deleted: trace_with_toplevel+renderer.scheduler.debug.json.gz 9.6 MB

trace_with_toplevel+renderer.scheduler.debug.json.gz 9.6 MB Download

Looks like this bug is now in stable version 63.0.3239.84 (Official Build) (64-bit) (cohort: 63_win_84).

Also this bug is happening not only with manually muted video.
It also happens with normal video when it's playing in background and then audio in it got quiet enough for Chrome to think there is nothing playing in that tab anymore.

So when you see speaker icon disappeared from background tab, there is a good chance live video became paused in that tab, so you will not hear it anymore until you switch back to that tab.

Deleted: tab_speaker_icon.png 925 bytes

	tab_speaker_icon.png 925 bytes View Download

This definitely sounds like the scheduler deprioritizing more than it should. altimin@ did you ever look over the traces provided above?

Sorry, I assumed that this bug is fixed per #34. :(

--disable-background-timer-throttling not having an effect suggests that it's not scheduler throttling. If dalecurtis@ thinks that it's scheduler, could you double-check that this bug is reproducible with this flag? If it is reproducible, that means that it's not scheduler.

The page is backgrounded without audio, so timers on this page are throttled. However, there is only a handful of them and all other tasks are running without restrictions.

Running Chrome with "--disable-background-timer-throttling" fixes the issue (tested few times in Stable and Canary version).

That's interesting, thanks. So that it is a scheduling issue indeed, I'll take a closer look at traces to understand what's going wrong.

I believe that I have a working theory - AsyncMethodRunner at the moment uses default timer queue and gets throttled. I'm not 100% sure, but I'll fix it first and we'll see if it makes any difference on Canary.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0755c943610259ed719e3759428970e282dc79c9

commit 0755c943610259ed719e3759428970e282dc79c9
Author: Alexander Timin <altimin@chromium.org>
Date: Fri Dec 15 02:15:57 2017

[blink] Use per-frame task runner in AsyncMethodRunner

Posting async tasks to the default timer queue can lead to media tasks
being throttled, which may lead to videos being stopped in background.

R=haraken@chromium.org,hajimehoshi@chromium.org
BUG= 779962 , 786332

Change-Id: Ic50890f909ed824a9d8048d5ef5af590b3cd086b
Reviewed-on: https://chromium-review.googlesource.com/822931
Reviewed-by: Hajime Hoshi <hajimehoshi@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524292}
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/core/css/FontFaceSet.h
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/modules/gamepad/NavigatorGamepad.cpp
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/modules/mediarecorder/MediaRecorder.cpp
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/modules/mediastream/MediaDevices.cpp
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/modules/mediastream/MediaDevices.h
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/modules/notifications/Notification.cpp
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/platform/AsyncMethodRunner.h
[modify] https://crrev.com/0755c943610259ed719e3759428970e282dc79c9/third_party/WebKit/Source/platform/Timer.cpp

Tested in Canary "65.0.3296.0 (Official Build) canary (64-bit) (cohort: Clang-64) 7c13674631f0a3ae331faceb6df9168afacf155d-refs/heads/master@{#524554}": seems like the issue is fixed now. Thanks!

Looping M-63 release owners for confirmation if this needs to be merged back to M-63 as well.

We're not planning any further M63 releases. Pls target fix for M64 and request a merge. 

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

What's the impact of not including in M64?  Is this a confirmed regression?

Yes, this is a confirmed regression. The impact is that twitch (and maybe some other media websites) may be paused when the page is in background.

Approving merge to M64 Chrome OS.

altimin@, reminder to please merge CL to M64 branch 3282.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c0fdddca6a341d664241c1563e0f4d5c61c5dc95

commit c0fdddca6a341d664241c1563e0f4d5c61c5dc95
Author: Alexander Timin <altimin@chromium.org>
Date: Wed Jan 03 15:41:55 2018

[blink] Use per-frame task runner in AsyncMethodRunner

Posting async tasks to the default timer queue can lead to media tasks
being throttled, which may lead to videos being stopped in background.

R=hajimehoshi@chromium.org, haraken@chromium.org
TBR=altimin@chromium.org
BUG= 779962 , 786332

(cherry picked from commit f841a10836c67904024381b00419de87cb406423)

Change-Id: Ic50890f909ed824a9d8048d5ef5af590b3cd086b
Reviewed-on: https://chromium-review.googlesource.com/822931
Reviewed-by: Hajime Hoshi <hajimehoshi@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Alexander Timin <altimin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#524292}
Reviewed-on: https://chromium-review.googlesource.com/849003
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#397}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/core/css/FontFaceSet.h
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/modules/gamepad/NavigatorGamepad.cpp
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/modules/mediarecorder/MediaRecorder.cpp
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/modules/mediasource/SourceBuffer.cpp
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/modules/mediastream/MediaDevices.cpp
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/modules/mediastream/MediaDevices.h
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/modules/notifications/Notification.cpp
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/platform/AsyncMethodRunner.h
[modify] https://crrev.com/c0fdddca6a341d664241c1563e0f4d5c61c5dc95/third_party/WebKit/Source/platform/Timer.cpp

Thanks for the reminder!