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.