Tweak "inbound-rtp" creation time

[henbos]

The spec says "The RTCInboundRtpStreamStats is created when the first RTP packet for this SSRC is received".

• In potential use cases, such as the proposed Encoded Source, frames don't necessarily come from the network but we would still want "inbound-rtp" stats objects to show up since it contains valuable decode and playout related metrics.

Proposal: tweak spec to say "packets received or frames decoded"

[henbos]

Chrome fixed its inbound-rtp stats lifetime in M141 but had to implement this tweak to avoid rollback due to breaking Insertable Streams use case

[jan-ivar]

... we would still want "inbound-rtp" stats objects to show up since it contains valuable decode and playout related metrics.

That seems unfortunate. Can you detail the decode and playout-related metrics affected? Also can elaborate on where the frames come from?

[youennf]

• frames don't necessarily come from the network but we would still want "inbound-rtp" stats objects to show up since it contains valuable decode and playout related metrics

This is one difference between encoded transform, which does not allow to decode frames until receiving packets and insertable streams which allow to do so.

I would tend to wait for new proposals like encoded sink to decide whether we want to do this change. It seems strange to expose inbound-rtp stats while there is no rtp at all.

Maybe these new proposals would call for another kind of stat, or maybe no stat will be needed (web app fully controls what goes into the sink and has MediaStreamTrack stats + rvfc on the output side).

[henbos]

I'm not opposed to waiting for clarity since this depends on a feature that has not been standardized yet (Encoded Source), but I can say that I would be very much opposed to splitting up the "inbound-rtp" into multiple different stats objects. The inbound-rtp is tied to an RTCRtpReceiver and contains metrics for RTP, decode and arguably its "track". This is a dictionary, so if the RTP metrics arn't applicable, they can simply be missing from the dictionary. The stats type having "rtp" in the name is not such a big evil that we should revisit the entire stats model.

[henbos]

Looking at inbound-rtp it's about 50/50 what is RTP stats and what is decode stats.

[jan-ivar]

I like the idea of waiting as well, so we have something concrete to describe.

I see a number of ways to address this without breaking existing stats. Access is by keyword, not dictionary. Like a mutually-exclusive "inbound-encoded" key that has (mostly) the same dictionary members. Websites using encoded source would know to look for it, or duck type for code reuse.

[henbos]

Websites that use encoded source would be the same websites that arn't using encoded source. Different use cases and features, but same stats pipeline. Introducing new stats types has backwards compatibility problems without any tangible benefit.

"inbound-rtp" being a shared object for both RTP and decode stats is not a new problem, or a problem that is only exposed now - you can go back 10 or how ever many years and look at the original "inbound-rtp" stats object and you would see that it has always been a mix of RTP and decode stats. Hindsight is 20/20 but if this was a problem we should have fixed it 10 years ago, not now.

"inbound-rtp" defines both audio-only and video-only metrics, but that's not a problem, we just don't set any values for the metrics that are N/A. Same thing here; if RTP stats are N/A, we don't set them.

The "only" new problem here (except obsessing over the type name) is inbound-rtp.ssrc being a required attribute. I don't know if Encoded Source intents to let you specify SSRC, but if you don't, then this attribute would no longer be required.