Drastic software supports a number of IP video standards in videoQC, Net-X-Code, FlowCaster and other products. To access these streams, a URL style string is used to describe them. For some sources, like RTSP, this string is fairly standard. For others, like NDI, a URL style has been developed to allow those streams to be specified. Currently, udp://, rtp://, srt://, rtsp://, ndi://, s2022:// and s2110:// are supported. This document describes the URLs' format in more detail. We have also added some application specific notes for connecting our software to other applications.
Basic IP Video URLs
An IP video URL will always start with the type of stream you are expecting. Some of the types include udp://, rtp://, rtsp://, ndi://, s2022:// and s2110://. This will be followed by an IP address or resolvable name for the address of the stream. For some streams there will be a port value, and then a description of the stream on that device. For videoQC, there is also a special form that can be used to launch videoQC, FlowCaster iOS Player or FlowCaster Android Player automatically from a browser link. For these, simply preface the link you want with videoqc:// and remove the extra colon from your link.
UDP and RTP
UDP [User Datagram Protocol] and RTP [Real-time Transport Protocol] streams can be elementary video or audio streams, or more commonly a transport stream with PMT/PAT (Program Association Table/Program Mapping Table) and a number of streams within it. For UDP and RTP, you can specify a TCP (direct) address, but normally it will be a multicast group address, and also a port is normally specified. Here are a few examples:
SRT [Secure Reliable Transport] streams contain a transport stream with PMT/PAT and a number of streams within it. For SRT you can specify an address and a port. There are three modes for SRT: listener, caller and rendezvous. If you are a listener, you can only connect with a caller and vice versa. For Rendezvous, both the sender and receiver must be in rendezvous mode. A password for encrypted service can also be set. Here is some information on the modes:
- listener - this has to be one of your local IP addresses, and acts as a server waiting for a connection, so it must be directly visible to the caller (not behind a firewall)
- caller - this calls out to a remote IP that is running as a listener. You must be able to reach the IP directly (e.g. no firewall)
- rendezvous - this connects bi directionally, allowing it to connect through firewalls without extra configuration. Each side of the rendezvous uses the external (internet facing) IP address of their internet connection. This allows the signals to connect and pass through the firewall
Here are a few examples:
Possible parameters include
RIST [Reliable Internet Stream Transport] streams are UDP based self correcting connections. RIST supports three profiles: Simple, Main, and Advanced. Both the sender and the receiver must be in the same mode. The receiver will be the server and listen for a connection. The sender will be the client and connect to the receiver to send the data. The protocol will use two ports, the lower of which is specified in the URL and the higher which is the lower plus one. The lower port must be even.
Here are a few examples:
Possible parameters include:
- mode: listener (for server/receiver), caller (for client/sender) - Required
- profile: simple. main or advanced
- password: encryption key
- buffering: amount of buffer in milliseconds
RTSP [Real Time Streaming Protocol] streams require not only the device address, but also the description of the source of the stream you are accessing on that device. RTSP are also often user/password protected, so you may have to send a user/password in the form "<user>:<pass>@" just before the device identifier. Here are a few examples, and their sources:
- rtsp://192.168.100.10/axis-media/media.amp (an Axis camera)
- rtsp://192.168.199.11/user:pass@/video1+audio1 (a Marshall camera, with password)
- rtsp://192.168.160.20:/onvif/media.amp (an OnVIF source)
- rtps://192.168.150:11/video1?videocodec=h264 (a Marshall camera, video only, force h.264)
RTMP [Real-Time Messaging Protocol] is normally used to stream one video and one stereo audio channel to a website for distribution to multiple watchers. In modern sites, the RTMP is actually re-wrapped into HLS, which is then viewed by the end user. To connect to an RTMP site, like flowcaster.live, youtube.com, and twitch.com, you will need the URL/Link and the key/secret. For youtube, they are available after you 'go live' as the Stream URL and the Stream Key. Once you have them, you simply add a slash and the Stream Key to the Stream URL. For example:
Stream URL: rtmp://a.rtmp.youtube.com/live2
Stream Key: j2bg-a6ck-8t48-w2y2-aaaa
Final URL: rtmp://a.rtmp.youtube.com/live2/j2bg-a6ck-8t48-w2y2-aaaa
WebRTC [Web Real-Time Communication] is a browser native method of sharing video, audio and data. It is primarily used in chat programs, like Google Meet. When sending via WebRTC, FlowCaster appears as a person in the chat, with whatever video and audio it is receiving being sent to the chat.
Here is an example:
WHIP (WebRTC - Millicast)
WHIP [WebRTC-HTTP ingestion protocol] is a simpler negotiation system for WebRTC. Currently in use by Millicast to receive streams for worldwide, low latency transmission, FlowCaster and Net-X-Code support sending video signals via WHIP. WHIP requires an auth code (available from the Millicast config pages) and a stream name. The stream name is added to the end of whip://director.millicast.com/api/whip/ and the auth token is a parameter that starts with auth=.
Here is an example
There is a great article and video on WHIP streaming from FlowCaster to Millicast available here:
BLS (Bliss Protocol)
BLS [Browser Live Stream] is a protocol developed by Drastic to send live video, via an encrypted channel directly to a user's browser. It allows for much higher quality video than WebRTC, while still not requiring any plugins or special setup to present audio and video directly in a modern, HTML5 browser.
Here are a couple examples:
NDI [Network Device Interface] is a new video over IP protocol from NewTek®. It requires a device name and a source name to access NDI sources. NDI sources may also be searched on the local network. To enable the search, run DDRConfig and select the Advanced tab. Go to /VVW/Config and change EnableNDISearch = 1. If it does not exist, then create a new Numeric value for it.
To specify an NDI stream, use the device name, followed by a space, and then the source name within brackets.
- ndi://USER-PC (Desktop )
- ndi://TestCameraSource (ISO_1)
- ndi://PC2 (Google Chrome )
CDI [Cloud Digital Interface] is an advanced, fully uncompressed, protocol for use within Amazon VMs. It transports video in a number of formats, as well as audio, time code and other metadata. While it is possible to use CDI with Amazon's enhanced network backbone, it is safest and most efficient, within their network stacks. The URL will include a local IP and port, with an optional remote IP, adapter and ID.
Here are some examples:
Possible parameters include:
- remoteip: a remote computer to connect to exclusively
- adapter: the transport, EFA (Elastic Fabric Adapter) or socket. EFA is the default.
- id: a numeric value to specify the stream
S2022 and S2110
The SMPTE 2022-6 and SMPTE 2110 protocols can be accessed via SDP (Session Description Protocol) or manual setup. To access an SDP source:
For some Drastic software, the source can be set up manually. For S2022, this is a single set of Source IP, Source Port, Destination IP, Destination Port and Interface address. One or any combination of these can be used to describe the source of the SMPTE 2022-6 stream, which contains all the video, audio and HANC/VANC channels. For SMTPE 2110, up to three sets of the same information are required to describe the video, audio and anc streams, which are all separate. A PTP (Precision Time Protocol) grandmaster may also be specified. Here is the configuration dialog from 4KScope:
videoQC URL/URI From Browser
videoQC supports being run from a browser, if installed on a Windows or macOS computer, with the special videoqc:// URL/URI. This will also work on Apple and Android devices with our FlowCaster Player apps (available free from the app store). In the case of videoqc://, it is not a protocol itself, but rather it loads the player and passes the rest of the protocol to it. So if you wanted an automatic link to bring up the srt stream: srt://239.100.30:31:1234?mode=caller&password=thisisapassword&user=thisisauser, you would add this to the videoqc:// start and remove its colon, as below:
Application Specific Notes
VLC (version 3.0.8 and greater)
VLC supports a number of streaming formats from the menu Media | Open Network Stream. Here you can read our UDP://, RTP:// and SRT://. If you are using multicast IP addresses (eg. 239.#.#.#), VLC prefers that you add an at sign (@) before the ip, like:
You can also use the @ sign to receive on any address using just the port:
For SRT, VLC only supports the being a 'caller', so our software needs to be set up as a listener. A typical setup would be
Assuming the IP 172.16.12.25 was the IP of the machine SMPTE2NET is running on.
OBS - Open Broadcast System
OBS supports UDP, RTP and SRT using its FFMPEG media reader. It will support both listener and caller modes in the latest versions (26.0.2 or greater). The reconnect is not 100% reliable, so if connection is lost, then you may have to open the source again to have it set up. To add a UDP, RTP or SRT source, click the + button in the Source panel and select MediaSource. In the Properties, unclick Local File, add the standard srt string, for listener or caller:
Set the input format to "mpegts" without the quotes, and set up the buffering and reconnect to taste.
Marshall and other Cameras
Most cameras we have tested operate as callers, so our software will have to be set up as a listener on the local IP the SRT stream is coming in on. Alternately, you can use the all addresses mode by using the 0.0.0.0 IP