getStats should provide outbound-rtp stats immediately on completion of offer/answer
Categories
(Core :: WebRTC: Signaling, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox154 | --- | fixed |
People
(Reporter: bwc, Assigned: ng)
References
(Blocks 1 open bug)
Details
(Keywords: webcompat:platform-bug)
User Story
user-impact-score:1000
Attachments
(2 files)
webrtc-pc says: "If selector is an RTCRtpSender, gather stats for and add the following objects to result: All RTCOutboundRtpStreamStats objects representing RTP streams being sent by selector. "
webrtc-stats says: "The RTCOutboundRtpStreamStats is created when the RTP sender is configured by setting a local or remote SDP answer (via setLocalDescription() or setRemoteDescription() and the signaling state returning to "stable")."
These seem to contradict one another; I think the "being sent by" ought to change to something else, perhaps "associated with". The language in webrtc-stats is very clear, while the language in webrtc-pc is not. Plus, it seems that wpt expects the language in webrtc-stats to hold.
| Reporter | ||
Comment 1•10 months ago
|
||
| Reporter | ||
Comment 2•7 months ago
|
||
| Reporter | ||
Updated•7 months ago
|
Updated•4 months ago
|
Updated•4 months ago
|
| Reporter | ||
Comment 3•3 months ago
|
||
Alright, there is language elsewhere in webrtc-stats that clarifies this:
The RTCOutboundRtpStreamStats is created when the RTP sender is configured by setting a local or remote SDP answer (via setLocalDescription() or setRemoteDescription() and the signaling state returning to "stable").
https://w3c.github.io/webrtc-stats/#the-rtp-statistics-hierarchy
Would be really nice if that were reflected in the language for the stats fields themselves, but at least we have clarity on what to do.
| Assignee | ||
Comment 4•3 months ago
|
||
Comment 6•3 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/dd1650261561
https://hg.mozilla.org/mozilla-central/rev/12a487ab6379
Comment 8•3 months ago
|
||
Backed out for causing wpt failures at RTCRtpReceiver-video-anyCodec.html
Backout Link
Push with failures
Failure Log
Failure line TEST-UNEXPECTED-FAIL | /webrtc/RTCRtpReceiver-video-anyCodec.html | An RTCRtpReceiver is prepared to receive any negotiated codec. - assert_unreached: Timed out waiting for sent frames Reached unreachable code
| Reporter | ||
Comment 9•3 months ago
|
||
I'm not assigned to this anymore, fixing.
Updated•3 months ago
|
| Assignee | ||
Comment 10•3 months ago
|
||
The GMP plugin is being reinitialized for successive resolutions and is seemingly not always able to finish before the timeout.
This patch adds some logging and disables the test on Windows. It is already functionally disabled on Linux and Mac.
Android probably passes because we are not using OpenH264.
See Bug 1952881
Comment 11•2 months ago
|
||
Comment 12•2 months ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/95de109770b6
https://hg.mozilla.org/mozilla-central/rev/a03eb14f5d89
https://hg.mozilla.org/mozilla-central/rev/b047b4230c31
Updated•2 months ago
|
| Assignee | ||
Updated•2 months ago
|
Description
•