Technical
Video transport protocols explained: NDI®, SRT, RTMP, HLS and more
NDI®, SRT, RTSP, RTMP, HLS, TS over UDP: these terms do not all refer to the same technical layer. Some describe how the video is compressed, others how it is packaged, others still how it is carried or requested. This guide starts with the basics, then orients by use, and only compares at the end.
H.264, H.265
The codec
The method used to compress and play back the image. It determines the weight of the stream, the quality, the latency and the compatibility.
MPEG-TS
The container
The packaging that bundles video, audio, timecode and metadata into a single stream. The "TS" in "TS over UDP" is exactly this.
UDP, SRT, RTMP, HTTP
The transport
How that packaging travels over the network. This is the level where the technologies on this page really compare.
A simple image helps: the codec is the compressed content of a letter, the container is the envelope, the transport is the delivery service.
These layers stack, and that is what explains the compound names on spec sheets. "TS over UDP" is not a single protocol: it is the MPEG-TS envelope sent directly over UDP. SRT often carries a similar MPEG-TS envelope, but adds reliability mechanisms, flow control and, depending on configuration, encryption. HLS changes the logic: it cuts the stream into segments referenced by playlists. In many cases the video codec stays the same, for example H.264 or H.265; what changes is how the stream is packaged, segmented or carried for the intended use. This is why a single encoder can offer SRT, RTMP, HLS, TS over UDP and RTSP outputs from one H.264 stream.
Another practical guide, to be taken as a tendency rather than an absolute rule: some modes push the stream toward a destination (TS over UDP, RTMP to a platform), others let the receiver come and fetch it (HLS, RTSP). SRT, often used for point-to-point contribution, handles its connection modes separately from the direction of the stream.
NDI® is a special case: it is not just a way of carrying video, but a complete ecosystem designed for IP production, mainly on a local or managed network.
| Need | Natural choice | Key point |
|---|---|---|
| Produce over IP on a local network (cameras, control room, monitoring) | NDI® | A complete IP production ecosystem, with automatic source discovery |
| Send a camera or a programme to a control room over the internet (contribution) | SRT | A reliable video link over imperfect networks, with optional encryption |
| Access the stream of an IP camera | RTSP | A session protocol: the receiver comes to fetch the stream, often carried over RTP |
| Publish a live stream to a platform (YouTube, CDN, live platform) | RTMP / RTMPS | The platform-ingest standard: a server URL and a stream key |
| Deliver video to web or OTT viewers | HLS | Segments served over HTTP, CDN scale, high latency |
| Distribute a stream on a managed network (internal IPTV, dedicated link) | TS over UDP | MPEG-TS sent directly over UDP, in unicast or multicast |
The most production-oriented, on a local network
NDI
NDI replaces video cables in a local network environment. It is common with PTZ cameras and production software such as vMix, OBS or TriCaster, and with manufacturers like BirdDog or Kiloview. It carries video, audio, tally, PTZ control and metadata over a single network. In High Bandwidth, it advertises a bitrate on the order of 150 to 165 Mb/s at 1080p60 with very low latency (often under 100 ms depending on the profile); the NDI|HX variants rely on H.264/H.265 to greatly reduce the bitrate.
Strengths
- +Very low latency, especially in NDI High Bandwidth
- +Comfortable for live production on a local network
- +Automatic source discovery
- +Carries video, audio, alpha, tally, PTZ and metadata
- +Very broad ecosystem across pro AV, PTZ and production software
Limits
- -Bandwidth-hungry, especially in High Bandwidth
- -Requires a clean network: proper switches, sufficient throughput, ideally a dedicated VLAN
- -Less suited to the internet or unstable networks (NDI Bridge opens up cross-network uses)
- -NDI|HX lowers the bitrate but adds compression and often latency
- -Tied to the NDI ecosystem, unlike SRT which is open source
Recommended use
Local control room, conference room, studio, light set. Avoid it as the primary long-distance contribution solution over the internet, except in a well-controlled case.
The best choice for crossing the internet
SRT
SRT carries a video stream reliably over an imperfect network: the internet, 4G/5G, best-effort fibre, a site-to-site link. It works at the transport level and does not define the video codec itself: it carries whatever it is given, often an MPEG-TS envelope with H.264 or H.265. Open source, it is designed for low latency, lost-packet recovery, jitter handling, AES 128/256-bit encryption and resilience on unpredictable networks.
Strengths
- +Very good over the internet and mobile networks
- +Far more robust than RTMP on unstable networks
- +AES encryption available
- +Low latency, often sub-second depending on the setting
- +Well suited to remote broadcast contribution
- +Multi-vendor and open source
Limits
- -Not as plug and play as NDI
- -Requires handling caller / listener / rendezvous modes, ports and firewall
- -No automatic source discovery on a LAN
- -Not a complete production protocol: no tally, PTZ or discovery
- -One-to-many often needs a server, gateway or intermediate cloud
Recommended use
Send a camera, a programme or a return feed between two sites. For a reliable video link over the internet, it is generally the most serious choice.
The classic IP camera protocol
RTSP
RTSP is mainly used to access the stream of an IP camera. In practice it controls the session (setup, play, pause, teardown) but usually does not carry the video itself: the media often travels over RTP. The official RFC describes it as a control protocol for real-time data, a kind of network remote control for a media server.
Strengths
- +Very common on IP cameras, NVRs and surveillance systems
- +Compatible with VLC, OBS, FFmpeg and some media servers
- +Low latency on a local network
- +Simple to pull a camera stream: an rtsp://... URL
Limits
- -Poor choice for streaming directly to web viewers
- -Browsers generally do not play RTSP natively: repackaging to HLS or WebRTC is often needed
- -Can be painful with firewalls and NAT, especially RTP over UDP
- -Security varies by camera; many RTSP streams are poorly protected
- -Less robust than SRT over the internet
Recommended use
Access a camera source, the most common case. Not suited to public distribution or reliable long-distance contribution.
The legacy protocol still widely used for ingest
RTMP / RTMPS
RTMP is old (historically tied to Flash) but remains widely used today to send a live stream to a platform. It mainly serves as the first mile: encoder to server or encoder to platform. The end viewer, in turn, watches in HLS, DASH or WebRTC. YouTube officially supports RTMP, RTMPS, HLS and DASH for live ingestion; RTMP/RTMPS suit normal, low-latency and ultra-low-latency modes, while HLS/DASH are better suited to 4K/HDR or modern codecs, but with more latency.
Strengths
- +Very widely compatible
- +Simple to configure: server URL + stream key
- +Supported by OBS, vMix, Wirecast, hardware encoders and live platforms
- +Good choice for sending to YouTube, a CDN or an event platform
- +RTMPS adds TLS encryption
Limits
- -Plain RTMP is not encrypted
- -Mainly limited to H.264 / AAC in common use
- -TCP-based: network loss can cause latency or stutter
- -Less robust than SRT over a difficult internet link
- -Not ideal for low-latency local production
- -Not a modern protocol for direct playback in browsers
Recommended use
Send a programme to a distribution platform, preferably RTMPS where available. To link two control rooms or for critical contribution, SRT is preferable.
Delivery to viewers, at scale
HLS
HLS (HTTP Live Streaming, developed by Apple) cuts the stream into small segments referenced by playlists (.m3u8) and served over HTTP, like regular web resources. Playback is native or via a web player, with very good network compatibility thanks to HTTP. It is the de facto standard for delivery to viewers: websites, OTT, mobile apps.
Strengths
- +Huge scale: segments are distributed through CDNs like any web content
- +Crosses firewalls and proxies without difficulty (HTTP/HTTPS)
- +Adaptive bitrate: quality adjusts to the viewer's connection
- +De facto standard of OTT and web delivery
Limits
- -High latency, often tens of seconds in standard form (reduced with LL-HLS)
- -Not made for contribution or real-time production
- -Segment-based logic differs from a continuous stream: no direct return path to the source
Recommended use
Deliver to viewers, on the web or in OTT. HLS is designed first for delivery to players; some workflows can also use it as a platform input, but that is not its most common use in live production.
The broadcast veteran, raw and deterministic
TS over UDP
TS over UDP is not a single protocol: it is the MPEG-TS envelope sent directly over UDP, in unicast or multicast. Very classic in IPTV, headends and dedicated links; in broadcast environments, multicast is often used to distribute one stream to several receivers. The RTP variant adds a real-time structure suited to audio/video (timestamps, packet sequencing), without guaranteeing quality of service on its own.
Strengths
- +Very low, constant latency
- +Native multicast support: one stream served to N receivers
- +Simple in principle, deterministic behaviour
- +Ubiquitous in broadcast and IPTV equipment
Limits
- -No error recovery: a lost packet becomes a visible artefact
- -No encryption
- -Requires a managed network (IGMP for multicast, guaranteed throughput)
- -Unsuited to the internet: SRT was created precisely to make this kind of stream reliable on imperfect networks
Recommended use
Distribute a stream on a managed network (internal IPTV, dedicated link, headend), in unicast or multicast. Avoid it for contribution over the open internet: that is exactly SRT's territory.
This table is there to confirm a choice already oriented by the need, not to discover it.
| Criterion | NDI | SRT | RTSP | RTMP / RTMPS | HLS | TS over UDP |
|---|---|---|---|---|---|---|
| Local live production | Excellent | Fair | Fair | Weak | Weak | Fair, for distribution |
| Contribution over the internet | Fair | Excellent | Weak to fair | Fair | Weak | Avoid on the open internet |
| IP cameras | Good if NDI camera | Possible, less common | Excellent | Rare | Rare | Possible on some models |
| Live platforms / CDN | Rarely direct | Platform-dependent | Rare | Excellent | Platform-dependent | Rare |
| Web delivery to viewers | Unsuited | Rare | Weak | Via a platform (ingest) | Excellent | Managed networks only |
| Latency | Very low | Low to configurable | Very low on LAN | Low to medium | High (reduced with LL-HLS) | Very low |
| Robustness on unstable networks | Medium | Very good | Weak to fair | Medium | Good (HTTP, CDN) | Weak |
| Simplicity | Very simple on LAN | Medium | Simple for a camera | Very simple | Simple on the playback side | Simple on a managed network |
| Security | Varies by config | Very good with AES | Varies | Good in RTMPS | Good over HTTPS | Weak: no encryption |
These ratings are common-use guides, not absolute measurements: real performance depends on the codec, the settings, the hardware and the quality of the network.
A local control room with several video sources on the same network
NDIA reliable video link between two sites, over the internet
SRTAccessing the stream of an IP camera
RTSPSending a programme to YouTube, a CDN or an event platform
RTMP / RTMPS (RTMPS preferred)Delivering to web or OTT viewers
HLSDistributing a stream on a managed network, in unicast or multicast (internal IPTV, dedicated link)
TS over UDP (RTP as a variant)The bottom line
The confusion comes from calling everything "streaming", when these technologies do not work at the same level. In practice: NDI is for producing, SRT for transporting, RTSP for accessing a camera stream, RTMP for publishing to a platform, HLS for delivering to viewers, TS over UDP for distributing on a managed network.
And to read any spec sheet: the codec is the compression; the container is the packaging; the transport is the delivery.
AV control protocols
The control counterpart to this page: VISCA, OSC, NDI PTZ, ONVIF and the other protocols that command the machines.
Read the guideUnderstanding NDI
The basics of the IP video protocol: High Bandwidth / HX variants, network sizing, examples.
Read the guideNDI vs SDI
Baseband or IP transport: which backbone to choose depending on the production context.
Read the articleLive production software
vMix, OBS, mimoLive, Wirecast: the software control rooms that leverage NDI, SRT and RTMP.
Read the articleLet's talk about your video chain.
Protocol choice, network sizing, remote contribution, suitable hardware: the HoriCast team supports integrators and end users in France.
Contact us