a lot of [INFO:CONSOLE(23)] "Still waiting for the fake audio signal.", source: http://127.0.0.1:38697/media/webrtc_test_audio.js (23)

Issue 754714 has been merged into this issue.

nothing suspicious on WebRTC blame list.
chrome revision range is 8c8ab3db65a753303b542df2e1db2abe5b4c1ef9 (build 24154) .. eb35bbd49aacbaaa015c9cc63d9c6ae16a26d64c (build 24156)

The only media-related changes I see in Chromium range:

[1]https://chromium-review.googlesource.com/c/601057
Plumb output color space to video decoder

[2]https://chromium-review.googlesource.com/c/602596
Defer AOC::OnError() to avoid spurious device change errors.

[3]https://chromium-review.googlesource.com/c/611002
[media] Enable ChunkDemuxer to signal OnProgress events.


[3] is suspicious, but Issue 754043 it's associate with has some complicated history, and it's already been merged to M61.

sandersd@ could you PTAL?

Some WebRtcBrowserTest.* also got flaky, for example:

WebRtcBrowserTest.NegotiateOfferWithBLine
https://uberchromegw.corp.google.com/i/chromium.webrtc.fyi/builders/Android%20Tests%20%28dbg%29%20%28L%20Nexus9%29/builds/24318

WebRtcBrowserTest.NoCrashWhenConnectChromiumSinkToRemoteTrack
https://uberchromegw.corp.google.com/i/chromium.webrtc.fyi/builders/Android%20Tests%20%28dbg%29%20%28L%20Nexus9%29/builds/24317


with messages like "Still waiting for video to satisfy function isVideoPlaying"
(https://uberchromegw.corp.google.com/i/chromium.webrtc.fyi/builders/Android%20Tests%20%28dbg%29%20%28L%20Nexus9%29/builds/24318/steps/content_browsertests/logs/stdio)


So I'm not sure if conclusion on Issue 754714 is correct.

Shouldn't be (3) since the WebRtc tests don't generally use WMPI, but WMP_MS and additionally don't use Media Source Extensions which that patch affects.

Also given that there are at least 4 good builds among the bad  I think the starting revision should be pulled back to 1ac8f7d910cbf05080a406d51be987affd8b4870 24150 to be sure.

I'm looking at chromium range https://chromium.googlesource.com/chromium/src/+log/9a7e43c26d697a994c50c82fa5dfb81c24f44351..eb35bbd49aacbaaa015c9cc63d9c6ae16a26d64c?pretty=fuller
(this is starting 24149)

And have no good candidates to blame.

Is it possible to run the bot on an earlier green revision? If the tests pass reliably on earlier revisions, it would rule out hardware issues.

sakal@ could you PTAL?

kjellander@ can we do an experiment like #9? Can we also run the tests on another bot? This Nexus 9 seems to be the only device running them.

These bots are running with Chromium src always at HEAD and src/third_party/webrtc at the revision that the poller polled at https://chromium.googlesource.com/external/webrtc/trunk/webrtc

You could probably force a build passing a revision from https://chromium.googlesource.com/external/webrtc/trunk/webrtc in the text box by the Force button at https://uberchromegw.corp.google.com/i/chromium.webrtc.fyi/builders/Android%20Builder%20ARM64%20%28dbg%29 and it should build Chromium src at current HEAD with src/third_party/webrtc at the revision you pass.
I'm not sure what that will provide though.

Regarding the test - the Nexus 9 is running the same test as the other Android testers in this waterfall: out/Debug/bin/run_content_browsertests --gtest_filter=WebRtc*

[Re-triage] Since this is a P1 regression, it should be assigned to someone. Back to olka@ who was the owner before sakal@. Maybe it could be a P2 though since it's Android?

To me it looks like this fixed now?

The bot is all green now.