PSA: RTCMediaStreamTrackStats (a.k.a. "track") is becoming deprecated

[Henrik Boström]

In the modern getStats() API, the RTCMediaStreamTrackStats (type == "track") dictionary was made obsolete in the spec due to not working as intended in the case of simulcast, where one RTCRtpSender has several RTP streams (e.g. resolution and frame rate having several values, one for each layer, but there just being one "track").

• The "track" metrics are already available in RTCOutboundRtpStreamStats (type == "outbound-rtp"), which in the case of singlecast is approximately the same as "track" and in the case of simulcast exposes one set of metrics per simulcast layer (as several "outbound-rtp" stats objects).
• In the inbound case, there is only ever one layer, and the "track" metrics already exists in RTCInboundRtpStreamStats (type == "inbound-rtp").
• Note that the trackIdentifier is located in "media-source.trackIdentifier" which is accessed via "outbound-rtp.mediaSourceId" in the outbound case, and in "inbound-rtp.trackIdentifier" in the inbound case.

To signify that the "track" stats dictionary is becoming deprecated, the RTCStats id of RTCMediaStreamTrackStats is getting prefixed with "DEPRECATED_".

For now, the "track" metrics will still be available in getStats(). But in some future milestone (TBD) the "track" stats will be removed.

[Philipp Hancke]

Am Mo., 25. Juli 2022 um 11:01 Uhr schrieb Henrik Boström <hb...@webrtc.org>:

In the modern getStats() API, the RTCMediaStreamTrackStats (type == "track") dictionary was made obsolete in the spec due to not working as intended in the case of simulcast, where one RTCRtpSender has several RTP streams (e.g. resolution and frame rate having several values, one for each layer, but there just being one "track").

• The "track" metrics are already available in RTCOutboundRtpStreamStats (type == "outbound-rtp"), which in the case of singlecast is approximately the same as "track" and in the case of simulcast exposes one set of metrics per simulcast layer (as several "outbound-rtp" stats objects).
• In the inbound case, there is only ever one layer, and the "track" metrics already exists in RTCInboundRtpStreamStats (type == "inbound-rtp").
• Note that the trackIdentifier is located in "media-source.trackIdentifier" which is accessed via "outbound-rtp.mediaSourceId" in the outbound case, and in "inbound-rtp.trackIdentifier" in the inbound case.

To signify that the "track" stats dictionary is becoming deprecated, the RTCStats id of RTCMediaStreamTrackStats is getting prefixed with "DEPRECATED_".

This means that if you, instead of using the stats.type == 'track'  match the stats.id of the stats using .startsWith('RTCMediaStreamTrack_') this will break?

https://chromiumdash.appspot.com/commit/a5cc0accfb2125590bc5ba2c36ae7786d456a4bc

should land in M106.

For now, the "track" metrics will still be available in getStats(). But in some future milestone (TBD) the "track" stats will be removed.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/22de47b4-cd71-48d1-a29f-319c62813052n%40googlegroups.com.

[Henrik Boström]

Yes, if you have hardcoded assumptions about track stats IDs your app will break. Note that stats IDs is not something you should rely on anyway since the way the stats IDs are generated is not standardized, not cross-browser compatible (e.g. Firefox does it differently) and we have an outstanding bug to make stats IDs unpredictable.

If you have any hardcoded assumptions about what the stats IDs are, please infer the stats object from its properties rather than its ID. For example, instead of .startsWith('RTCMediaStreamTrack_') you should do .type == 'track' and look at trackIdentifier.

In the type == 'outbound-rtp' case see above post for where the trackIdentifier is located, and in M105+ you can also look at outbound-rtp.mid to match it with the RTCRtpTransceiver.mid.