Closed juberti closed 6 years ago
I don't feel strongly about any of this but I wonder what it would even mean to make it not MTI? As far as I can tell the Opus RFC requires FEC to be implemented so not sure you can do Opus without doing FEC.
Well, you could simply discard the FEC data and not use it (and still be in compliance with the Opus RFC).
The question here is twofold: 1) Should we continue to mandate that WebRTC implementations must use received FEC data?
For Opus, a receiver MUST indicate that it is prepared to use incoming FEC data with the "useinbandfec=1" parameter, as specified in [RFC7587].
2) Should we continue to recommend that WebRTC implementations transmit Opus FEC to combat packet loss?
When using the Opus codec, use of the built-in Opus FEC mechanism is RECOMMENDED. This provides reasonable protection of the audio stream against individual losses, with minimal overhead. Note that as indicated above the built-in Opus FEC only provides single-frame redundancy; if multi-packet protection is needed, the aforementioned [RFC2198] redundancy with reduced-bitrate Opus encodings SHOULD be used instead.
@aboba seems to be mostly arguing against 2):
[BA] While loss of a single packet is by far the most likely loss mode, our tests do not indicate that there is much benefit from Opus internal FEC. For example, when we compared Opus internal FEC against no FEC and concealment, we found little discernible difference in MOS score. On the other hand, we did see a benefit arising from RFC 2198 redundancy to protect against burst loss. So based on our test results, we cannot recommend use of built-in Opus FEC.
The argument for RED in Section 4.1 applies as well to Opus as to other codecs, since RED is not only efficient but can protect against burst losses, which Opus internal FEC cannot. So I'd strike "without an internal FEC" from the below paragraph:
When using variable-bitrate codecs without an internal FEC, [RFC2198] redundant encoding with lower-fidelity version(s) of the previous packet(s) is RECOMMENDED. This provides reasonable protection of the payload with only moderate bitrate increase, as the redundant encodings can be significantly smaller than the primary encoding.
Isn't that covered by the 'if multi-packet protection is needed' clause mentioned above? The RFC 2198 approach is more complicated, since it's not done automatically by Opus, so I think recommending the built-in FEC is still useful.
@aboba, any further comments here?
@aboba - we were just discussing this at RTCWeb meeting at IETF 100. My read of this is that your testing indicated used of other things out performed built in Opus FEC. This leads to the question of what should RTCWEB browsers use. We could put in text to the specs that says is browsers can negotiate Flex Fec (or other things), then use it and don't use opus FEC. The current specs would not stop a browser from doing this today so this largely seems like a quality of implementation point. The topic of if something like RED helps or not is highly contentious and very situational - as you well know different vendors have very different defaults across the industry. I do not see us easily coming to agreement on what is best and when to use it. Given the how close this is to done, I proposed that we don't add text for this. The room seemed OK with that but I wanted to check that you can live with that? Again, I think browsers are allowed to do what you are proposing is best, and they will interoperate with ones that don't. But I don't think we have to mandate what choices they make in this regard.
Right, the fact that we say 'RECOMMENDED' leaves a lot of leeway for implementation discretion.
I need to check what we are able to say on this topic, but given that Bernard's findings don't indicate any negative result from using FEC, I don't see there being consensus to change the strength of the recommendation.
@fluffy, @spt - should we close this out?
Yes - I think we can close this one out.
I reviewed our stats regarding Opus FEC and I think the current RECOMMENDED text is indeed warranted. Closing accordingly.
See Bernard's post about its lack of effectiveness in MS tests.