Philipp Hancke

Now that makes sense. I assumed that the transport stats were describing what goes over the wire but they aren't actually. What goes over the wire is counted by the...

https://bugs.chromium.org/p/webrtc/issues/detail?id=11247 -- looks like it *is* a problem in implementations

the note added in #617 did also resolve this, no?

I would say there is a semantic difference: * null/undefined: there is no a=fmtp line for this codec in the sdp * "": there is a a=fmtp line but its...

also [ħere](https://w3c.github.io/webrtc-pc/#dom-rtcrtpcodecparameters-sdpfmtpline)

browsers don't receive simulcast and what they receive must look like a single RTP stream. See [here](https://groups.google.com/d/msg/discuss-webrtc/gik2VH4hUjk/xWUyA_XXAQAJ) for some of the guiding principles and/or have a :coffee: with that person

the sender might receive rtcp from the SFU which can show up as an inbound-rtp stream with remoteId set. This will have an SSRC but no rid iiuc

 As mentioned above this is visible but it makes the graph quite hard to interpret.

padding is just the legacy pre-"do it as rtx" way of probing so paddingBytesSent won't cut it because how do you identify probing on rtx then? probingBytesSent and probingPacketsSent would...

theoretically: yes practically: padding is used by webrtc.org only for probing so... no :-)