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:

• bls://10.0.0.234:5000
• blss://192.168.202.200:3000?password=kfiwgt84jsd&remoteip=120.32.54.6

BLS uses the port explicitly set. If there is no port set, it will use 80 for unencrypted and 443 for encrypted traffic.

  CDI

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:

• cdi://10.0.0.2:6000
• cdi://10.0.0.1:6000?remoteip=10.0.0.200&adapter=EFA&id=2

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

The implementation for this transit occurs over the Scalable Reliable Datagram (SRD) protocol. To achieve the highest performance and lowest latency, the AWS CDI SDK relies on EC2 instances that support the Elastic Fabric Adapter (EFA) and are placed within a single Placement Group.

The AWS CDI SDK opens one specified User Datagram Protocol (UDP) port per connection to control communication between Amazon EC2 instances running AWS CDI SDK. The receiving side listens on the specified port number. The transmitting side uses a random port number from the ephemeral port range, as determined by the operating system.

For network security best practices concerning how to block UDP packets from the public Internet, see Security best practices for your VPC.

The AWS CDI SDK also relies on EC2 instances using a Security Group that allows all inbound and outbound traffic to and from the Security Group itself. For more information, see Prepare an EFA-Enabled Security Group.

  HLS

HLS [HTTP Live Streaming] is an HTTP-based adaptive bitrate streaming communications protocol. HLS resembles MPEG-DASH in that it works by breaking the overall stream into a sequence of small HTTP-based file downloads, each downloading one short chunk of an overall potentially unbounded transport stream. A list of available streams, encoded at different bit rates, is sent to the client using an extended M3U playlist.

The standard also includes a standard encryption mechanism and secure-key distribution using HTTPS, which together provide a simple DRM system. Later versions of the protocol also provide for trick-mode fast-forward and rewind, and for integration of subtitles.

HLS Encoder: codify video files in H.264 format and audio in AAC, MP3, AC-3 or EC-3. This is encapsulated by MPEG-2 Transport Stream or MPEG-4_Part_14 to carry it.
HLS Segmenter: divides the stream into fragments of equal length. It also creates an index file that contains references of the fragmented files, saved as .m3u8.

  NDI

NDI [Network Device Interface] is a 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 [2])
• ndi://TestCameraSource (ISO_1)
• ndi://PC2 (Google Chrome [1])

If you are creating an NDI stream, with FlowCaster or Net-X-Code Server, for instance, only the stream name is specified.  The Computer name is added automatically by NDI, and you cannot use brackets in the name

• ndi://FlowCasterOut
• ndi://SDI1Out
• ndi://SMPTE2110_Group1

NDI uses a range of TCP ports: NDI ports 49152 to 65535

RIST

RIST [Reliable Internet Stream Transport] streams are UDP based self correcting connections.  Drastic currently supports the following RIST profiles:  Simple, and Main. Simple Profile provides ARQ (automatic repeat request) for packet loss recovery, jitter removal, optional FEC (forward error correction). The Main Profile adds encryption for secure content.

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:

• rist://10.0.0.123:5000?mode=listener&profile=main
• rist://192.168.1.22?mode=caller&profile=simple

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

When using the 'listener' mode, the port it is listening on must be open in the firewall. For Caller, it should work without firewall adjustment.

  RTMP

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

For sending, RTMP should work without firewall adjustment. RTMP uses port 1935

  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:

• udp://239.254.40.40:5004
• rtp://239.100.20.20:50004
• rtp://239.100.30:31:1234

This is a server protocol on the receiver, and requires the selected port to be open to receive. On the send side, it should work without firewall adjustment.

  RTSP

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)

RTSP uses port 554

  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:

• s2202://192.168.101.200/channel1.sdp
• s2110://mainsources.drastic.ca/crosspoint10.sdp

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 SMPTE 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 are the configuration dialogs from 2110Scope:

  SRT

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:

• srt://239.254.40.40:5004?mode=listener
• srt://172.12.25.20:5006?mode=caller
• srt://239.100.30:31:1234?mode=caller&password=thisisapassword&user=thisisauser

Possible parameters include

• mode=
  • caller
  • listener
  • rendezvous
• password=<string>
• keylen=16|24|32
• username=<string>
• streamid=#
• latency=#
• buffering=#
• maxbw=#

When using the 'listener' mode, the port it is listening on must be open in the firewall. For Caller and Rendezvous, it should work without firewall adjustment.

  WebRTC

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:

• webrtc://flowcaster.live?meetingid=asre-dsec-asds-seff&name=flowcaster

WebRTC uses a bunch of standard ports:

• Access to ports TCP + UDP 4443, 3478, 443 for www.flowcaster.live
• Access to video streaming services in VPN and Firewall settings
• Ports used: 80, 443, 4443, 3478 (TCP and UDP), 5349 TCP, 40000:65535 UDP

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:

videoqc://srt//239.100.30:31:1234?mode=caller&password=thisisapassword&user=thisisauser

ST-2110/2022 uses the port(s) set by the caller.

  WHIP (WebRTC - Dolby.io)

WHIP [WebRTC-HTTP ingestion protocol] is a simpler negotiation system for WebRTC.  Currently in use by Dolby.io to receive streams for worldwide, low latency transmission, FlowCaster and Net-X-Code Server support sending video signals via WHIP.  WHIP requires an auth code (available from the Dolby.io 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

• whip://director.millicast.com/api/whip/kwky3g6g?auth=48ce3daa09cd8355f80fc0d37005f9422a62bebf9b6411b61cfb1cfb2fa

WHIP uses a bunch of standard ports:

• Access to ports TCP + UDP 4443, 3478, 443 for www.flowcaster.live
• Access to video streaming services in VPN and Firewall settings
• Ports used: 80, 443, 4443, 3478 (TCP and UDP), 5349 TCP, 40000:65535 UDP