Almost a year back we had a post about FEC in WebRTC in which we spoke about the need to balance the amount of redundancy added due to bandwidth considerations and that since there are networks without congestion control, it should be possible in WebRTC to limit the added redundancy.
In this post we will look at the implementation side of it given the changes Google announced in Chrome 50 (Beta) release notes.
There are different ways to implement FEC. FEC can be achieved by adding redundant information or by sending an additional, lower resolution.
A good on the topic is this IETF document by Justin Uberti from Google that talks about how FEC should be implemented in WebRTC.
You might also want to read the following 2 standard documents about redundancy (RED) mechanism, and corresponding Forward Error Correction info (ulp-fec):
In WebRTC, up until Chrome 50, the way to signal in SDP that FEC is being used for a media stream was by adding an m-line RED. Since FEC was possible for VP8 only it was assumed that this RED m-line is for the VP8 codec. It was not possible up until Chrome 50 to negotiate more than one retransmission (RTX) or redundancy (RED) codecs.
This typically resulted in 2 m-lines, one for VP8 and the other for VP8 with FEC, appearing as “RED”. If the other side didn’t support the Google way of doing FEC it could choose the VP8 m-line rather than the RED m-line.
As of Chrome 50 support for FEC in other codecs (e.g. VP9) was added. This made things a bit more complex and required some changes that impact applications.
This post it to help you mind the gap.
This change directly impacts cases where Chrome 50 and above is used. Since this is a modification of the media stream, interoperability with other browsers or end points might be impacted as well.
Applications that were implementing support for Forward Error Correction and leveraging chrome’s RED, ulp-fec with VP8 for that should:
- Double-check for regression with VP8
- Extend their code to use the same mechanism now available for VP9
Eventually, the redundancy (RED) and FEC mechanisms interact with bandwidth estimation and control parameters (nack, poi, rtx, remb, …) in the browser context. While beyond the scope of this update, a review of the corresponding material mentioned above in this post is advised.
This is a quality feature (retransmission, possibly multiplexed with the original media) that paves the way for a much better experience with VP9. While this does not require any change, nor break any existing code, it might break interoperability.
It is also interesting for people who want to get the best out of VP8 (today) and VP9 (tomorrow) to start experimenting with.
It paves the way for not only a better VP9, but also support for better quality in simulcast and SVC media transmission with more than one codec (think: VP8 for the low resolution layer, and VP9 for the higher resolution, all protected against errors).
Another bug shows improvement on current VP9 testing:
Issue 554512 Add browser_tests and content_browsertests utilizing the VP9 codec.