Subject: [rtcweb] Comments on draft-ietf-rtcweb-fec-04 (Opus FEC)

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 May 2017 14:50:49 -0700

Section 3.3

   For Opus, packets deemed as important are re-encoded at a lower
   bitrate and added to the subsequent packet, allowing partial recovery
   of a lost packet.  This scheme is fairly efficient; experiments
   performed indicate that when Opus FEC is used, the overhead imposed
   is about 20-30%, depending on the amount of protection needed.  Note
   that this mechanism can only carry redundancy information for the
   immediately preceding packet; as such the decoder cannot fully
   recover multiple consecutive lost packets, which can be a problem on
   wireless networks.  See [RFC6716], Section 2.1.7
<https://tools.ietf.org/html/rfc6716#section-2.1.7> for complete
   details.

Section 4.1

   When using the Opus codec, use of the built-in Opus FEC mechanism is
   RECOMMENDED.  This provides reasonable protection of the audio stream
   against typical losses, with modest overhead.  Note that as indicated
   above the built-in Opus FEC only provides single-frame redundancy; if
   multi-packet protection is needed, the built-in FEC should be
   combined with [RFC2198 <https://tools.ietf.org/html/rfc2198>]
redundancy to protect the N-2th, N-3rd, etc.
   packets.

[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.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 24 May 2017 17:02:38 -0700

This would be a pretty dramatic statement, basically indicating that the
FEC mechanism that has been built for Opus is not useful.

While I understand the rationale, I would like to have some more specific
results that we can point at before making such a claim in a RFC.

On Tue, May 16, 2017 at 2:50 PM, Bernard Aboba <[email-masked]>
wrote:

>    wireless networks.  See [RFC6716], Section 2.1.7 <https://tools.ietf.org/html/rfc6716#section-2.1.7> for complete
>    details.
>
>
> Section 4.1
>
>
>    combined with [RFC2198 <https://tools.ietf.org/html/rfc2198>] redundancy to protect the N-2th, N-3rd, etc.
>    packets.
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>