With the release of Cablecast 7.1 the network streaming capabilities of the Flex and VIO server's are greatly expanded. With version 7.1 it is now possible to play out live network streams from a variety of sources including RTP, RTMP, RTSP, HLS, YouTube Live, and NDI. This article will provide an overview of each supported stream type as well as instructions for creating streams and playing them as both scheduled events and manually using force events.

The Network Streams feature is included in Cablecast 7.1 with out any additional licensing. However a VIO or Flex video server is required for these features.

Protocols versus Codecs

Before diving into the different streaming protocols Cablecast 7.1 supports, it's important to make clear the difference between a streaming protocol and the encoding of the audio and or video the stream is carrying. Described in this article is primarily networking streaming Protocols. Protocols define how the stream is transmitted across the network and sometimes how the client and server initiate a session. Containers or transport formats describe how the data is divided into streams, segmented and sent over the network and usually contains metadata about the compressed audio and video within. For our purposes the most common container is MPEG transport stream used with the RTP and HLS protocols. Finally CODEC describes how the raw audio and video streams are compressed While some protocols such as HLS and RTMP are fairly strict in the types of containers and codecs they can carry, other streaming protocols such as RTP are much more flexible. For use in Cablecast we recommend the following encoder settings.

Protocols

RTP

Overview

RTP or Real-time Transport Protocol is a commonly supported protocol used for delivery of audio and video streams over IP networks. RTP usage is not limited to video streaming, in fact my IP based telephone systems use RTP for media delivery. RTP supports both unicast (one to one) and multicast (one to many) delivery. The multicast support specifically makes RTP an efficient choice when you have multiple locations that want to receive the same network streams on the same network.

Network Considerations

Plan your network carefully when using multicast. In particular multicast of audio / video over a wifi network can greatly reduce network performance.

RTP is sent over IP networks using UDP (https://en.wikipedia.org/wiki/User_Datagram_Protocol). Differing from TCP there is no confirmation that a UDP packet is delivered. This is commonly referred to as fire and forget. This makes delivery of RTP more efficient, allowing for higher data rates and lower latency than would be achievable using TCP (https://en.wikipedia.org/wiki/Transmission_Control_Protocol) protocol. This makes RTP less suitable for networks that may experience high rates of packet loss, such as over the public internet.

Using RTP the connection is initiated by the encoder. This requires the encoder to be able to reach the Cablecast video server. Any firewalls between the encoder and the video server need to be configured to accept inbound traffic and the port the RTP traffic is being delivered on. Further the RTP port must be an even number (e.g. 4444, 4446). Odd number ports are reserved for RTCP (RTP Control Protocol) (https://en.wikipedia.org/wiki/RTP_Control_Protocol).

Cablecast Specifics

For use in Cablecast the RTP stream must contain a MPEG Transport Stream containing audio and video matching the above defined encoder settings.

Summary

When To Use: Local Area Networks and I-nets.

When to Avoid: Bad networks / internet.

Pros: Low latency, very common

Cons: Packet Loss, Network Configuration

RTSP

RTSP or Real Time Streaming Protocol is a protocol designed for controlling media servers. It uses VHS style commands such as PLAY and Record so that a client can control media operations, the client in this case being the Cablecast video server. Transmission of the audio and video itself is not accomplished by RTSP, but is instead delegated to RTP.

Network Considerations

With RTSP the client or Cablecast video server initiates the connection with the RTSP server or encoder. This requires that all firewalls between the Cablecast video server and RTSP encoder allow inbound traffic on the RTSP port. The default port for RTSP 554 but can be configured to an alternate port depending on your RTSP encoder.

RTSP has the ability to fall back to embedded TCP for transmission of audio video data if the client and server are unable to negotiate a UDP port for RTP transmission. This is the most likely scenario if your cablecast video server is behind a firewall. Note however that some servers may not implement the interleaved fallback in which case the RTSP stream would likely timeout and fail.

Summary

When To Use: When remote location has static IP and RTSP server can be poked through firewall.

When to Avoid: When remote location is unknown.

Pros: Low latency, very common, can work around firewalls better then RTP

Cons: Packet Loss, Network Configuration

RTMP

RTMP or Real Time Messaging Protocol was original developed as prosperity protocol for streaming video and audio over the internet. Adobe acquired the protocol and released an incomplete specification. While having many short comings, RTMP is widely adopted making it one of the most common protocols for network streaming. Most popular video streaming services such as Twitch, YouTube, and Facebook all accept RTMP as ingest protocols and therefore many off the shelf and open source encoders exist with RTMP support.

Network Considerations

There are three roles in a typical RTMP streaming session.

• Encoder - Encodes the audio / video and pushes it to the RTMP server
• Server - Receives RTMP streams from the encoder and pushes it to connected clients.
• Client - Requests RTMP streams from an RTMP server

Using RTMP in Cablecast 7.1 requires a third party RTMP server such as CablecastRTMP , Wowza or Nginx RTMP.

In the diagram above the Cablecast VIO or Flex server acts as the client and the AJA HELO (https://www.aja.com/products/helo) acts as the encoder. Streaming RTMP from the encoder to the client VIO server requires a third party RTMP server.

• CablecastRTMP (https://www.cablecast.tv/solutions/cablecast-rtmp)
  • Subscription based
  • Pairs well with Cablecast
  • Easy to setup and use
  • Cloud based (no hardware)
  • Can simulcast to Facebook and YouTube

Beyond that, the two widely used RTMP servers are

• Wowza (https://www.wowza.com/)
  • Closed source non-free
  • Does much more then rtmp
• Nginx RTMP (https://github.com/sergey-dryabzhinsky/nginx-rtmp-module)
  • RTMP module for open source Nginx web server
  • OBS has a good article on building on a Raspberry Pi (https://obsproject.com/forum/resources/how-to-set-up-your-own-private-rtmp-server-using-nginx.50/)

The benefit of RTMP is that it is a fairly lightweight protocol that uses TCP. Unlike UDP TCP guarantees packet delivery with acknowledgements and re-sending of lost packets. This makes it a great option for delivery over the public internet where packets may may be lost.

Another benefit and potential pain point is the requirement of a third party RTMP server. While this complicates initial setup it also allows for the RTMP server to be located on the public internet or in the cloud. This is ideal for situations where neither the encoder's location, or the client's location can be configured for RTP or RTSP support.

In situations where the RTMP server will be located behind a firewall care must be taken to allow inbound traffic to the TCP port the server is listening on. The default port for RTMP is 1935 but can be configured to use a different port in most server software.

Summary

When To Use: Over the public internet when neither encoder or client location network configuration can be modified.

Pros: Very common, requires no network configuration when RTMP server is in cloud. Commercial supported RTMP services available.

Cons: Higher latency, requirement of third party server.

HLS - HTTP Live Streaming

HLS or Http Live Streaming (https://en.wikipedia.org/wiki/HTTP_Live_Streaming) is a protocol developed by Apple to stream live and video on demand to iOS devices. Because it is the only supported protocol for live streaming to Apple devices, it is very common. HLS is what is commonly referred to as a distribution protocol / format. It is generally used to deliver video and audio to the viewer. It uses common HTTP servers and content distribution networks to allow it to scale very well to millions of concurrent viewers.

HLS is generally very high latency, meaning that the video and audio might be delayed by as much as 60 seconds from the time it was captured until a client sees it on their screens. However because of how common HLS is, it can be very convenient to be able to pull in an HLS stream into Cablecast despite the increased latency. For example some streams we have seen available as HLS are:

• Other Cablecast Systems
  • Cablecast Live outputs an HLS stream which could then be played out on your Cablecast Channel
• Free Speech TV
• Classic Arts Showcase

It is important when re-broadcasting live streams to get express written permission from the content's copy right holders. For that reason we don't include stream links for any of the above streams.

Another benefit of HLS is support for ABR or adaptive bitrate streaming. ABR allows for the client to choose different stream qualities depending on screen size and available bandwidth. While we recommend using network streams in Cablecast on fast reliable connections, this can help if your Cablecast's systems bandwidth is limited.

Network Considerations

HLS is served over standard TCP HTTP connections usually with port 80 being http (non-secure) and port 443 https (secure). Your Cablecast system will access the stream using those ports and any firewall in front of the server providing the HLS stream needs to have the appropriate firewall rules in place to allow the inbound connections. Because HLS is primarily a distribution protocol, most HLS streams have the appropriate firewall rules in place.

When using https to deliver HLS it is appropriate that they HLS be served using valid https certificates. Self signed certificates will cause the stream to fail to play.

Summary

When To Use: Over the public internet when desired stream is already available via https

When To Avoid: When low latency is required.

Pros: Very common, usually no special network considerations.

Cons: High latency

YouTube Live (BETA)

YouTube live is YouTube's live streaming solution. It allows YouTube channel owners to setup live streams for viewing on the YouTube platform. YouTube live accepts RTMP stream for ingest and is compatible with many commercial and open sources encoders. Because many station operators are already sending their content to YouTube, being able to pull that content back into Cablecast for broadcast on the cable channel is useful.

Rebroadcasting YouTube streams is against YouTube's terms of service. When possible it is preferable to simulcast to both YouTube and Cablecast independently. YouTube may change their APIs or break this feature at any time.

Network Considerations

Cablecast's YouTube Live support works by analyzing the YouTube page to retrieve the HLS stream that YouTube provides for a live event. In order for Cablecast to retrieve the HLS url the YouTube account owner must allow embedding of live streams as shown in the screen shot below. At this time the "Embed Live Streams" options is only available in the "Classic Creator Studio"

Summary

When To Use: When you are already broadcasting to YouTube and you have limited bandwidth at encoder site.

When To Avoid: When it's not your content.

Pros: Easy to use / setup. No special network considerations.

Cons: Not officially supported by YouTube, could break at any time.

SRT

Cablecast 7.5 introduces support for SRT network streams. SRT is an open source video transport protocol that is optimized for unpredictable networks such as the internet. SRT support is currently in technical preview, meaning the setup, configuration, and final features of SRT support may change as we receive feedback from real world testers utilizing SRT in the field.

Please see our additional KB on SRT here: https://support.cablecast.tv/s/articles/technical-preview-srt-streams-in-cablecast-75

NDI

NDI or Network Device Interface is a protocol developed by NewTek that enables easy discovery and delivery of broadcast quality IP Video over a standard gigabit LAN. The protocol is made freely available by NewTek leading to wide adoption by various software and hardware products.

Network Consideration

NDI was designed to be used on a Local Area Network and uses a discovery feature to allow all devices to recognize the source as an option to use.

Summary

When to Use: NDI compatible devices are already available on the network.

When to Avoid: Slow network conditions such as slow link between two LANs.

Pros: Low Latency, High-quality, Can use sources like Tricaster

Cons: Not meant for using over the internet

Using Live Streams In Cablecast

Using a Network Stream in Cablecast is easy. Streams can ether be scheduled like any other show or forced live from the force matrix.

Creating The Stream

1. Navigate to Settings -> Location Settings -> IO (Tab) -> Network Streams and click New.
2. Give the stream a Name, select its Type and enter in the stream URL.
3. Click Save

Schedule A Network Stream

Initial Setup

In order to schedule a Network Stream a few steps must be completed before hand.

1. You must have a Network Stream format created
   1. Located in Settings -> Location Settings -> Shows (Tab) -> Formats
2. Each of your video server devices must have the Network Stream format added as one of the three format options.
   1. Located in Settings -> Location Settings -> I/O (Tab) -> Devices -> (Your Device)

Creating The Show

With the above settings in place you can now create a show using the Network Stream format and choose the desired network stream. When the show is scheduled Cablecast will switch to the network stream.

Scheduling Network Streams is recommended for streams that are always on or that reliably start before the scheduled broadcast. If the stream is not yet started the initial playback may timeout.

Forcing A Network Stream

From the Cablecast Force Matrix one can force a Network Stream live using the Play Stream action.

Recording A Network Stream

This process has changed in Cablecast 7.2. See this article for specifics.

https://support.cablecast.tv/s/articles/setting-up-cablecast-to-use-network-stream

If running Cablecast 7.1 follow these steps:

https://support.cablecast.tv/hc/s/article/360042123951-Recording-A-Network-Stream-In-Cablecast-7-1

Timeouts Buffering and Error Handling

When cued, the video server will attempt to buffer a few seconds of video. If connecting to the stream, or buffering does not complete within 10 seconds the stream will timeout and an error will be displayed in the force matrix.