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.
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.
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 –
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
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:
Veset Nimbus configuration for this usage scenario is relatively simple:
In the next usage scenario, we can look at a live feed signals delivered to Veset Nimbus playouts over AWS MediaConnect:
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 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:
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.
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.).
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.