Skip to content

Adaptive bitrate streaming over WebRTC

When streaming user-generated content, you will probably face the necessity to provide each viewer with the highest video quality their network connection can afford. To address this requirement, the WebRTC protocol provides the adaptive streaming technology which is successfully implemented in Flussonic.

Adaptive streaming is based on Adaptive Bitrate (ABR) algorithm designed to deliver video efficiently to a wide range of devices. In adaptive bitrate streaming, multiple bitrate (MBR) renditions of the same source—tracks—are created using the transcoder. The channel between server and each individual client player is then established to send one of the tracks; in the ABR mode, the server decides which track to send depending on the user's current network speed. When necessary, manual track selection can be provided in the client player.

Flussonic selects a track with bitrate and quality suitable for the user based on the following indicators received from the user's browser:

  • NACK (Negative ACKnowledgement) packet loss indicator. This is the number of lost packets per unit of time.
  • REMB (Receiver Estimated Maximum Bitrate) or TWCC (Transport-wide Congestion Control) packet rate indicator. This is the time it takes for a packet to be delivered from the server to the client player. See Using REMB or TWCC for ABR below for details.

Configuring ABR

The ABR option is enabled for WebRTC by default. This means that players will work in auto mode until a user chooses the resolution manually. To enable the auto mode again, select it in the player's settings.

Make sure to configure the transcoder to define the tracks for ABR switching, for example:

stream webrtc-abr {
  input fake://;
  transcoder vb=1000k size=1920x1080 bf=0 vb=300 size=320x240 bf=0 ab=64k acodec=opus;

Using REMB or TWCC for ABR

When playing streams via WebRTC, Flussonic uses RTP protocol for sending video and audio frames. This protocol provides two mechanisms of measuring available bandwidth. Flussonic can use one of those mechanisms in ABR algorithm to decide if it is possible to switch bitrate to a higher value.


You can choose the mechanism based on REMB (Receiver Estimated Maximum Bitrate) message reported by the client. The bitrate of sent video will not exceed the one sent by the client in the REMB. However, if REMB grows, Flussonic can switch to a track with a higher value. Learn more about REMB.

This is a simple mechanism, however it has some drawbacks:

  • After temporary packet loss (for example, due to network connection failure), REMB falls dramatically and then increases too slowly (for 5-15 minutes). During this time Flussonic cannot switch to a track with better quality for a long time although the client is able to play it.
  • Flussonic cannot control this value because it is calculated on the client’s side.
  • This mechanism is marked as deprecated and probably will not be developed.

To enable REMB mechanism, set bitrate_prober=false in the webrtc_abr directive.


By default, Flussonic uses the TWCC (Transport-wide Congestion Control) mechanism available as RTP extension. Learn more about TWCC.

In this case, Flussonic adds to each sent packet an RTP header extension that contains the extension ID and the packet sequence number. The client sends back an RTCP feedback message containing the arrival times and sequence numbers of the packets received on a connection. Thus, Flussonic knows the sending time and receiving time of each packet and can calculate the difference between them. Also, Flussonic knows the size of each packet, so it can calculate the bitrate the packets were actually sent with.

To estimate maximum possible bitrate, Flussonic sends groups of so called probe packets at regular intervals. These packets are sent with a bitrate higher than the current one. When the packets are received, Flussonic calculates their actual bitrate as described above. If after some iteration the calculated bitrate exceeds the bitrate of the next (higher quality) track at 10% and the packet loss (NACK) conditions are satisfactory, Flussonic switches to the next track.

This mechanism provides more control and flexibility because most of its logic works on the sender side.

You can set the following parameters of TWCC mechanism in the webrtc_abr directive:

  • bitrate_prober=true – switch to using TWCC
  • bitrate_probing_interval– the time interval of sending probe packets, in seconds.

For example:

webrtc_abr bitrate_prober=true bitrate_probing_interval=2;