Closed Bug 2000975 Opened 10 months ago Closed 2 months ago

getStats should provide outbound-rtp stats immediately on completion of offer/answer

Categories

(Core :: WebRTC: Signaling, defect, P2)

defect

Tracking

()

RESOLVED FIXED
154 Branch
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.

Severity: -- → S2
Priority: -- → P2
User Story: (updated)

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: nobody → docfaraday
Type: task → defect
Summary: getStats should provide outbound-rtp stats immediately on completion of offer/answer, and/or we need to fix the spec → getStats should provide outbound-rtp stats immediately on completion of offer/answer
Blocks: 2019387
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 154 Branch
Pushed by asilaghi@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/c58404904231 https://hg.mozilla.org/integration/autoland/rev/4feaec19fca1 Revert "Bug 2000975,Bug 2019387: apply code formatting via Lando" for causing wpt failures at RTCRtpReceiver-video-anyCodec.html

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

Status: RESOLVED → REOPENED
Flags: needinfo?(docfaraday)
Resolution: FIXED → ---
Target Milestone: 154 Branch → ---

I'm not assigned to this anymore, fixing.

Assignee: docfaraday → ngrunbaum
Flags: needinfo?(docfaraday) → needinfo?(ngrunbaum)

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

Status: REOPENED → RESOLVED
Closed: 3 months ago → 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 154 Branch
QA Whiteboard: [qa-triage-done-c155/b154]
Flags: needinfo?(ngrunbaum)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: