PSA: opus+red enabled by default in M96

[Philipp Hancke]

I’ve landed a change that allows using a combination of opus and RFC 2198 redundancy which may improve audio quality in a number of use-cases:

  https://chromiumdash.appspot.com/commit/773a2226671506f7438487e0df0cc3f2d66b4a98

This enabled RED by default in M95 but it is toggled off via a killswitch since it was missing the fmtp line which took a bit longer to ship (the final bit landed in 96.0.4663.0).

Try it:

Using Chrome Beta (M96 currently) you can try it on

  https://webrtc.github.io/samples/src/content/peerconnection/audio/

Since the difference is a bit hard to hear see https://webrtchacks.com/red-improving-audio-quality-with-redundancy/ for how to evaluate RED, e.g. with simulated packet loss as well as https://webrtchacks.com/implementing-redundant-audio-on-an-sfu/ and https://www.meetecho.com/blog/opus-red/ for how a server might utilize RED.

Implementation notes:

audio/red will be using a payload type 63 by default. Note that libwebrtc (in M96) will require a RFC 2198 fmtp line. This does not influence the amount of redundancy the encoder generates which defaults to 1 for the time being. Note that M96 will not negotiate RED from M95 due to the missing fmtp line (which is the reason this got disabled via the killswitch so it should not show up normally).

opus+red is not active by default but can be activated through the setCodecPreferences API by changing the order of codecs such that red appears before opus. Note that in getStats opus+red will still be identified as “opus”.

The encoder is configured to encode a single redundant packet. This greatly improves the POLQA-MOS score for low packet loss without excessive bandwidth overhead. It is possible to use the encoded insertable streams API to write a custom encoder that wraps opus frames in the RFC 2198 format for applications that require more flexibility with respect to the amount of redundancy.

On the receiving side, there is no practical restriction on the amount of redundancy (the hard limit is 32), tests were done with up to four redundant packets.

See the issue tracker for more details.

[eggert.c...@googlemail.com]

Thanks a lot for your efforts and transparency!

Maybe I had a misunderstanding here: I'm trying to get this running between an Android device and the current Chrome Canary right now, but I'm only having luck so far when the Android side is setting the answer and Chrome the offer, but not the other way around.

I have a pastebin which first contains the offer that Android sends over and then the answer that the Chrome API creates: 

https://pastebin.com/Rq2CPNEe

From my point of view the Android offer looks correct here and prioritizes red with " m=audio 9 UDP/TLS/RTP/SAVPF 63 ..." - however, the resulting createAnswer does not contain any red/48000/2 entry whatsoever. This entry does exist when creating an offer though.

Any idea what I am doing wrong here? I'd appreciate any help/guidance. 

Doing it the other way around seems to work like a charm and Android actually uses opus red. 

[Philipp Hancke]

what version are you using on Android? Chrome 96 won't negotiate RED unless the fmtp line along the lines of

  a=fmtp:63 111/111

is present while the apparently older version of Android will just ignore those lines from the M96 offer.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4fc825c3-3042-4b84-acf5-0e92dadf40b3n%40googlegroups.com.

[eggert.c...@googlemail.com]

That line was indeed the key - I thought my version was recent enough as it had all the other lines, but after updating the codebase again this turned up and I have red active in both directions. Thanks a bunch, Philipp :).