1765215 - Track unmute intermittently fired before inbound-rtp stats are available

Status: NEW

(Core :: WebRTC, defect, P3)

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

+++ This bug was initially created as a clone of Bug #1765005 +++

Detected on Mon, Apr 18, 17:04:23 try of patch in bug 1765005:

TEST-UNEXPECTED-FAIL | dom/media/webrtc/tests/mochitests/test_peerConnection_audioChannels.html | Error testing that PCMU with 1000 channel(s) is ignored and produces 1 channels: TypeError: can't access property "codecId", inboundStat is undefined

I did a fiddle version and was able to repro twice in April 10 Nightly on macOS, but am no longer able to:

STRs:

• Open https://jsfiddle.net/jib1/zap5f3h2/12/

Expected results:

• No errors in web console

Actual result:

• Error testing that PCMU with 1000 channel(s) is ignored and produces 1 channels: TypeError: can't access property "codecId", inboundStat is undefined

The error happens here:

    await new Promise(r => receiver.track.onunmute = r);
    const stats = await receiver.getStats();
    const inboundStat = [...stats.values()].find(({type}) => type == "inbound-rtp");
=>  const codecStat = stats.get(inboundStat.codecId); // inboundStat is undefined

...because getStats produces stats without "inbound-rtp". This seems to be a race.

Waiting for the unmute event is supposed to be the only surefire way to ensure stats are available (in spite of compat issues in w3c/webrtc-stats#619).

Spec support:

unmute must fire in a queued task after "an RTCRtpReceiver receives data on an RTP source", and inbound-rtp is "Statistics for an inbound RTP stream that is currently received".

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Rebased bug 1765005 patch and added an assert, and in it still appears, only affecting linux here in this particular try:

TEST-UNEXPECTED-FAIL | dom/media/webrtc/tests/mochitests/test_peerConnection_audioChannels.html | has inbound-rtp stats after track unmute

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Nico, any thoughts on how this can happen? It would be good to get this fixed to support our position in w3c/webrtc-stats#619 (comment) that this is supposed to be how to call stats web compatibly.

Comment 3

[Nico Grunbaum [:ng, @chew:mozilla.org]]

This is my understanding.

This [0] is what leads to unmuting the track [1]. While later than [0] but in the same function [2] passes the packets on eventually reaching a MediaSessionConduit impl, e.g. [3].
[0] https://searchfox.org/mozilla-central/source/dom/media/webrtc/transportbridge/MediaPipeline.cpp#590
[1] https://searchfox.org/mozilla-central/source/dom/media/webrtc/jsapi/RTCRtpReceiver.cpp#805
[2] https://searchfox.org/mozilla-central/source/dom/media/webrtc/transportbridge/MediaPipeline.cpp#602
[3] https://searchfox.org/mozilla-central/source/dom/media/webrtc/libwebrtcglue/VideoConduit.cpp#1498

You can try moving [2] before [0].