webrtc-stats
webrtc-stats copied to clipboard
Clarify FlexFEC stats
"outbound-rtp" is now said to cover both RTP and RTX stats. This makes sense because RTP and RTX streams map 1:1 so there is no ambiguity there.
In the implementation code, there is a third possible stream: FlexFEC. I don't believe this has a 1:1 relationship with a single RTP media stream. Which byte and packet counters should these be added to?
I just realized that there are fecPacketsSent, but there aren't any fecBytesSent.
Each packet should be associated with a single "outbound-rtp", so I think this is well defined.
Questions for the meeting. Which do we care about?
- fecBytesSent/fecBytesReceived: Without them we can't tell the overhead of FEC on bytesSent.
- fecHeaderBytesSent/fecHeaderBytesReceived: Without them + fecBytes we can't tell the overhead of FEC on the total traffic on the transport.
We can't tell how much of the payload (bytesSent) is due to FEC (only due to RTX). The (bytesSent - retransmittedBytesSent) may be used to infer how much bytes were actually encoded, but this estimate would today also include FEC. Alternatively:
- totalEncodedBytes?
What also affect headerBytesSent but can't be distinguished in the metrics today:
- retransmittedHeaderBytesSent: Without it we can't tell the overhead due to retransmissions.
Action item on me to file an issue and PR for all the above suggested counters
According to FlexFEC it should get its own SSRC.
The mapping of FEC to source streams would make sense if it is explicitly mapped in the SDP. Otherwise the FEC mechanism (using in-band mapping) is quite flexible to dynamically change the set of source SSRCs. So the set might contain all the SSRCs but not all were used, which can be misleading.
Solved by #762