Are "codec" stats per transceiver or per transport?

[jan-ivar]

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

"codec" "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: "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 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

[Pehrsons]

Another corner case is when an fmtp line differs in the local and remote sdps, so the encoder and decoder would be configured differently. If this difference in sdpFmtpLine should be surfaced through stats, the codec stats in this case end up being per rtp-stream rather than per transceiver. Related to #616.

Should codec stats be coalesced up to transport-level while all parameters match? That's certainly an option that avoids lots of waste in most cases.

[alvestrand]

460 codec entries sounds like a bug to me.
The intent when writing the "codec" stats was that one would be able to know the precise configuration for each payload type; the way RTP works, there can't be two different codec configurations for the same payload type on the same transport in the same direction, so it only makes sense to have max 1 codec entry for each PT.

[jan-ivar]

so it only makes sense to have max 1 codec entry for each PT.

...per direction in some cases, but yes this makes sense to me.

[henbos]

460??? Yeahhhh, I'd say that's a bug

[vr000m]

In callstats.js, we just filtered out the duplicates, hence, coalescing does make sense.

[fippo]

Given the recent motion to reduce codec stats greatly can we revisit this one? With @henbos latest proposal to only produce codecs that are in use this brings down the number from 4 to 2 but deduping seems more effort than these two objects are worth

[henbos]

You're referring to the "per direction" note specifically, can you file a separate issue for that? The issue that codecs are per-transport and not per-transceiver still holds.

[fippo]

I am refering to the coalescing note that was added in #617 which is what completed this issue. But yes, specifically the second part of the note

[alvestrand]

sadly, the PT can refer to different configs in the two directions of a transport.
I think it makes sense to think of the fmtp as "this is what I have promised to handle if you send it to me" - thus, the two ends can give different promises, but making two different promises at the same end (such as would happen if fmtp differed between two PT descriptions in the same bundle) makes absolutely no sense to me.