WEBRTC Bandwidth Estimation __WEBRTC

Author: Gustavo Garcia (original link)

Translation: Liu Tong

Bandwidth estimation is probably the most important part of the WEBRTC video engine. The task of the Bandwidth estimation (BWE) module is to determine how much video stream you can send and not network congestion to ensure that video quality is not reduced.

In the previous bandwidth estimation algorithm is very basic, in general, based on the design of packet loss. Usually we start to slowly increase the bit rate of the video until we detect the loss of the packet. To detect lost packets, you use the standard RTCP feedback, where the receiving end uses the RTCP receive report (RR) information to periodically report the packet loss.

Today's bandwidth estimation algorithms are becoming more advanced, trying to detect congestion before the router starts discarding packets. These algorithms predict congestion by analyzing the delay between packets. The idea is that when you start to encounter congestion, the data will start to flow into the buffer in the router, and the latency will become more diverse. Some of the most popular of these algorithms are Google Congestion control (which is WEBRTC), scream, and Sprout. If you want to learn more about the history and status of congestion control standards, you can look at the interesting blog post Randell Jesup wrote.

Starting at the very beginning of WEBRTC, the media engine (built by Google, but both Firefox and Chrome) is based on the theory of remote bandwidth estimation. As I said before, the receiver analyzes the packet latency, generates an estimate of the available bandwidth, and then returns it to the sender using the RTCP message, where the RTCP information uses a type of information that is designed to do the job: Remb. Another detail about WEBRTC implementations is that the sender does not use only the bandwidth estimates that are received in the REMB packet, but also uses the feedback packet to determine the target video bit rate that is eventually sent.

The benefit of this implementation is that it can quickly reduce the bit rate when it detects overuse, even when congestion is not detected at the moment.

But this has changed in the most recent version of Chrome, and now all the logic of bandwidth estimation occurs on the sender side. The basic detection of congestion is not much different from the previous, and the sender needs to estimate the available bandwidth from the receiving end of the delay information. This is done with two new mechanisms/protocols:

#1 the header extension of a wide serial number: All video RTP packets have an additional 4 bits in the header to contain a serial number. This is negotiated with the SDP using the following statement:

Note: The idea of this new serial number is that you can use only one counter for audio and video, but Chrome hasn't yet used it in the audio field, so I don't think it's very useful now.

#2 Transfer feedback: The receiver periodically feeds back the sender with information about the received packet and the delay between packets. To complete this work, the receiver uses a new RTCP packet (transmission feedback). This is negotiated in the SDP with the following statement that includes the new RTCP feedback:

When you look at what the transmission feedback packet looks like, it's interesting that you realize that there are Google's recommended specifications, as well as the official standardization program, but the real use is in the actual implementation of the source code.

This rtcp feedback default 100ms is sent once, but is actually dynamically adaptable, using only 5% of the available bandwidth (the minimum is 50ms and the maximum is 250ms).

To minimize size, the new RTCP package is very compact in format, including packet packets within blocks, storing numbers in base+diff, or reducing granularity to 0.25ms intervals. I have done a simple test, with these improvements, it will still use 16Kbps to send a feedback packet per 50ms.

You can view related implementations in Remote_estimator_proxy.h and transport_feedback.cc.

What is the benefit of the bandwidth estimate at the transmitter end. Google's explanation is that, in so doing, all the decision logic will be in one place (the sender), and this will make testing the new algorithm simpler because you don't have to depend on two endpoints at the same time. To be honest, because of automatic browser updates, I don't see the big benefit of this change, but it's really neater, even more expensive in terms of bandwidth usage. Another advantage is that the sender can know what type of data stream they are sending, or use a different algorithm when sending a regular video instead of doing something like a screen broadcast.

Will we be affected by the actual impact? If you build a media server that requires bandwidth estimation, you need to update your implementation to some extent. The good news is that Chrome will also support the old mechanism (REMB) for a while, at least until Firefox supports it. But Remb may not make any new progress, and now the likelihood of a bug is higher, so I think it's not a good idea to postpone the update too long.

Is the bandwidth of the transmitter really better? I did a quick test (this is the test page, you can try one, or by changing the Boolean to do other tests, in which the two algorithms (old REMB and new transmission feedback) are used in chrome, and the new algorithm behaves much better, at least in the ascending part of the initial phase of the connection. I don't think there is a technical explanation for this kind of result except that Google is now investing in new algorithms, regardless of the old algorithm, and all of the haste will only happen in the new algorithm. Obviously in the new algorithm, in the first two seconds there must be some special way to deal with bandwidth estimation, but I did not study too much.

Now who's doing this and what's going on. The bandwidth estimate for the sender is the default algorithm in the Chrome55 version, but it is still in the process of development, so we should do well to anticipate many changes. Official standardization work is done in the IETF of the Rmcat workgroup, but now most of the available implementations in Chrome are Google's own version, which is the norm for Google's own algorithms and feedback protocols.

*chrome is also planning to use the bandwidth estimation algorithm (which is planned to be added in version 58) to determine the audio bit rate sent.