SRT Encoder Guide
What SRT actually fixes, the one setting most installations get wrong, and which models ship with it
SRT — Secure Reliable Transport — is an open protocol for carrying video across networks you do not control. RTMP assumes the path is good enough and fails when it is not. SRT measures the path continuously and repairs it: the receiver reports which packets never arrived, and the sender sends them again. That single mechanism is why an SRT stream keeps moving across a public link where an RTMP stream would freeze and stay frozen.
This guide covers what an SRT encoder does, where it beats RTMP and where it does not, how to size the latency buffer, what carries it through a firewall, and which ORIVISION models publish SRT in their protocol set today.
1. What an SRT encoder is
The encoder does not change. The transport underneath it does.
The video path is the same as any other encoder
An SRT encoder captures the HDMI input and encodes it to H.264 or H.265 exactly as any other encoder does, then wraps the resulting stream in SRT packets instead of RTMP ones. Picture quality is decided by the encode settings. SRT decides whether those packets arrive intact.
It runs over UDP, with reliability rebuilt on top
SRT is UDP-based. TCP retransmission is far too slow for live video and its head-of-line blocking makes it unusable, so SRT builds its own acknowledgement and retransmission layer on UDP rather than inheriting the one that already exists.
It is a two-way session, not a one-way push
The receiver keeps telling the sender what it has and has not received. That feedback is what lets the sender retransmit only what is genuinely missing instead of re-sending everything. It also means both ends have to be SRT-aware.
It is a contribution protocol, not a playback format
A browser cannot play SRT directly and no consumer platform ingests it. SRT terminates at a decoder, a gateway or a media server. If the final destination is a web page, the server converts to HLS or another delivery format for the last leg.
2. SRT against RTMP and RTSP
Each protocol exists for a different part of the chain. Choosing the wrong one for a leg is the most common single cause of a stream that keeps freezing.
ORIVISION encoders publish several of these in one protocol set, so changing transport usually does not mean changing hardware.
| Protocol | Built for | Where it belongs | Its weakness |
|---|---|---|---|
| SRT | Lossy links with real latency | Contribution over the public internet, remote venues | Both ends must speak SRT |
| RTMP / RTMPS | Publishing to a platform | YouTube, Facebook and Twitch ingest | TCP-based; degrades sharply as packet loss rises |
| RTSP | Querying a stream locally | Camera integration, NVR, VLC | Not designed for long-distance public links |
| HLS / FLV | Distribution to many viewers | Web and app playback | Seconds of delay by design |
| UDP / RTP multicast | Many receivers on one network | Campus and in-house distribution | No recovery at all; assumes a clean network |
ORIVISION encoders list SRT alongside HTTP, RTSP, RTMP/RTMPS, HLS, FLV and UDP/RTP multicast in their published protocol set, so the transport is a configuration choice rather than a model choice.
3. Caller, listener and rendezvous
SRT has three ways to establish a session. Picking the right one removes most firewall problems before they start.
Listener
One side opens a UDP port and waits for the other to arrive. Use it on the side whose network you control and can configure.
Caller
The encoder dials a fixed address and port. This is the usual choice at a remote venue, because the encoder only has to make an outbound connection — no inbound rule is required at the venue at all.
Rendezvous
Both sides dial each other at the same time and the session still forms when neither end can hold an open port. Use it when both ends sit behind NAT but both can send outbound traffic.
The practical rule
Put the caller on the side you cannot configure and the listener on the side you can. In most contribution setups that means caller at the venue and listener on your own server or decoder.
4. Sizing the latency buffer
This is the setting behind most SRT complaints. Too small and the picture stutters; too large and you have added delay you did not need.
What the buffer is actually for
SRT holds arriving packets briefly so that a retransmitted packet can be slotted back into the right position. The buffer must be long enough to cover one round trip plus the jitter on the path, and no longer than that.
Measure the round-trip time first
RTT sets the floor. As a working starting point, set the latency to roughly three to four times the measured RTT, then reduce it while watching for visible stutter or dropped frames.
Two worked examples
On a link with 40 ms round-trip time, start around 120 to 160 ms. On a cross-continent path with 150 ms RTT, the same rule puts you at 450 to 600 ms. You cannot go below RTT plus jitter, and no setting changes that.
Latency is not bitrate
Raising the latency buffer will not improve picture quality on a link that is simply too thin for the bitrate you selected. Those are separate problems: fix the bandwidth first, then tune latency.
Where it is configured
SRT is configured on the encoder alongside the destination address and the encode settings. The same values have to be present at the receiving end, or the session will not establish.
5. Packet loss, retransmission and bandwidth
SRT repairs a link. It does not create bandwidth that is not there.
What ARQ does, in one sentence
The receiver reports which packets are missing and the sender sends them again. This is automatic repeat request, and it is the entire reason a lossy link becomes usable.
Retransmission costs headroom
Re-sent packets consume capacity on top of the video bitrate. A path dropping a few percent needs spare capacity above the stream rate, so do not design the link to run at 100 percent of its nominal throughput.
What SRT cannot fix
Sustained loss well beyond what the configured buffer and recovery can absorb, or a link that is over-subscribed for minutes at a time. In those cases the answer is a lower bitrate or a more efficient codec. SRT is a repair mechanism, not a substitute for bandwidth.
Bonding is implementation-dependent
SRT includes a socket-grouping feature for using two network paths at once, but support varies between implementations and firmware versions. If your design depends on it, confirm it on the specific model before committing.
6. Encryption and firewalls
The security half of the name is real, but it is narrower than it sounds.
AES encryption is optional and shared
SRT supports AES-128 and AES-256 with a passphrase set at both ends. It protects the payload in transit. It is not a replacement for a VPN on a network you consider hostile.
One port, both directions
A single UDP port carries the session, which is markedly easier to permit than the multi-port, connection-oriented rules some other transports need.
Bandwidth control prevents self-inflicted loss
SRT can be told the maximum rate the sender may use. Set that to the real available throughput of the link rather than to the video bitrate alone, or the encoder will end up competing with its own retransmissions.
Keep both ends on NTP
If the two ends disagree about time, session setup can fail intermittently in ways that are hard to attribute. Time sync at both ends removes a whole class of confusing faults.
7. Which ORIVISION encoders support SRT
Every model below publishes SRT in its protocol set. Bitrate is the configurable range quoted on the product page, not a recommendation for your content.
| Model | Inputs | Encoding | Bitrate range | Notes |
|---|---|---|---|---|
| ZY-EH1304 | HDMI 1.4 × 4 plus 4 audio | H.265 / H.264 / MJPEG | 16 kbps – 12 Mbps | Four streams per channel, 16 in total; 1000M RJ45; HDCP 1.4 |
| ZY-EH1301 | HDMI × 1 with loop-out | H.265 / H.264 / MJPEG | 16 kbps – 20 Mbps | Up to 4K@30Hz; ONVIF and GB28181; PoE optional |
| ZY-EH1401 | HDMI × 1 with loop-out | H.265 / H.264 / MJPEG | 16 kbit/s – 16 Mbit/s | Up to 4K@30Hz; LCD shows IP address and status |
| ZY-EHP1414 | HDMI × 4 with 4 loop-out | H.265 / H.264 / MJPEG | 16 kbit/s – 16 Mbit/s | 1U rack chassis, 485 × 200 × 45 mm |
| ZY-EH1308 | HDMI × 8 plus 8 audio | H.265 / H.264 / MJPEG | 16 kbit/s – 16 Mbit/s | Two RJ45 ports; up to 4K@30Hz |
| ZY-ES1401 | SDI × 1 with loop-out | H.265 / H.264 / MJPEG | 16 kbps – 20 Mbps | For SDI camera sources; LCD status display |
| ZY-EHV1401 | HDMI × 1 and VGA × 1 | H.265 / H.264 | 16 kbit/s – 20 Mbit/s | One device covering both HDMI and VGA sources |
| ZY-EV1201 | VGA × 1 with loopback | H.265 / H.264 / MJPEG | 16 kbps – 20 Mbps | For legacy equipment with VGA output only |
| ZY-EH311 | HDMI × 1 with loop-out | H.265 / H.264 | 16 kbit/s – 12 Mbit/s | Compact 1080p@30Hz unit; web configuration |
FAQ
Related guides
Live Streaming Encoder Guide
From a single camera to a 16-channel rack: protocols, bitrate and interfaces explained before you choose a model
H.265 HDMI Encoder Guide
Where HEVC earns its keep on an HDMI encoder, where it costs you, and how to check what your encoder is really sending
4, 8 and 16-Channel HDMI Encoder Guide
Choose the channel count by counting streams, then size the network before you choose the chassis
Not sure whether your link needs SRT?
Tell us the two endpoints, the measured round-trip time and the packet loss you are seeing, and our engineers will tell you whether SRT will fix it and which model to use.
HDMI video encoder models — compare channels, inputs and protocols across the range.