Re: [rtcweb] FEC for audio?

I don't think we would send a standalone FEC packet, given the overheads -
I would expect we would use RFC 2198 encoding and send 5109 FEC as
piggyback on the 'next' audio packet, similar to how I understand the
internal FEC works. This would have (5 + 10 + 4) * 8 = 152 bits of overhead
per packet, or ~8 Kbps when using 20 ms frames.

On Mon, May 19, 2014 at 6:16 PM, Timothy B. Terriberry <
tterriberry@mozilla.com> wrote:

> 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.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>