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:
|For the UDP URLs the resource type is "udp://".|
StreamIP – defines the stream IP in the following format:
It has the following meaning:
SourceIPis specified, unicast streaming from this IP will be used.
MulticastIPis specified, the stream from this multicast group will be used, from any source.
MulticastIPare specified, the only source defined by
SourceIPfrom the specified multicast group will be used.
MulticastIPis 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 the 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 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.
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.
|Caller and listener modes should only be used in pairs, regardless of where they operate (transmit / receive).|
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.
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.
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 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.