remoting_unittests failing on chromium.win/Win7 Tests (dbg)(1) |
||||||
Issue descriptionremoting_unittests failing on chromium.win/Win7 Tests (dbg)(1) Type: build-failure Builders failed on: - Win7 Tests (dbg)(1): https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%281%29 https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%281%29/builds/56854 is showing failure in remoting_unittests Webrtc_ConnectionTest.Audio_0, with stdio showing lots of """ [3632:4088:0126/183635.318:27270207:WARNING:webrtc_audio_sink_adapter.cc(63)] Unsupported number of channels: 1 """ Findit is suggesting the culprit is the WebRTC roll https://chromium.googlesource.com/chromium/src/+/968048dbdb64fde8f6ac073077399dfaf42f6bb3 mfomitchev suggested that reverting the roll is infeasible and the test should be disabled instead, which I'll do now.
,
Jan 27 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b875cd72ebc343cdd479e8cdf1fc79dcb0f833db commit b875cd72ebc343cdd479e8cdf1fc79dcb0f833db Author: suzyh <suzyh@chromium.org> Date: Fri Jan 27 04:10:48 2017 Disable ConnectionTest.Audio Webrtc_ConnectionTest.Audio_0 is timing out after the latest WebRTC roll. Disabling the test until it can be looked at. BUG= 685910 TBR=kelvinp@chromium.org Review-Url: https://codereview.chromium.org/2659823003 Cr-Commit-Position: refs/heads/master@{#446587} [modify] https://crrev.com/b875cd72ebc343cdd479e8cdf1fc79dcb0f833db/remoting/protocol/connection_unittest.cc
,
Jan 27 2017
+sergeyu who wrote the unittest that's now failing, can you take a look?
,
Jan 27 2017
Removing label to avoid this showing up in sheriff-o-matic dashboard (since it's assigned)
,
Jan 29 2017
Bisecting webrtc shows that this started happening after this change: https://codereview.webrtc.org/2516993002 Test fails only on windows in Debug mode, but on other platforms and in release builds I see the following error message now: [274784:345376:0128/162521.722:453554406:ERROR:statistics.cc(80)] SetSendCodec() invalid number of channels (error=8005) [274784:345376:0128/162521.729:453554406:WARNING:audio_send_stream.cc(303)] SetSendCodec() failed: 8005 [274784:345376:0128/162521.735:453554406:ERROR:audio_send_stream.cc(90)] Failed to set up send codec state. Karl, do you know what the root cause might be? The test runs webrtc connection with one audio stream and stereo=1 is added in SDP, so stereo is expected on the receiver side. For some reason the receiver gets mono (only windows in debug builds).
,
Jan 30 2017
Ugh. Yes, that CL is probably "at fault", in that it's likely to have triggered the behavior. When trying to land it, I found two interacting bugs: (1) we appear to lose the Opus "stereo" parameter when parsing the SDP for the receive side, which causes that part of the code to always think we're supposed to do Opus in mono; and (2) a mistake when translating AudioCodec to CodecInst that caused us to disregard any Opus "stereo" parameter and always decode Opus in stereo. (WebRTC bug 6986 ; you're already CCed.) That CL inadvertently fixed the second of those bugs, causing Opus decoding to be always-mono instead of always-stereo; I had to include an explicit emulation of the bug in that CL in order to not break Webrtc_ConnectionTest.Audio_0, and I thought I'd managed to make everything bug-compatible with the old code at that point. Obviously, I was wrong...
,
Jan 30 2017
Regarding the error messages in comment #5: Are you sure those started appearing at the same time as Webrtc_ConnectionTest.Audio_0 started failing for win-debug? Those messages talk about the send codec, and my CL should only have touched the receive side.
,
Jan 30 2017
Yeah, the error about SetSendCodec() seems to be unrelated. It's there even if I revert this change. (It's shown when the sender sets local SDP. As far as I can tell it happens because the sender gets codec config from the answer SDP and until the answer is received the sender has invalid OPUS config with channels=0).
,
Jan 30 2017
,
Feb 22 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5a5c943ccde6a22137a1b9e23a4d334a26b8633b commit 5a5c943ccde6a22137a1b9e23a4d334a26b8633b Author: kwiberg <kwiberg@chromium.org> Date: Wed Feb 22 09:54:08 2017 Actually pass the stereo=1 parameter to WebRTC for receiving audio There's currently a bug in WebRTC that causes us to always decode Opus in stereo, which explains why the missing stereo parameter didn't cause problems. But we'd like to fix that bug... BUG= webrtc:6986 , chromium:685910 Review-Url: https://codereview.chromium.org/2710483002 Cr-Commit-Position: refs/heads/master@{#451962} [modify] https://crrev.com/5a5c943ccde6a22137a1b9e23a4d334a26b8633b/remoting/protocol/connection_unittest.cc [modify] https://crrev.com/5a5c943ccde6a22137a1b9e23a4d334a26b8633b/remoting/protocol/webrtc_transport.cc
,
Feb 23 2017
Webrtc/ConnectionTest.Audio/0 has been flaky again, see bug 695384
,
Feb 23 2017
The original bug is fixed now. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by suzyh@chromium.org
, Jan 27 2017