Cinegy supports a number of IP video standards in our IP-enabled products. 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.

RTP and UDP

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

rtp://<StreamIP>:<Port>/?serviceId=<ProgramPid>&videoPid=<VideoStreamPid>&audioPids=<AudioStreamsPids>

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

where:

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.

Caution
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 the audio streams PIDs in the program divided by a comma (e.g. "audioPids=136,137").

Note
Setting the VideoStreamPid and AudioStreamsPids parameters is optional.

SRT

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 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 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.

Configuration

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.

Note
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 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:

srt://10.186.3.41:9000

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:

srt://0.0.0.0:9000

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.

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:

srt://1.2.3.4:8888/?pass=AAAAABBBBB

or

srt://1.2.3.4:8888/?serviceId=2001&videoPid=2110&audioPids=2120&pass=AAAAABBBBB

Note
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:

srt://1.2.3.4:8888/?latency=250

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.

Caution
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.