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://;
  webrtc_abr;
  transcoder vb=1000k size=1920x1080 bf=0 vb=300 size=320x240 bf=0 ab=64k acodec=opus;
}

If you prefer to have more control over the adaptive bitrate streaming, specify additional parameters for webrtc_abr:

Parameter Description Example
start_track Video track number from which playback starts. Possible values: v1, v2, v3 and so on.

If not specified, or an audio track specified (start_track=a3), or a video track number does not exist, playback starts with the track number in the middle of the list (e.g. v2 if you have tracks v1, v2, and v3) and then adjusts to the bandwidth availability.

If some tracks are excluded by the query parameter ?filter=tracks:..., Flussonic searches for an available track with a lower number up to v0. If no track with a lower number was found, Flussonic searches for a closest track with a higher number.		 start_track=v4
loss_count Packet loss counter. Specified as integer.
The default value is 2.		 loss_count=3
up_window If during the last up_window seconds there were less than loss_count lost packets and bandwidth (defined by REMB/TWCC) is sufficient for the next bitrate track, then the client player switches to the higher bitrate track.
The default value is 20.		 up_window=17
down_window If during the last down_window seconds there were more than loss_count lost packets, the client player switches to the lower bitrate track regardless of REMB/TWCC.
The default value is 5.		 down_window=6
ignore_remb If true, Flussonic ignores REMB (Receiver Estimated Maximum Bitrate) reported by a peer when switching bitrate to a higher value.

If false, the bitrate will not exceed the one sent by the client in the REMB.
Use only with REMB; does not affect anything when using TWCC.
The default value is false.		 ignore_remb=true
bitrate_prober If true, Flussonic periodically sends probe packets to measure available bandwidth and switches bitrate to a higher value if possible. Learn more here: Using REMB or TWCC for ABR.
The default value is false.		 bitrate_prober=true
bitrate_probing_interval The time interval of sending probe packets, in seconds. Learn more here: Using REMB or TWCC for ABR. bitrate_probing_interval=2

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.

REMB

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.

TWCC

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;