Cinegy supports a number of IP video standards in our IP-enabled products. In order to access IP streams, an URL style string is used to describe them. Usually this URL is generated automatically, but sometimes for various reasons you may need to change this manually.

This document describes the URLs' format in more detail.

An IP video URL will always start with the type of stream you are expecting. Currently, rtp://, udp:// and srt:// are supported.


The RTP URL format description is given below in the general structure:


For the UDP URLs the resource type is "udp://".


StreamIP – defines the stream IP in the following format: [SourceIP][@MulticastIP].

It has the following meaning:

  • If only SourceIP is specified, unicast streaming from this IP will be used.

  • If only MulticastIP is specified, the stream from this multicast group will be used, from any source.

  • If both SourceIP and MulticastIP are specified, the only source defined by SourceIP from the specified multicast group will be used.

  • If neither SourceIP nor MulticastIP is specified, data will be received from any source (i.e. sending it to the specified port).

Port – defines the port that will be used for streaming.

Port 8888 is the default service port used for connection with the Channel Directory Server; it cannot be used as a user-defined service port.

ProgramPid – defines the program PID that will be used. If this parameter is not specified, the first program found in the stream will be used.

VideoStreamPid – defines the video stream PID in the program. If none is specified, the first available video stream PID will be used.

AudioStreamsPids – defines audio streams PIDs in the program divided by a comma (e.g. "audioPids=136,137").

Setting the VideoStreamPid and AudioStreamsPids parameters is optional.


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 a perfect technology for people looking to move into the cloud, or to reduce the footprint of multicast streaming around a datacenter 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 the 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 and Cinegy Capture 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 dependent on the IPv4 address contained within the URL.

Caller and listener modes should only be used in pairs, regardless of where they operate (transmit / receive).

Caller Mode

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


In this case, an application requesting or sending the stream will reach out to the specified address and request that an SRT connection is made to the 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 the Cinegy Air engine or Cinegy Multiviewer over Wi-Fi or LTE, for a short confidence check of that output.

A further example is that the Cinegy Playout engine can be a caller into Cinegy Multiviewer and, conversely, Cinegy Multiviewer can be a caller into the Cinegy Playout Engine. In both scenarios the video data will always flow from the Cinegy Playout engine to Cinegy Multiviewer.

Listener Mode

In listener mode, a device waits for a request to open the SRT connection. The listener device waits for SRT requests on a certain port on either a specific or all network adapters. The URL for listener mode to use all local adapters will be:


Whereas, if the application needs to listen on a specific local address, simply replace the IP component with that of the desired network adapter.

In this case, the application listening will accept the first valid SRT connection sent to UDP port 9000. This allows a listener to wait for a calling device to choose to make a request, allowing the said application to wait in a configured state while the caller is set up or adjusted later. This is useful for defining the listener that can retain a static configuration at runtime while callers are altered, for example allowing Cinegy Multiviewer to listen for incoming streams from a mobile device or uplinked studio.

SRT Encryption

Cinegy products support encrypted SRT streams and will automatically decrypt them for you on input with an SRT passphrase specified in the dedicated field for output streams and directly in the input stream URL as follows:




Please note that in accordance with SRT requirements, the passphrase length should be between 10 and 79 characters.

SRT Latency

SRT protocol supports the concept of a delay buffer that provides an operating window for lost packets to be recovered. The value could be zero, if using only forward-error-correction modes (zero retransmissions) or it could be up to a few seconds. The SRT communication protocol works by both parties of the exchange sharing the latency parameters required for the recovery window, where the highest value of the two is taken as the value that shall be used for the duration of the session.

When using SRT with Cinegy products, latency may be controlled on any stream receiver through adjustment of the 'latency' URL parameter. Any stream generator starts with a default latency value of 120 milliseconds, and this acts as the lowest value for SRT latency any session may use when a Cinegy product is the source.

The receiving device requests an explicit latency by expressing the desired milliseconds of delay in the SRT URL:


This allows receivers to have a different error correction buffer depending on circumstance – a LAN-connected device might leave latency at the default (unspecified), but a 4G-connected devices might request 300 ms from the same source.

Note that latency values in excess of 4000 ms are not tested and may cause problems.

Choosing what latency values are required is not simple, but should be at least 2x the RTT (round-trip-time) of the connection as a minimum. The RTT of the link can be estimated through use of tools like ping, or can be tracked through the SRT connection statistics exposed by the Cinegy Playout engine.