Re: [rtcweb] FEC for audio?

["Timothy B. Terriberry" <[e-mail]>]

Justin Uberti wrote:
> Advice on the exact value of XX welcomed.

That is complicated, of course. I think if you're using SILK, you should 
probably always prefer the in-band FEC (if nothing else, it saves you a 
minimum of 54 bytes of header overhead over RFC5109), but that's a 
decision we make on a packet-by-packet basis.

However, libopus will use CELT at rates as low as 12 kbps (and always 
uses CELT for CBR rates below 8 kbps), and will use SILK/Hybrid at rates 
as high as 76 kbps, depending on the application libopus was configured 
with, our estimate of whether or not the content contains voice or 
music, the stereo width (if the signal is stereo), and hysteresis from 
previous mode decisions.

For a simple application, I'd probably enable 5109 for a mono voice 
stream encoded in VOIP mode at around 48-56 kbps (but I have not done 
any testing around these numbers). A more complex application could 
negotiate 5109 always, and then only transmit FEC for the packets that 
do not contain a SILK layer.

If you are using 5109, be careful to pass in the post-FEC recovery 
packet loss percentage to libopus when encoding, instead of the raw 
packet loss percentage. Above a certain loss rate (8% if I'm reading the 
current code correctly), libopus will force SILK usage in order to be 
able to use the built-in FEC.

When protecting CELT, you may also want to experiment with using ULP to 
protect only the beginning of the CELT payloads. We intentionally 
organized the packet so the most important information was at the front. 
The first 64-bits or so are enough to get the pitch filter and basic 
energy levels correct (though you'll probably want to send a little more 
to justify all the bitrate you spent on IP+UDP+RTP+FEC headers). As long 
as you get the energy levels correct, you cannot mess things up _too_ 
badly, even if the rest of the packet is random garbage. Make sure you 
pass the decoder a packet with the same size as the original, even if 
you only recover some of the data, as otherwise even the recovered data 
will not decode correctly.