[webrtc-stats] Are "codec" stats per transceiver or per transport? (#614)

jan-ivar has just created a new issue for https://github.com/w3c/webrtc-stats:

== Are "codec" stats per transceiver or per transport? ==
TL;DR: The spec states codec stats are per transport, not per m-line, which doesn't match Chrome. But whaddabout sdpFmtpLine?

["codec"](https://w3c.github.io/webrtc-stats/#dom-rtccodecstats) _"is created when a codec type is registered for an **RTP transport**. It may be **referenced by multiple RTP streams in media sections** using that transport, but similar codecs in different transports have different RTCCodecStats objects."_

While _"RTP transport"_ isn't clearly defined, there's a `transportId` member, so I'd assume this refers to that `"transport"` which [says](https://w3c.github.io/webrtc-stats/#dom-rtccodecstats-transportid): _"The unique identifier of the transport on which this codec is being used, which can be used to look up the corresponding RTCTransportStats object."_

From [testing](https://jsfiddle.net/jib1/5v4qdr79/) I see Chrome creating a full set of `"codec"` entries (46) for _each_ transceiver (10 transceivers = 460 "codec" entries), even though there's only 1 `"transport"` (because BUNDLE). I read the spec as sayng that 10 transceivers should produce 46 "codec" instances (in Chrome), not 460.

But I'm not sure what this means for the sdpFmtpLine, since I believe `a=fmtp` may vary per m-line (but how often does it)?

One one hand this looks like a spec bug. On the other, returning 460+ JS objects seems like a waste and potential scaling issue.

cc @docfaraday @pehrsons

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/614 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 20 January 2022 03:06:49 UTC