Adapt a WebRTC stream to poor network conditions

 The Wowza Streaming Engine (WSE) WebRTC stack includes three mechanisms that keep playback stable when network conditions change:

• Simulcast: Receive multiple bitrate renditions with the option to match each viewer to the rendition their estimated bandwidth can sustain.
• Negative acknowledgement and retransmission: Report and repair individual missing RTP packets without disturbing the primary stream.
• Keyframe requests: Recover a decoder that can no longer decode what it's receiving.

Together they form an escalation ladder, and each rung is cheaper than the one above it. A sustained change in a viewer's bandwidth is handled by switching renditions, which affects only that viewer. Isolated packet loss is repaired by retransmitting just the missing packets, which is inexpensive and invisible to the viewer. Only when loss is too severe to repair does a viewer fall back to requesting a fresh keyframe.

Configure network adaptation on a WebRTC stream

Prerequisites

• A WebRTC-enabled live app
• A publisher that advertises simulcast, RTX, and PLI support in its SDP exchange
• A player that advertises RTX, TWCC and/or REMB in its SDP exchange

Configure in WSE Manager

All three mechanisms are controlled with the application's WebRTC properties. To update an app's network adaptation configuration settings in WSE Manager, follow the steps below.

1. Open WSE Manager.
2. Click the Applications tab.
3. Select the name of the app.
4. In the contents panel, click WebRTC.
5. Select either the Simulcast tab or theAdvanced / RTP Feedback tab.
   • Simulcast: Simulcast, bandwidth estimation, and adaptive rendition selection
   • Advanced / RTP Feedback: NACK/RTX and keyframe requests
6. Click Edit.
7. Change the settings, as needed.
8. Click Save.

Configure in Application.xml

To update an app's network adaptation configuration settings in its  Application.xml configuration file, follow the steps below.

1. Navigate to your app's [install-dir]/conf/[app-name] directory.
2. Open the  Application.xml file.
3. Navigate to the <WebRTC> → <Properties>  container.
4. Adjust the configuration setting, as desired. (See the sections below for tuning guidance.)
5. Restart the app to apply the changes.
   
   
   

6. <!-- Example WebRTC network adaptation properties (See configuration settings for a full list) -->
   <!-- The properties below belong in the <WebRTC>/<Properties> container of Application.xml -->
   
   <Property>
       <Name>webrtcEnableTransportCC</Name>
       <Value>true</Value>
       <Type>Boolean</Type>
   </Property>
   <Property>
       <Name>webrtcEnableRemb</Name>
       <Value>true</Value>
       <Type>Boolean</Type>
   </Property>
   <Property>
       <Name>webrtcEnableSimulcast</Name>
       <Value>true</Value>
       <Type>Boolean</Type>
   </Property>
   <!-- Without this, viewers stay on the highest-priority rendition and never switch -->
   <Property>
       <Name>webrtcRenditionSelector</Name>
       <Value>bandwidth</Value>
       <Type>String</Type>
   </Property>
   <Property>
       <Name>webrtcEnableNack</Name>
       <Value>true</Value>
       <Type>Boolean</Type>
   </Property>
   <Property>
       <Name>webrtcEnableRTX</Name>
       <Value>true</Value>
       <Type>Boolean</Type>
   </Property>
   <Property>
       <Name>webrtcPLIInterval</Name>
       <Value>3000</Value>
       <Type>Long</Type>
   </Property>

Simulcast

Prerequisites

• A WebRTC-enabled live app
• A publisher that advertises simulcast in its SDP exchange

Simulcast allows WSE to receive multiple independently encoded renditions of the same stream at different bitrates on a single WebRTC track. WSE then forwards a single rendition to each viewer. Each viewer in a mixed audience gets the best quality for their connection, instead of everyone being held to the weakest link. A viewer on a congested connection can be moved to a lower rendition without adding encoding load or affecting other viewers.

By default, WSE forwards the highest-priority rendition, as determined by the publisher. A viewer whose connection cannot sustain that bitrate loses packets or stalls rather than dropping to a lower rendition. If the forwarded rendition stops, viewers move to the nearest live rendition below it in priority order, or to the highest live rendition if there is none below it, and return when the original republishes. (Audio is unaffected, because every rendition carries the same audio.)

Because every viewer receives the top rendition, plan egress to be the number of concurrent viewers multiplied by the bitrate of the highest rendition. The default simulcast settings work well when viewers are on known, provisioned connections or when every viewer should receive identical quality.

When viewer connections vary, you may choose to enable adaptive rendition selection. See the section below for more information.

Adaptive rendition selection

Prerequisites

• A WebRTC-enabled live app
• A player that advertises transport-cc or goog-remb in its SDP exchange

When adaptive rendition selection is enabled, WSE moves each viewer between renditions on its own, following a per-viewer bandwidth estimate reported by that viewer's player. WSE's WebRTC stack supports receiver estimated maximum bitrate (REMB) and transport-wide congestion control (TWCC) bandwidth estimators.

• REMB: The viewer reports its own estimated maximum bitrate and WSE follows it. Negotiated in the SDP as goog-remb.  Enabled by default.
• TWCC: The viewer reports the arrival time of every packet and WSE runs congestion control over them, probing for spare capacity. Negotiated in the SDP as transport-cc. Disabled by default.

Both bandwidth estimators are negotiated per viewer on the playback leg: WSE echoes goog-remb or transport-cc in its SDP answer when the player offers it, it doesn't advertise either to publishers.

Only one estimate runs per viewer. Which one applies depends on what that viewer negotiated:

Negotiated with the viewer	Estimate that drives rendition selection
TWCC (with or without REMB)	TWCC. It takes precedence wherever it is negotiated.
REMB only	REMB, the fallback for viewers that don't offer TWCC.
Neither	None. The viewer stays on its initial rendition, as if adaptive rendition selection were disabled.

You can change the REMB and TWCC settings in WSE Manager on the Simulcast tab, or by editing the app's bandwidth estimation WebRTC configuration settings.

When adaptive rendition selection is enabled, you can adjust the additional simulcast settings in the list below. When adaptive rendition selection is disabled the settings are greyed out in WSE Manager.

• Initial Rendition: Whether the viewer is initially sent the highest or lowest rendition.
• Upgrade Margin (%): The percentage of headroom above a rendition's required bitrate that the estimate must exceed before upgrading to it, as a percentage.
• Downgrade Margin (%): The headroom below the current rendition's required bitrate that the estimate must fall past before downgrading from it, as a percentage.
• Downgrade Debounce (ms): The debounce window before a downgrade takes effect, in milliseconds.

You can tune an app's default simulcast settings in WSE Manager or by editing the app's simulcast configuration settings. To update simulcast settings in WSE Manager, open the application, click the WebRTC tab, select the Simulcast tab, then click Edit. 

The list below has example situations that may warrant tuning, along with the appropriate simulcast property.

• Disable simulcast: Turn off simulcast. (Set webrtcEnableSimulcast to false.)
• Viewers never move off one rendition as bandwidth changes: Enable adaptive rendition selection. (Set webrtcRenditionSelector to bandwidth.)
• Viewers get more quality changes than you want, or fewer: Adjust the upgrade and downgrade margins and the downgrade debounce. (Update webrtcRenditionUpgradeMarginPercent,webrtcRenditionDowngradeMarginPercent, or webrtcRenditionDowngradeDebounceMs.)
• Playback starts blurry, or stalls before the first frame: Update the initial rendition selection. (Update webrtcRenditionInitialRendition.)
• Viewers climb too slowly, or too eagerly: Change the upgrade margin. (The downgrade margin must be set higher than the upgrade margin; an invalid pair is rejected and the defaults are restored.)
  
  
• Quality drops on brief network dips: Change the downgrade margin or the downgrade debounce, to add stickiness

Advanced & RTP Feedback settings

NACK and RTX

Prerequisites

• A WebRTC-enabled live app
• 
  A player and publisher that advertise RTX in their SDP exchange

When a viewer detects a missing packet, it sends a negative acknowledgement (NACK) identifying the lost sequence numbers. The sender responds by retransmitting them (RTX), usually on a separate stream dedicated to retransmissions.

A retransmission is only useful if it arrives before the packet is due for playout, so NACK works best on low-latency paths where a round trip fits comfortably inside the receiver's jitter buffer. On long or badly lossy paths, forward error correction is the better tool.

In an SFU topology, the viewer's NACK is handled by the SFU rather than the publisher. The SFU keeps a short cache of recently sent packets and retransmits from it, only requesting the packet from the publisher if it doesn't have it.

Negative acknowledgement (NACK) allows a viewer to notify the publisher when a packet is lost. Once the publisher receives a NACK about a lost packet, it retransmits them (RTX). NACK and RTX work in conjunction to repair isolated packet loss by retransmitting just the missing packets, rather than requesting a new keyframe. This is inexpensive on the network, but adds a small fixed delay to the stream, typically tens of milliseconds at the default cache size, so it isn't free the way changing renditions is.

When NACK and RTX are enabled, WSE will listen for NACKs from viewers and retransmit lost packets from a cache on a parallel stream. It will also send NACKs to publishers and wait for packet retransmission. NACK and RTX are disabled by default. We recommend enabling them when you see frequent full-picture refreshes on lossy networks.

You can enable NACK and RTX in WSE Manager or by editing the app's NACK and RTX configuration settings. To configure NACK or RTX in WSE Manager, open the application, click the WebRTC tab, select Advanced / RTP Feedback, then click Edit.

 The list below has example situations that may warrant tuning.

• Retransmissions arrive for packets that were only reordered: Update the NACK delay. (Update webrtcNackDelayMs.)
• Loss persists on high-bitrate renditions: Update the RTX cache. (Update webrtcRTXCacheSize.)

Keyframe requests

Prerequisites

• A WebRTC-enabled live app
• A player that advertises PLI or FIR in its SDP exchange

WSE supports two RTCP feedback messages for requesting keyframes: Full Intra Request (FIR) and Picture Loss Indication (PLI). PLI support was added in WSE 4.12. Both PLI and FIR are automatically negotiated by WSE for every WebRTC stream. You can configure an app's keyframe request settings in WSE Manager or by editing the app's keyframe request settings. To configure the app's keyframe request intervals in WSE Manager, open the application, click the WebRTC tab, select Advanced / RTP Feedback, then update the settings below:

• PLI (Picture Loss Indication):
  PLI Interval (ms): The minimum interval between PLI messages per stream, in milliseconds (range 100-60000, default 3000).
• FIR (Full Intra Request):
  • FIR Message Scheme: How FIR messages are paced. May be set to either time or frame:
    • time: Request a new keyframe after every n milliseconds.
    • frame: Request a new keyframe after every n frames.
  • FIR Message Interval: The interval between FIR messages. The units depend on the scheme (default 1000 ms for time, 30 frames for frame).