Closed Bug 1301286 Opened 3 years ago Closed 3 years ago

Intermittent dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html | Error in test execution: Error: Timed out waiting for frames timeout/<@...

Categories

(Core :: WebRTC, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox52 --- fixed
firefox-esr52 --- fixed
firefox53 --- fixed
firefox54 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: jesup)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell fixed])

Attachments

(1 file)

Rank: 35
Priority: -- → P3
Paul, although this bug has been open for a long time, I notice the frequency of failures increased around the time you made changes to the test in bug 1328142. Would you mind having a look at the failures / see if you can make this test more reliable?
Flags: needinfo?(paulrkerr)
Paul has left Mozilla (though he may still comment); I landed those patches.
Flags: needinfo?(paulrkerr) → needinfo?(rjesup)
:rjesup, we have gone a few weeks with no traction on this bug, just yesterday alone we had 65 failures (primarily on Linux)- Can we get someone to look at this bug this week?  I would imagine this is easy to reproduce given the frequency of this, especially since Feb 10th.
I'm actively working on this; the 65 failures were due to two patches colliding.  I landed two fixes on 2/13 that should (I hope) greatly reduce the frequency of problems here
Flags: needinfo?(rjesup)
Note that drno landed a patch to greatly improve the underlying code; not sure if that will help or hurt the random failures here.
apparently 100Kbps isn't enough to ensure green tests...
Attachment #8838153 - Flags: review?(adam)
Assignee: nobody → rjesup
Status: NEW → ASSIGNED
Comment on attachment 8838153 [details] [diff] [review]
At least in the webrtc49 update, 100Kbps isn't enough for simulcast tests

Review of attachment 8838153 [details] [diff] [review]:
-----------------------------------------------------------------

r+ with a suggestion to add a comment.

::: dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html
@@ +25,5 @@
>    }
>  
>    runNetworkTest(() =>
>      pushPrefs(['media.peerconnection.simulcast', true],
> +              ['media.peerconnection.video.min_bitrate_estimate', 180*1000]).then(() => {

Ideally, add a comment here indicating that 180kpbs is an emperically-derived value that is much higher than the theoretically-required 80kpbs. I'd like some sort of breadcumb in case whatever is causing that mystery ever gets driven to ground. It also provides a bit of a "if you need to fudge this futher, that's okay, since the number was kind of made up in the first place" hint.
Attachment #8838153 - Flags: review?(adam) → review+
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e118331fa1ff
At least in the webrtc49 update, 100Kbps isn't enough for simulcast tests r=abr
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/d1e16f0f601c
accidental qref pulled in some half-writtne debug code rs=bustage
(In reply to Pulsebot from comment #23)
> Pushed by rjesup@wgate.com:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/d1e16f0f601c
> accidental qref pulled in some half-writtne debug code rs=bustage

This did not back out the unreviewed logging change in rtcp_sender.cc -- please back that out also.
Flags: needinfo?(rjesup)
Pushed by rjesup@wgate.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c1130ac2f33b
backout accidental logging change rs=backout
Flags: needinfo?(rjesup)
https://hg.mozilla.org/mozilla-central/rev/e118331fa1ff
https://hg.mozilla.org/mozilla-central/rev/d1e16f0f601c
https://hg.mozilla.org/mozilla-central/rev/c1130ac2f33b
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Whiteboard: [stockwell fixed]
You need to log in before you can comment on or make changes to this bug.