How to manage live content delivery using Veset cloud playout platform

Introduction

Nothing can replace the viewing experience of a quality live streamed event. At the same time, this is also an exciting yet somewhat challenging proposal for broadcasters. It’s a great way to increase target audience’s interest and drive new revenue streams, however it is not trivial to do this from a technical point of view

We, at Veset, understand this problem and are relentlessly working on improving the live streaming capabilities of our Veset Nimbus cloud playout platform. This is why we’ve recently (2020) added extended support for multiple live feed inputs on our Linux-based playouts.

An added bonus of running playouts on Linux-based OSes versus Windows-based, is that the total cost of operation is – again – reduced. This is because Linux-based VMs in Amazon EC2 cloud are substantially cheaper to operate. There are also other exciting features available with Linux playouts.

These include:

1. Easier & quicker Docker-based deployment
2. Updating playouts are quick taking only several minutes
3. The overall encode/decode performance has been increased

Back to live events - This article explains the current live stream management functionality available in Veset Nimbus cloud playout platform (our flagship product). Nimbus is a product for professional live event broadcasting, for both traditional linear television and OTT (Over-The-Top) channels.

Technical overview

Veset Nimbus platform overview & datasheet: veset.tv/nimbus

Live functionality summary: Live signal feeds are directly received on redundant (1+1) playouts (e.g. AWS EC2 Linux-based machines) over a multitude of natively supported IP transport protocols –

• MPEG-TS over UDP / RTP;
• MPEG-TS over RTP-FEC (1-D, 2-D);
• RTMP (server PUSH, client PULL);
• Amazon MediaConnect (protocols – UDP / RTP, RTP-FEC, RIST, Zixi PUSH/PULL).

There are other protocols that are not supported natively but are implemented with the help of 3rd party products, namely SRT protocol (with Wowza Streaming Engine (SE) client), standalone Zixi protocol (with Zixi Broadcaster/Receiver/Feeder client products) etc.

Your choice of protocol depends on the location of the live feed signal source (internal AWS network, external source etc). There are separate tolerances as regards to reliability / packet loss for each protocol.

Up to 8 simultaneous live input feeds can be delivered per playout. The exact number depends on the AWS EC2 instance size used; instances can also be upscaled anytime to accommodate any additional feed requirements.

Switching to the appropriate live signal source on channels/playouts can be managed by either

• following scheduled playlist events – playlist-driven events; or
• manual operator switch to/from the chosen live signal feed.

Usage scenarios

There are multiple usage scenarios for live streaming events with Veset Nimbus.

The first one is a scenario where the live feed is sourced from a resource that is already located inside the same AWS network:

• There is a live feed whose source is, for example, AWS Elemental encoder or AWS MediaLive in the same VPC or AWS region.
• The live feed is the only live feed signal used (not multiple live feeds).

Veset Nimbus configuration for this usage scenario is relatively simple:

1. Add a new live input to each playout where you want this live feed to be available;
2. Choose a UDP port you would like to use, select RTP FEC protocol. Then push the live feed using the RTP-FEC protocol to the playout’s DNS name or IP address as shown in the Veset Nimbus UI.

In the next usage scenario, we can look at a live feed signals delivered to Veset Nimbus playouts over AWS MediaConnect:

• Live signal might be sourced outside of AWS internal network so a highly resilient transport solution needs to be used; in this case we’re using Zixi protocol.
• Feeds are first delivered to an AWS MediaConnect flow. Then, Veset Nimbus automatically creates flow outputs to its playout(s).

Veset Nimbus live input configuration is automated if you use the same AWS account for both AWS MediaConnect service and Veset Nimbus:

There is also a separate usage scenario for RTMP feeds. Although this is not as reliable as other reliability-focused transport protocols (Zixi, RIST, SRT etc.) it is still widely used for live feed delivery & transport. For RTMP live signal feeds you would be directly pushing them to the playout (RTMP PUSH/server type). Alternatively you can pull the live signal feeds (RTMP PULL/client type) from an RTMP server.

Veset Nimbus configuration example for both live signal feed input types:

Latency

Latency is always a concern when running live streaming events. In the case of a cloud-based playout, there is and always will be additional signal latency when compared to fully SDI workflows. This is due to the nature of this type of playout infrastructure. Veset Nimbus is no exception to this rule.

To summarize, the latency between a live event source and delivery to a head-end location can be split into the following parts:

• Latency of live feed signal transport to cloud (uplink to the cloud) – The exact latency is usually measurable and can be managed with the use of low-latency IP signal transport technologies like Zixi or RIST. A good rule-of-thumb average here would be 2-4s.
• Latency of the playout itself – Veset Nimbus adds additional latency due to the fact that the signal needs to be decoded, then encoded again. In the grand scheme of things this is negligible – usually less than 1 second total.
• Latency of playout output reaching head-end location (downlink from the cloud) – Similarly to uplink, this depends on the IP protocol chosen, but the same numbers of 2-4s apply here, also.

So, in comparison to traditional SDI-based workflows the live latency added is circa 4 to 8 seconds in total. Of course, this can be reduced further. For example, if the live source already originated in AWS cloud’s network, there’s an even lower latency IP protocol used (AWS DirectConnect to head-end network; transport over RTP-FEC in this case with <1s buffer etc.). But these wouldn’t be your typical deployment scenarios for a typical cloud playout live streaming use case.

FAQ

Q: What live feed input signal types and characteristics does Veset Nimbus support?
A: Multiple MPEG2 & MPEG4 MPEG-TS feeds over IP; up to 50Mbps total multiplex bitrate per feed. Feed resolutions starting with 576i SD, and ending with UHD (2160p@60fps)

Q: What AWS services can you natively receive live feeds from?
A: AWS MediaConnect, AWS MediaLive, AWS Elemental encoders of any kind.

Q: Can we run manual live events with operator interaction?
A: Yes. Examples include a) live events with undefined end (= live event continues playing out even if it’s scheduled time has passed; operator switches live event off when it’s finished); b) live events with undefined start (= live event starts according to incoming SCTE-35 signaling); c) completely manual operator overrides for manual start/end live events (even unscheduled).

Q: Live feeds and SCTE-35 – can you…?
A: Yes. There’s listener support for incoming SCTE-35 signaling that can be used to trigger various actions (live event start/end, SKIP/TAKE etc. Manipulation of the channel timeline, ad insertion, SCTE-35 passthrough etc.).

Conclusion

There are multiple live streaming event usage scenarios that Veset Nimbus cloud playout platform can help you realize. These include: multiple live input feeds, switching between feeds, using a combination of different protocols to deliver live feeds to the cloud.

So, no matter the scenario, Veset Nimbus has you covered whether you want to use the product for occasional scheduled live events, or for predominantly live event(s) based channel workflows.