With the increase in public cloud adoption, and an ever more well-connected world to report from or hold events in, the arrival of an open technology that people can utilize to move signals around could not have been better timed. The technology we are talking about is an open-source video transport protocol.

With this protocol, you can get the benefits normally enjoyed from working with traditional MPEG Transport Stream based I/O but without the limits of multicast network configurations or worrying about packet loss with less reliable connections. This is the perfect technology for people looking to move into the cloud, or to reduce the footprint of multicast streaming around a datacentre or broadcast facility.

General Information

The Secure Reliable Transport protocol (SRT) allows broadcast video distribution encrypted across public networks. Created by Haivision and Wowza, when combined with Cinegy software, SRT offers remarkable low-latency performance and crystalline video clarity, irrespective of the distance between source and destination.

We at Cinegy were quick to see the potential of SRT and it is now integrated into all our IP-enabled products. Cinegy Air, Cinegy Route, Cinegy Multiviewer, Cinegy Capture and Cinegy Live all have the possibility to input or output SRT streams and Cinegy software snaps together into a cloud-based broadcast infrastructure in minutes.


The SRT protocol can act in two modes, as a caller or a listener, which differ dependant on the IPv4 address contained within the URL.

Caller Mode

In caller mode, a source or destination device acts as the initiator of an SRT connection. The caller device must know the public IP address and port number of the listener. The URL of the receiver in caller mode should contain the specific address of the source of SRT packets, for example:


In this case, the application receiving the stream will reach out to the specified address and request an SRT stream is sent to that calling application on UDP port 9000. Before the request, and in case the request is terminated or the connection is lost, no traffic will flow from the source to the receiver (unlike with a static unicast configuration where the sender continuously streams packets regardless of any receiver state). This is useful when defining and starting a new receiving operation without reconfiguration of a sender, for example a mobile device requesting the output of Cinegy Air Engine or Cinegy Multiviewer over Wi-Fi or LTE, for a short confidence check of that output.

Listener Mode

In listener mode, a device waits for a request to open the SRT connection. The listener device only needs to know that it should listen for SRT packets on a certain port. The URL of the receiver in listener mode, should not refer to any specific address as a source of SRT packets, for example:


In this case, the application receiving the stream will accept the first valid SRT streams sent to UDP port 9000. This allows a receiver to wait for a sending device to choose to send material to the input, allowing the receiver to wait in a configured state while the sender is set up or adjusted later. This is useful for defining the receiver that can retain a static configuration at runtime while senders are altered, for example allowing Cinegy Multiviewer to listen for incoming streams from a mobile device or uplinked studio.