Avoiding WebRTC in the studio is not just about picture or sound quality. It’s about architectural intent. WebRTC is designed to adapt to unpredictable networks, while broadcast production systems are deliberately engineered to eliminate unpredictability altogether.

It’s worth reminding ourselves why broadcast engineers strive for low and predictable latency in studios. Fundamentally, low latency keeps production responsive, and deterministic latency keeps productions reliable. Furthermore, live productions rely on time-critical systems where signals must remain aligned, predictable, and controllable.

The Case For Deterministic Delay

To achieve frame accurate switching, video frames must be temporally aligned where precise boundaries need to be adhered to. Deterministic delay ensures every path through the system has a known, repeatable timing plane, thus allowing camera, graphics, and video-server feeds to be switched and mixed cleanly without distortion or interference.

Human interaction is highly delay sensitive, and during live productions directors cue presenters, presenters hear IFB returns, and commentators react to live action. Low and determinate latency keeps conversations sounding natural and more importantly, consistent latency prevents awkward silence on-air. Humans can easily adapt to fixed delay, but they struggle with variable delay – and hence latency – that changes unpredictably.

Consequently, broadcast engineers design systems around worst-case scenarios, not average performance. This allows them to define end-to-end latencies, buffer depths, failover timing and switching margins. This makes integration, troubleshooting, and scaling the system manageable and predictable. Variable and non-deterministic latency introduces the potential for unpredictable error at every stage of the workflow.  Not only does this lead to the potential for video and audio dropout, but it also means that any errors can appear randomly and without warning.

Managed networks used in studios guarantee adequately provisioned bandwidth, QoS is prioritized and systems are segmented to facilitate scaling and systematic fault finding. Because the infrastructure is engineered to be stable, the transport layer must also be stable. Adaption mechanisms that dynamically change buffering or bitrate may help with unmanaged networks, but inside a studio infrastructure, they undermine predictability.

How WebRTC Underpins Media Ecosystems

At its core, WebRTC is a real-time media framework originally developed to allow browsers to exchange video, audio, and data directly without plugins or proprietary software. It’s not just a codec or signaling method but is a complete transport stack for distributing interactive media over IP.

WebRTC uses RTP (Real-Time Protocol) over UDP with SRTP (Secure RTP) encryption by default. Protocols including ICE, STUN and TURN allow it to automatically traverse NATs (Network Address Translations) and the built-in congestion control stops flooding of the network similar to Transmission Control Protocol (TCP).  Adaptive bitrate encoding allows the codec to dynamically change its compression ratio depending on the network conditions and jitter buffering and packet loss concealment help keep the detrimental effects of any packet loss to a minimum. Fundamentally, it is designed to facilitate real-time communications across unmanaged, unpredictable networks, particularly the public internet.

Many of today’s interactive media ecosystems are underpinned by WebRTC, including video conferencing, browser-based remote contribution tools, online education platforms and VoIP services. The internet is particularly troublesome for media distribution: bandwidth fluctuates, packets are lost, and latency can vary significantly from moment to moment. Users are frequently located behind NAT devices, routes may change mid-session, and end-to-end QoS cannot be guaranteed.

WebRTC was designed specifically for this environment. It establishes connections using ICE, STUN and TURN to traverse firewalls and NAT boundaries, encrypts media by default, and continuously monitors packet loss, round-trip time and available bandwidth. Based on these measurements, it dynamically adjusts encoder bitrate, resolution, frame rate and buffering depth. If congestion increases, it reduces transmission rate; if conditions improve, it scales quality back up.

This closed-loop adaptation allows media sessions to remain stable even when the underlying network is unstable, prioritizing continuity of communication over fixed latency or fixed signal characteristics.

Although WebRTC has a proven track record of working across the internet and other unmanaged networks, through its adaption methods, it does suffer from multiple anomalies.

To navigate jitter and packet loss, WebRTC employs dynamically adjustable buffer depths. This means that end-to-end delay is not fixed and it can increase under congestion and decrease when conditions improve. For internet conferencing, this is acceptable, but for tightly synchronized systems, such as those requiring fast and accurate video and audio mixing and cutting, this dynamic buffer allocation creates too much uncertainty, as shown in Figure 1.

Congestion Control

The principal goal for WebRTC is maintaining continuity of service rather than accurate and deterministic video and audio timing. The protocol constantly monitors the network quality and changes the picture quality by adjusting the codec bitrate. As the network bandwidth can be heavily contested, the resulting picture quality can vary enormously, giving rise to dramatic resolution shifts and even frame rate adaption.

Congestion control is needed to stop congestion collapse on the internet, or any other unmanaged network that the media may be traveling over. As WebRTC employs UDP (User Datagram Protocol), it must also provide its own method of congestion control, and it does this through sophisticated algorithms that automatically react to perceived changes in the network conditions. These algorithms prioritize fairness and stability across the internet, but this does mean that broadcast engineers do not fully control the transport behavior; media timing can change without any explicit changes, and delay and throughput are influenced by decisions at the remote endpoints. In other words, congestion control is delegated to the control stack.

Designed for operation across untrusted networks, the protocol encrypts media by default and continuously probes network conditions to enable adaptive behavior. This constant monitoring and adjustment increases CPU utilization, adds encoder and decoder overhead, and introduces additional system complexity.

The Trade-Off

WebRTC optimizes for delivery in hostile networks such as the internet and keeps media flowing even when the network misbehaves. However, the price paid for this reliability and flexibility is that latency becomes variable and indeterminate, video and audio quality becomes adaptive and will change in resolution, and the transport behavior becomes dynamic and therefore indeterminate.

Attempting to mix between video and audio sources that do not share the same sample clock is at best challenging, some might say impossible, which is why broadcasters go to such great lengths in defining and implementing timing planes in video and audio infrastructure. On the public internet, this trade-off makes perfect sense as without buffer and bit rate adaption, video and audio media exchange would be almost impossible.

In managed networks, as those found in ST 2110 infrastructures, predictability often matters more than adaptability, which is why WebRTC dominates internet distribution and VoIP, but is rarely chosen for deterministic studio production systems. In other words, WebRTC trades control for resilience. It assumes the network cannot be trusted, so intelligence is pushed into the endpoints. That design choice makes it extraordinarily effective for global, internet-scale communication. But in environments where the network is already engineered to be stable, the same adaptive mechanisms introduce variability that engineers would otherwise eliminate.