SRT Protocol: Encoders, Decoders and Reliable Video Transport
SRT carries media between compatible IP endpoints and provides mechanisms to recover missing packets and manage delivery timing. It is a transport layer for a video workflow; codec compatibility, network reachability and total latency remain separate design requirements.
What SRT Adds to a Video System
Secure Reliable Transport is an open-source protocol used for professional contribution and other IP media workflows. It operates over UDP and can carry compressed video/audio without changing the codec. The endpoints need a mutually supported payload format as well as an SRT implementation.
Its transport mechanisms address packet loss and timing variation. Missing packets can be requested again using automatic repeat request (ARQ). Recovery remains constrained by available time and capacity: a packet that arrives after the useful delivery deadline cannot restore a frame already presented.
Recovery has a budget
SRT cannot create bandwidth or make a prolonged outage disappear. The path must carry the media, protocol overhead and required recovery traffic within the chosen timing budget.
Follow the Media and the Return Path
-
Prepare
- Capture and encode
- Or ingest an IP stream
- Match the payload format
-
Send
- Establish the session
- Send media packets
- Retain data for recovery
-
Transport
- Forward media path
- Return control traffic
- Variable delay and loss
-
Receive
- Reorder and buffer
- Request missing packets
- Decode or forward media
Conceptual transport sequence. Control and recovery traffic returns from the receiver to the sender; the network must support the required two-way communication.
An SRT encoder starts with a source such as HDMI or SDI. An SRT decoder reconstructs a supported video/audio output. An SRT gateway can terminate the session and forward the compressed content through another IP transport. These are different device roles even when all use SRT.
Connection Roles and Media Direction
| Connection role | Behaviour | Network consideration |
|---|---|---|
| Caller | Initiates a connection to a remote address and port. | The remote listener must be reachable through the relevant routing, NAT and firewall rules. |
| Listener | Waits for an incoming connection. | Confirm the listening interface and permitted UDP traffic. |
| Rendezvous | Both peers participate in coordinated connection establishment. | Support and NAT behaviour must be verified; it is not a universal firewall bypass. |
Caller and listener describe connection establishment, not the direction of video. Depending on the implementation, a sender or a receiver may initiate the session. Agree the role, endpoint address, UDP port and any application-specific Stream ID with the remote operator.
Encryption is available in SRT, but must be configured and verified on both ends. Matching credentials and supported settings are required. The SRT label alone does not establish an encrypted connection, secure management access or a complete security architecture.
Decoder or Gateway at the Receiving End?
A · Encoder → SRT → decoder
Use this path when the receiving equipment needs HDMI, SDI or another supported baseband output. Match video/audio formats and output timing to the downstream system.
B · Encoder → SRT → IP gateway → LAN
Use a compatible gateway when received media should remain compressed and feed a managed distribution network. This avoids an unnecessary decode-and-re-encode step when the formats already match.
C · Existing IP stream → SRT gateway → receiving site
A protocol gateway can adapt an existing stream for the WAN path. If codec or resolution changes are required, add a verified transcoding function.
Plan and Validate the Complete Link
Specify the target end-to-end delay, expected path variation and acceptable service interruption. Test with representative content and network loading. A stable office connection during commissioning may not represent the operating environment at an event or remote site.
Measure encoder, transport and receiver contributions separately where possible. Observe round-trip time, loss, retransmissions, receive-buffer behaviour and destination continuity. Increase buffering only with an understanding of the resulting application delay.
- Confirm the exact codec, payload and audio format at both endpoints.
- Agree connection roles, reachability and authentication before the event.
- Check usable path capacity in both required directions.
- Validate stream restart and receiver recovery after a brief interruption.
- Check whether any optional SRT features are implemented in the actual device firmware.
Do not assume optional capabilities
Protocol-level support for features such as bonding does not prove that a particular encoder, decoder or gateway implements them. Product selection must follow the model documentation.
Where SRT Fits
SRT is principally a contribution and transport tool in this context. Large audiences normally require a distribution stage sized for the viewer population. Sending a separate session to every viewer changes the capacity requirement and should not be confused with LAN multicast.
Relevant BLANKOM Building Blocks
Use the selected product page’s Data Sheet and User Manual to verify model-specific interfaces, capacities and firmware functions. Send your requirements to IRENIS for a configuration matched to your project.
BLANKOM device licensing is lifetime, with no recurring BLANKOM licence fee or mandatory SLA. Third-party services and optional system components have their own commercial terms; the supplied configuration should state what is included.
For the broader system context, see What Is IPTV? and the Technical Library.
Frequently Asked Questions
Does SRT reduce the encoded bitrate?
No. Transport conversion does not change video compression. Recovery and protocol traffic may increase the network capacity needed.
Does SRT always eliminate packet loss?
No. Recovery depends on the available time, path capacity and loss pattern.
Must the encoder always be the caller?
No. Connection initiation and media direction are separate; confirm the roles supported by both devices.
Is an SRT stream automatically encrypted?
No. Configure compatible encryption settings and verify their use on the actual session.
Technical and Product References
Define the Signal Chain Before Selecting Equipment
Send the information below so IRENIS can identify appropriate BLANKOM products and any compatibility checks needed for your system.
© 2026 IRENIS GmbH. All rights reserved. Unless otherwise stated, the original text, diagrams, tables and illustrations in this publication are protected by copyright. Except where permitted by applicable law, they may not be reproduced, republished, distributed, translated, adapted or used commercially, in whole or in part, without the prior written permission of IRENIS GmbH. Any permitted quotation or reference must clearly identify IRENIS GmbH as the source and, for online use, include a link to the original publication. Third-party trademarks and credited materials remain the property of their respective owners.
Original publication: SRT Protocol: Encoders, Decoders and Reliable Video Transport
