We recently enabled Forward Error Correction (FEC) for audio streams in Firefox’s WebRTC implementation using the built in support provided by the Opus codec. FEC creates a redundant, low bitrate encoding of audio that can be used to recreate lost packets. Since enabling FEC requires splitting some of the bitrate for use by the redundant encoding that could otherwise be used for the primary encoding, it was important to test whether or not FEC would actually result in improved call quality.
The way that Opus splits bitrate is such that for the default setting for audio bitrate in Firefox (40 kbps) FEC will not be enabled for two input channels, so all testing was done with the number of input channels set to one. Work is underway in Opus to make it more effective at lower bitrates, but for now, the bitrate would have to be increased to 58000 kbps for Opus to start producing LBRR packets with two channels enabled.
We collect telemetry on dropped packets. The telemetry values are permille, so even at the 75th percentile, we’re seeing around 1.854% reported packet loss. The threshold for enabling LBRR within Opus is around 1%, so if our telemetry is accurate, FEC would not have any effect on about 66% of calls made. The tests were performed at the 75th and 95th percentiles, so 1.854% simulated packet and 19.435% packet loss. The tests were done using netem on Linux and also included 1000ms of simulated latency, the scripts containing the exact commands used can be found here. Calls were made from Firefox Nightly to Google Chrome 51 using default settings.
The Opus configuration under test was set in ACMGenericCodec::ResetAudioEncoder to force the number of channels and whether or not FEC was enabled to the desired values without having to be concerned about them being overwritten by other parts of the system. This is also were experimentation with bitrates was performed. The recording controls in the Linux Pulse Audio Volume Control application were used to play the clip into Firefox, bypassing the microphone, and record the audio from Chrome, bypassing the speakers.
Call with no packet loss:
Call with 1.854% packet loss and no FEC:
Call with 1.854% packet loss and FEC:
Call with 19.435% packet loss and no FEC:
Call with 19.435% packet loss and FEC:
The difference between FEC on and off is subtle at low packet loss rates and is unlikely to have much impact on the majority of calls made; at high packet loss rates it makes a very noticeable difference.