- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Feb 2025 15:10:57 +0000
- To: public-webrtc@w3.org
henbos has just created a new issue for https://github.com/w3c/webrtc-stats: == RTCOutboundRtpStreamStats should be created "early" == > The lifetime of all RTP [monitored object](https://w3c.github.io/webrtc-stats/#dfn-monitored-object)s starts when the [RTP stream](https://w3c.github.io/webrtc-stats/#dfn-rtp-stream) is first used: When the first RTP packet is sent or received on the [SSRC](https://w3c.github.io/webrtc-stats/#dfn-ssrc) it represents, or when the first RTCP packet is sent or received that refers to the [SSRC](https://w3c.github.io/webrtc-stats/#dfn-ssrc) of the [RTP stream](https://w3c.github.io/webrtc-stats/#dfn-rtp-stream). I assume SSRCs are NOT signalled in the SDP in this post, even though they typically are with existing implementaitons. While inbound-rtps don't have a known SSRC until the first packet is received, this is NOT true for outbound-rtps where the SSRC is picked by the WebRTC engine as soon as the RTCRtpSender has been "configured" which happens by doing O/A. LibWebRTC already does what I think makes sense: If 3 encodings are configured, we get 3 outbound-rtps and the SSRCs are known whether or not a packet has been sent yet. If we implement the spec literally, a simulcast stream would look like a singlecast stream during ramp-up when only the first encoding has started sending yet. Existing web apps wants to know the SSRCs of all RTP streams whether or not they have ramped up yet, or even if they're not going to because the RTCRtpSender's track is null ("mute" use case). I think this is one of those "easier to align spec with impl than to align impl with spec". Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/797 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 February 2025 15:10:58 UTC