The past 10 to 15 years have witnessed a major upheaval in how entertainment
content is distributed to, and consumed by, end users. This upheaval is underpinned
by the consumers’ desire to watch content when they want it, at whatever location
they are, and on whatever playback device they have at their disposal. This desire
could only be satisfied – on a massive scale – by leveraging the reach and capabilities of the Internet. Almost all playback and display devices – smart TVs, tablets, PCs, smartphones, game consoles, etc. – can be connected to it, from any location, and at any time because they support the core Internet protocols (IP, TCP and UDP).
More recently, this transition towards IP networks for content distribution has also been taking place on the B2B side of the entertainment business. This can be seen in production plants – where cameras are IP-enabled and IP switchers and routers are replacing traditional SDI-based gears– in post-production, and in contribution feeds to Multichannel Video Programming Distributors (MVPDs).
The Internet’s traditional transport protocols (UDP and TCP) were designed long before such trends took place. This makes them suboptimal for the various use cases of audio and video transport. This suboptimality was recognized as early as 1990 when the concept of Application Layer Framing (ALF) was first introduced [ALF]. With ALF, applications customize transport layer functionalities (such as error and rate control) at the application layer to suit their specific requirements.Given the proliferation of applications requiring transport of multimedia content (video, audio, closed captions, and associated metadata) over IP, numerous ALF transport protocols have been developed to achieve optimum performance for
each use case. The first widely deployed instance was the Real-time Transport Protocol (RTP) and its companion Real-time Transport Control Protocol (RTCP), first introduced in the mid-1990s. Since then, many others have been developed –some proprietary, others open source, some fully standardized and others still in draft specification form – leading to a confusing alphabet soup of protocols.
It is the intent of this White Paper to decipher this alphabet soup by providing overviews of the more popular protocols and identifying the use cases where they bring the most value.
| Protocol | Transport Layer | Adaptive Bitrate (ABR) | Latency | Primary Use Cases | Licensing / Standard | Reliability Mechanism | Key Features / Notes |
|---|---|---|---|---|---|---|---|
| RTP/RTCP | UDP | No (Payload only; compression determined by codec) | Low (Network-dependent; no built-in retransmission delay) | Traditional OTT (legacy), contribution/primary distribution, video conferencing | Open Standard (IETF RFC) | No built-in retransmission (typically used with FEC) | Includes sequence numbers and timestamps; RTCP for QoS monitoring; poor firewall traversal; does not support CDN caching. |
| HLS / DASH (HTTP Adaptive Streaming) | TCP (UDP for HTTP/3) | Yes (Chunked transfer; supports multi-bitrate) | High (Traditional 30s+; Low-Latency mode can reduce to a few seconds) | End-user OTT distribution, VOD, live streaming | Open Standard (DASH is an MPEG standard; HLS led by Apple) | Relies on TCP retransmission (Application layer adapts to bandwidth via bitrate switching) | File-based download rather than streaming; highly scalable via CDN caching; client-side intelligent bandwidth adaptation; firewall-friendly. |
| RTMP | TCP | Yes (Chunked transfer) | Low (Sub-second, but limited by TCP) | Legacy systems, pushing streams to CDN edges, legacy Flash applications | Proprietary (Adobe; specs partially open but deprecated) | Relies on TCP retransmission | Flash-based; supports multiplexing; Adobe has discontinued support; recommended only for legacy device compatibility. |
| Zixi | UDP | No (Transports encoded streams) | Low (Configurable, typically <1500ms) | Primary distribution, remote production, reliable live transport | Proprietary (Zixi Corporation) | FEC (Z-FEC) + ARQ (Hybrid mechanism) | Supports link bonding; dynamic bitrate adaptation; high reliability; requires dedicated components (Feeder/Broadcaster/Receiver). |
| SRT (Secure Reliable Transport) | UDP | No (Transports encoded streams) | Low (Configurable, typically a few hundred milliseconds) | Contribution distribution, live transport over the internet, alternative to RTMP/Zixi | Open Source (Initiated by Haivision, promoted by the SRT Alliance) | ARQ (Optional FEC, but implementation details are not specified in the spec) | Based on UDT; connection-oriented sessions; AES-128 encryption; does not support link bonding; highly accepted in the Asia-Pacific and price-sensitive markets. |
| RIST (Reliable Internet Stream Transport) | UDP | No (RTP-based) | Medium/Low (Depends on Profile; ARQ introduces buffering delay) | Multi-vendor interoperable primary distribution, reliable internet transport | Open Standard (Video Services Forum, VSF) | ARQ (NACK) for Simple Profile; FEC for Main Profile | Aims to solve proprietary protocol interoperability issues; supports link bonding; Main Profile supports encryption (DTLS) and multiplexing; implementation details left to vendors. |
| QUIC | UDP | No (Transport layer protocol; upper-layer application decides) | Low (Faster handshake than TCP; no head-of-line blocking) | Next-gen web transport, underlying protocol for HTTP/3, latency-sensitive web applications | Open Standard (IETF) | Built-in packet loss recovery (Independent stream control; no head-of-line blocking) | Foundation of HTTP/3; solves TCP head-of-line blocking during multiplexing; integrates TLS 1.3; strong connection migration capabilities. |
| NDI (Network Device Interface) | UDP/TCP (Primarily UDP multicast) | Yes (Supports high-efficiency and compressed formats) | Medium (Software-synced; not frame-accurate) | ProAV within LANs, live production, video conferencing, software-defined workflows | Proprietary (NewTek/Vizrt; provides free SDK) | No explicit built-in mechanism (Relies on high bandwidth and low packet loss in LANs) | Auto-discovery (Zero Config); easy deployment; low hardware requirements; not suitable for long-distance or high packet-loss networks; primarily used for uncompressed/visually lossless transport within LANs. |
Techhub
DOC-REV 2026.07 · EN