Closed Bug 1821231 Opened 1 year ago Closed 1 year ago

webrtc/RTCPeerConnection-getStats.https.html fails intermittently because the first packet transmitted is RTX

Categories

(Core :: WebRTC: Audio/Video, defect)

defect

Tracking

()

RESOLVED FIXED
113 Branch
Tracking Status
firefox113 --- fixed

People

(Reporter: bwc, Assigned: bwc)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

It seems that sometimes the first RTP packet out of the sender is using the RTX ssrc. This causes an unmute event, but we don't get any outbound-rtp stats for it, because the stats query code is not looking at stats for RTX.

I need to read up on how the stats api is supposed to treat rtx independent of the stream being retransmitted.

Heads-up on this; do you know off the top of your head how this ought to be functioning?

Flags: needinfo?(na-g)

Thanks for the heads up. The RTX being treated separately makes sense, though it is new to me.

Flags: needinfo?(na-g)

I looked, and webrtc-stats says:

"RTX streams do not show up as separate RTCOutboundRtpStreamStats objects but affect the packetsSent, bytesSent, retransmittedPacketsSent and retransmittedBytesSent counters of the relevant RTCOutboundRtpStreamStats objects."

It looks like libwebrtc either does not do any of this summing-up work for us, or maybe this summing-up does not work properly when only RTX has been sent. I'll need to investigate further.

Assignee: nobody → docfaraday

Hmm. It looks like the totaling-up is only being done for audio, which is pretty weird. So we'll need to total this stuff up ourselves.

Try looks fine.

Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cda424bfe16c
Take RTX stats into account for outbound-rtp stats. r=ng
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 113 Branch
Blocks: 1822350
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: