The current live encoding looks something like this. An encoder takes in a raw feed at the venue or broadcast center and encodes streams in multiple formats and bitrates. The streams are then sent over a broadband connection to a CDN for delivery.
There are big challenges associated with this way of doing things. Encoding is a CPU bound process. This means that as you add more bitrates and streams, you will run out of capacity, and you will have to add more encoders. This requires great upfront capex, and operational expertise, both of which make it difficult to scale, as indicated in the diagram.
Moreover, delivering multiple formats in multiple renditions requires a lot of bandwidth. This can be expensive, and can limit the venues from which live events are broadcast. It’s also essential to keep in mind that the encoder scalability and bandwidth problems are exacerbated by having multiple simultaneous events, or multiple camera angles from a single event, or both!
Users connect to the Zencoder Live Cloud Transcoding service with an application via the API. You also need a lightweight encoder on site that can output an RTMP feed. This could be as simple as the free Flash Media Live Encoder, or something with a little more heft, like WireCast. The application makes a call to the Zencoder service and the Zencoder service returns a URL, to which an RTMP feed will be published, along with a stream name.The URL and Stream Name are plugged into the encoder, and the RTMP feed is published to the Zencoder service. The Zencoder service then does the heavy lifting, transcoding a single RTMP feed into HLS and RTMP output formats, and in as many bitrates as desired.
Compared to the old way of doing things, with this architecture it’s cheap and easy to scale your on-site encoder.
And because you only need to publish one RTMP stream to the cloud there are no bandwidth bottlenecks at the point of origin. Together this means less capex, and more flexibility with your live events.
The service scales up and down seamlessly, so you never hit capacity or pay for idle processing power.
A centralized facility with established encoding infrastructure can realize bandwidth savings by encoding in the cloud, and quickly iterate applications and adapt to new formats and devices. Examples include a broadcast head end, a data center, a newsroom, etc.
A highly decentralized architecture is very challenging and expensive without cloud transcoding. Not only does it benefit from a significantly lighter technology stack, but also enables totally new set of live streaming use cases. New content services can aggregate live streams from disparate sources for playback within an application. Examples include live user generated content, services that aggregate sports programming from highschools and colleges, multi-stage concerts, and field reporters for news organizations.
At the heart of the new Live products that we are launching, is this mission – 1) enable our customers to stream more live events by minimizing the cost and the operational complexity, and 2) enable our customers to reach a broader audience.On the next 2 slides, we have a diagram that should look very familiar to everyone …
NBC / Universal Sports Access to dozens of sporting events, both live and on demand: cycling, swimming, soccer, rugby, Olympic trials, etc. Some content available for free Some content requires TVE authentication via Adobe pass Some requires users to sign-in and pay
Hugo Boss Beijing Fashion Show with live and on-demand content available on their website, on Facebook and YouTube. All video content was available in 3D (with 2D option) It was a PR hit, generated active participation among fans and fashionistas. Limited edition glasses were made available in store locations around the world with a time stap for local access to live streams.
Brightcove Live SolutionsChris Little & John Riske