Add stat to reflect the redundancy of FEC/RED data

[minyuel]

It would be good to add receiver stats on how much/often FEC/RED data is received but not needed (since the data they try to protect are received)

[vr000m]

I think one can calculate the overhead of the FEC by comparing the FlexFEC track with the associated media tracks. packetsRepaired: tells you how many packets were repaired due to FEC.

There are several corner cases where the packetsSent > packetsReceived + packetsRepaired and not be equal. In those cases, either the FEC structure/XOR scheme was not tailored for the expected loss pattern, example, burst loss higher than expected.

[minyuel]

Thanks for the reply! Two questions:

1. Which FlexFEC track did you refer to?
2. How about non-flex FEC, like Opus inband FEC?

[vr000m]

https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme, we are going to push out a -06 version and I believe the one implemented in chrome is -03 version.

Isn't the in-band FEC for opus with every packet (i.e., it recovers a solitary packet loss)? AFAICT, this is not controlled from the application. If we could be control it from the application, it would make a lot of sense to measure it.

[icydragons]

I would be in favor of measuring it regardless of if it can be controlled by the application since it provides an indication of the quality of the rest of the audio stream. Also, I do believe the application can turn on or off in band FEC when using opus if it is giving a worse experience.

[alvestrand]

@minyuel is on leave, expected back end of February.

[alvestrand]

This might simply be asking for a "FEC packets received" counter.

[vr000m]

For in-band FEC, would fecPacketsReceived be enough? because we already have packetsRepaired. Maybe a corresponding fecPacketsSent

[henbos]

@icydragons If this is a FEC packets sent/received we can create a PR.

[minyuel]

Hi,

Sorry for this late reply. I missed the earlier discussion until Harald brought this up again.

I would like to add a few comments.

1. In my opinion, to measure both necessity and sufficiency of FEC, we may need "Fraction of audio that is recovered from FEC" and "Fraction of FEC that is received but unused". Both of these have been implemented (but not standardized) in WebRTC: googSecondaryDecodedRate and googSecondaryDiscardedRate, respectively.

2. inband FEC of Opus is not on every packet. It is sent rather opportunistically. To quote "Packets that are determined to contain perceptually important speech information, such as onsets or transients, are encoded again at a lower bitrate and this re-encoded information is added to a subsequent packet."

3. So far, application can turn on/off FEC by SDP, but cannot control the degree of FEC, which is supposed to be adaptive to the network conditions.

[vr000m]

@minyuel Assuming we add fecPacketsSent/Received, wouldn't the counters packetsReceived, packetsLost, packetsRepaired, and fecPacketsReceived help with calculating the rates in 1?

[alvestrand]

@henbos to ping @minyuel to figure out if we've added enough stuff to close the bug.

[vr000m]

@balazskreith PTAL