RTSP, RTMP, SRT, HLS or WebRTC: Which IP Video Protocol Should You Use?

The question is where the picture lands

Most protocol arguments start in the wrong place. They start by asking which protocol is best, and there is no answer to that, because the five protocols in common use on a hardware encoder were designed for five different jobs. The useful first question is narrower: what is on the receiving end, and who controls the network in between?

A stream that goes to a recording server on the same switch has almost nothing in common with a stream that crosses the public internet to a CDN, or one that has to appear in a browser without a plugin. Those three destinations pull you towards three different answers, and once the destination is fixed the remaining choice is usually between two protocols rather than five.

What makes this a hardware question rather than a software one is that a hardware encoder is a fixed point in the system. It is installed, powered and left alone; it has to be configured once and stay correct. So the practical aim is to pick the protocol set at commissioning, not to revisit it.

What each protocol was built for

Protocol	Designed for	Transport	Typical use
RTSP	Controlling a stream, not carrying it	Usually RTP over UDP; can be interleaved over TCP	LAN viewing, NVR/recorder ingest, VLC and player access
RTMP / RTMPS	Ingest into a streaming platform	TCP	Publishing to a public platform or a media server
SRT	Reliable delivery over an unpredictable network	UDP with ARQ retransmission and optional AES	Site-to-site contribution links, bonded or cellular uplinks
HLS	Delivery to ordinary HTTP clients at scale	HTTP over TCP, segmented	Browser and set-top playback through a CDN
WebRTC	Interactive, sub-second, plugin-free	UDP (SRTP) with ICE/STUN	Two-way or operator-controlled viewing in a browser

Two of these are worth separating out because they are frequently confused. RTSP is a control protocol. It sets up and tears down a session; the media itself normally travels as RTP. When someone says "the RTSP stream is broken", the fault is usually in the RTP path, the UDP port range, or the network between — not in RTSP. The mechanism and its failure modes are covered in What Is SRT? for the SRT side, and the same reasoning about buffers applies across all of them.

RTMP is an ingest protocol. It exists because platforms accept it. That is a complete reason to use it and also its entire limitation: it is the right choice when the destination requires it, and a poor choice when you are free to choose. RTMPS is the TLS-wrapped variant; prefer it wherever the stream leaves your own network.

Latency: what each one costs

Latency is not a property of the encoder alone; it is dominated by the buffer the transport needs in order to do its job. Ranked from least to most delay, the ordering is stable across vendors:

• RTP/UDP under RTSP — minimal framing and no recovery buffer. Lowest delay, and no protection when packets go missing.
• WebRTC — built for interactivity. The ZY-EH1401 quotes approximately 300 ms for WebRTC transmission.
• SRT — in between, and the useful choice because its recovery buffer is configurable. You choose how much loss it absorbs and you pay for that in delay. On a clean path you can tighten it substantially.
• RTMP / RTMPS — more buffering than raw UDP, because TCP will retransmit and hold order. Correct when a platform requires it, not otherwise.
• HLS — the most delay, because it works by segmenting. That segmentation is exactly what makes it scale through ordinary HTTP infrastructure.

The decoder end matters as much as the encoder end. The ZY-DH901 is specified at under 200 ms, and matching decoder models across a site is worth more than optimising a single link. The full arithmetic, including encode, transport and display contributions, is set out in Latency Budget for IP Video.

One caution that saves callbacks: a large SRT buffer on a clean LAN buys nothing and costs delay. The buffer is insurance, and insurance should be sized to the risk, not maximised.

The public internet: loss and recovery

On a managed LAN, packet loss is close to zero and UDP-based delivery is reliable because there is nothing to recover from. Across the public internet, loss is the normal condition, and the question becomes how the transport handles it.

• TCP-based transports (RTMP/RTMPS, HLS) recover loss by retransmitting and holding delivery order. When a packet is lost, everything behind it waits. On a lossy link this shows up as stutter or a growing delay rather than as visible damage.
• SRT recovers by ARQ within a time budget. Packets that arrive too late to be useful are dropped rather than waited for, which is why it degrades gracefully instead of stalling. It also carries optional AES encryption, which matters if the content has to cross a network you do not own.
• Plain UDP does not recover at all. It is entirely appropriate on a LAN and entirely inappropriate across the internet.

That is the whole argument for SRT in one sentence: it is the only option in this list designed specifically for a path you do not control. Where the link is a VPN, a dedicated fibre or a switch you own, the argument weakens considerably.

Pull or push: who opens the connection

This distinction causes more failed installations than any other, because it determines which side needs to be reachable.

• Push — the encoder opens the connection outwards to a server. Only the encoder needs outbound access. This is how RTMP and RTMPS ingest works, and how SRT caller mode works.
• Pull — a client opens a connection inwards to the encoder. The encoder must be reachable, which means a route, a port and, in practice, a port forward or a VPN. This is how RTSP access from a player, and SRT listener mode, work.

SRT supports both roles — caller and listener — which is why it adapts to awkward network arrangements: whichever side has the reachable address takes the listener role and the other dials out. When a remote site has no inbound route at all, that flexibility is usually the deciding factor.

If several viewers on the same LAN need the same stream, this is also where the transport mode matters more than the protocol. One-to-many delivery inside a LAN should be carried as multicast rather than as many unicast copies; the switch behaviour required for that is explained in Multicast, Unicast and Broadcast Explained.

Firewalls, ports and the browser question

Two practical constraints settle most real designs.

What the firewall will let through. Anything over TCP on a conventional port passes easily because it looks like ordinary web traffic. UDP, and especially a UDP port range for RTP, is the thing that gets blocked — and when it is blocked, the symptom is a control session that connects and a picture that never arrives. If you do not control the firewall, prefer a TCP-based transport or SRT in caller mode.

Whether a browser has to play it. Browsers will not play RTSP or raw RTP, and RTMP playback in a browser has not been viable since Flash. That leaves HLS for one-way delivery to many viewers, and WebRTC where the viewing is interactive or operator-driven. If "open it in a browser" is a requirement, HLS or WebRTC is the answer and the rest of the list is not in contention.

What one encoder can output at once

The common assumption is that choosing a protocol means choosing one. It does not: a hardware encoder normally supports several simultaneously, and the useful design is to let each protocol do the job it is good at.

The ZY-EH1401 is specified with support for RTSP, RTMP, RTMPS, SRT, ONVIF, GB28181, RTP, UDP multicast, UDP unicast, FLV, HLS and WebRTC, and RTMP accepts username and password input. In practice that lets one unit feed a local recorder over RTSP, publish to a platform over RTMPS, and serve an operator over WebRTC at the same time.

The ceiling is stream count, not protocol count. Streams consume encoding and network resource, and the ceiling depends on resolution — the ZY-EH1401 runs four streams per channel at 1080P and one stream per channel at 4K. Multi-channel hardware scales the same way: the ZY-EH1304 takes four HDMI inputs and produces up to sixteen streams out of a single 1000M port, and the ZY-EH1308 takes eight inputs with two RJ45 ports so traffic can be separated.

Two protocols in that list are not general-purpose and should be understood as integration interfaces rather than delivery options: ONVIF and GB28181 are how an encoder registers with a video management or surveillance platform. If nothing in your system is asking for them, you do not need them; if a VMS is asking, they are the whole requirement.

Matching protocol to deployment

Deployment	Choose	Why
Recording or NVR on the same LAN	RTSP / RTP	Native to recorders and players, lowest delay, no recovery overhead needed
One-to-many screens on one LAN	RTP over UDP multicast	One copy on the wire; requires correct IGMP behaviour on the switch
Publishing to a public platform	RTMPS	What platforms accept for ingest, and encrypted in transit
Site-to-site over the internet	SRT	Configurable recovery buffer and optional AES on a path you do not control
Remote site with no inbound route	SRT in caller mode	Encoder dials out; no port forward required
Many viewers in browsers	HLS	Segmented HTTP scales through ordinary CDN infrastructure
Interactive operator control in a browser	WebRTC	Sub-second and plugin-free; around 300 ms on the ZY-EH1401
Integration with a surveillance platform	ONVIF / GB28181	Registration interface, not a delivery protocol

Where the far end is also ours, a decoder closes the loop. The ZY-DH931 is a H.265 4K decoder with an embedded RTMP server and an LCD screen, which is the arrangement that suits a site where the receiving end also has to serve local viewers.

Finally: decide the protocol set at commissioning and write it down. The failures that cost the most are not the ones where the wrong protocol was chosen, but the ones where nobody recorded which one was, and a change at the receiving end silently orphaned the stream.

Where to start

FAQ

Related reading

• What Is SRT, and Why It Beats RTMP on the Public Internet
• RTMP, RTMPT and RTMPS Explained
• Latency Budget for IP Video
• Multicast, Unicast and Broadcast Explained
• SRT Encoder: Latency, Packet Loss and Model Choice
• Live Streaming Encoder Guide
• H.264 vs H.265: Which Codec Should You Use?
• All Video Encoders
• Live streaming: encoder, protocol and path
• Broadcast and production video chain
• Security and surveillance video over IP