Achieve Near-Real-Time Video Streaming at Scale (Recorded Webinar)

Jamie Sherry:
Hi there, thank you for joining this webinar entitled Achieve Near-Real-Time Video Streaming to a Global Audience. My name is Jamie Sherry and I’ll be talking to you about low latency streaming and a new offering that Wowza has released recently. So, Wowza’s Streaming Cloud, if you’re not familiar, is a live streaming service that Wowza offers that provides, today, the ability to deliver live streaming content to a global audience. And what we’re introducing here today, talking about a new offering, is Wowza Streaming Cloud with Ultra Low Latency and what we’re touting here is any size, anywhere in the world, in under three seconds. We’ll talk more about that.

First, I’d like to talk about what latency is. I’m not sure if all of you know what that is. Latency is a definition that I’ve kinda put together, is defined as the amount of time between when a frame of video is captured and when it’s displayed. I’ll show you some examples here to articulate that in a second here. If you look at a typical live streaming workflow, we have a few standard components across that workflow that we like to talk about when we talk about live streaming. The first, from left to right, is capture and encode where we have cameras and encoders that are sending live sources, digital sources, into further components downstream. The next one is ingest and media processing, this is also known as an origin, and the live sources go into that ingest infrastructure and occasionally there is some processing happening there to prepare it for further down the line where we do the distribution and playback. Next, is distribution piece.

Distribution is, in this case, reflected as a globally set up infrastructure that helps with delivering live streaming content to a large audience in a widely distributed audience regionally or geographically. Then, of course, playback, the most important piece I think for everyone doing live streaming is the user experience. That includes the playback of the video content. Might be other things going on there, but the playback is often very involved and can be very intricate and complicated. And when we look at the delivery of the content in a traditional sense using a format like Apple HLS, which is an HTP live streaming format, we are talking about, if we look at our latency definition of moving a frame of video from capture to playback taking upwards of 30 to 45 seconds, that is a standard time that that type of content will take to be delivered. In many cases, that is well accepted, and in many cases, especially new-use cases are being developed, that is not as acceptable and people need that time to be lower.

When we talk about it with ultra low latency in place, we have the same components here; capture and encode, ingest and media processing, distribution, playback. And when we look at a frame of video moving from left to right, from capture and encode to playback, we’re talking about more of under 2 to 3 seconds. In this case, I show 1.78 seconds. That is more of what people need that, I’d love for that to be absolute realtime. That is not actually possible, but getting it close as possible, under three seconds, is very suitable for a lot of use cases and a lot of customers.
And latency doesn’t really have a standard measurement or definition in the industry. We have created this chart and created this actually a couple years ago when we started talking to customers more and more at trade shows and at other events and through customer calls and conversations, where we ended up defining latency around a standard based on cable. Streaming is often compared to cable TV, and so cable TV can be on average around five seconds and so we’ve framed out these streaming use cases around that to be higher and lower end.

If you consider the first case I talked about with the 30 to 45 seconds, they should be streaming typical format and there are a lot of cases where that high of a latency doesn’t really matter and that’s okay. As we move from left to right though we reduce the latency and we end up all the way at the end where we have solutions out there that can be less than a second or closer to really, really close near realtime. And those are things more like two-way conferencing like Zoom, or Skype, or GoToWebinar, things like that. What we really are considering is back in the middle here where we have reduced latencies and low latency, especially on the right where we have anything from gambling and gaming, and online gaming where people play games and/or betting tech games. And even when you just see stuff where end users are starting and doing their own live-streams, those times need to be much lower ’cause most of the times doing something with that on an interactive way to require that low latency.

What we’re talking about again is, with respect to our offering here of Wowza Streaming Cloud with Ultra Low Latency is live streaming with less than three seconds latency, sub-three second latency. We’re talking about glass-to-glass, it’s a term used to talk about from capture to playback, end-to-end’s another way to look at it and we’re talking about a scale. So when we first decided to work on this offering, we were talking to customers and prospects and people in the industry, and what we found is that a lot of people don’t just need that low latency but they need it at scale in the large audience live-stream to hit a large audience, or widely distributed audience. So the scale factor here is very important.

And if we consider that specific live workflow with respect to this offering of ultra low latency and Wowza Streaming Cloud, what we’re talking about again on the left with capture and encode is an IP camera or a live encoder publishing into Wowza Streaming Cloud or in some cases we can use Wowza Streaming Engine as well, and we can also use Wowza Gocoder. The STK can be used to build an app to publish into Wowza Streaming Cloud. These are the standard same ways to publish, use the same protocols, RTSP, RTMP, the Wowza Streaming Cloud with Wowza Gocoder. These can be used to cloud today. They can also be used with the ultra low latency feature that’s in Wowza Streaming Cloud. On the right, the difference now, is that we do require our player, our clients, the Wowza player in the browser, and the Wowza Gocoder SDK for mobile app development on IOS and Android. The GoCoder SDK has been expanded and extended to support playback, as well as publish, now. Because of the proprietary nature of the offering we have, this feature in cloud, we require these clients today.

We don’t expect that to be forever or for very long. We recognize that there are other applications out there that people use in the market that are leading like JW Player, or Bitmovin on the browser, other frameworks that could be used to build mobile apps, and we recognize that we will need to be able to support those and we will support those in the future.

And if we look at this workflow a little deeper in a more technical sense we are talking about first without ultra low latency today, what you could do with what we call our transcoder work flow with the output being Apple HLS. We have a camera again publishing to a live encoder, live encoder publishing into what we call a transcoder, which is the origin in this case, Wowza Streaming Cloud and then publish into … We do media processing on that transcoder, we create, for example adaptive bitrate renditions if we have a single bitrate coming in and we want to adapt the bitrate out. And we create those renditions, send those off to Wowza CDN and we deliver those as Apple HLS to our application.

And when we compare that to the workflow that we’re introducing here with this new offering with ultra-low latency, we have the same, again as I mentioned in the previous slide, the same protocols, methodologies for getting into or publishing into Wowza Streaming Cloud. Camera points to an encoder, for this example it uses the same protocols to go in to an origin, in this case the origin is not a transcoder, we do not support transcoding just yet with ultra-low latency in this workflow. That will be something that comes down the road here on the roadmap. Then what we do is we publish out of that origin to Wowza CDN using Apple HLS and we also publish, and that in this case is a single bitrate stream using Apple HLS and then we publish into Wowza CDN using the Wowza protocol. Again, a single bitrate stream as well. Then we go out to our clients Wowza player or Wowza GoCoder STK to play that Wowza low latency stream.

So the one on the bottom is the low latency stream, the one up to the Wowza CDN using HLS is what we call a fallback stream. That is to support some deficiencies we have on iOS in browsers today that I’ll explain in a second. That HLS stream is what we call a reduced latency, we can get again a sub-three seconds on the Wowza stream. We can get about 8 to 10, maybe 12 seconds on that HLS stream. So we can tune that down to get that even lower than the 30 to 45 seconds I mentioned in the beginning.

The deficiency I mentioned on [inaudible 00:09:33] browser platform does not, their browsers are not MSC based, and so we cannot support Wowza player on the iOS browsers today. So we have the HLS stream to get into the browser there. We also, again, have the STK to build mobile apps on iOS. So we have some answers for the iOS platform and we will continue to work on filling that gap in with the iOS browsers to get the true low latency Wowza stream with sub-three seconds onto the iOS browsers in the near future.

So let me talk about key features and benefits of the ultra low latency feature of Wowza Streaming Cloud. We’re talking about reliable scaling, I mentioned in the beginning, again that scale was a key part of this. It’s not just delivering the low latency to one or two users, but delivering it to thousands, ten of thousands, hundreds of thousands, and above amounts of users in a widely distributed fashion as well. Ultra low latency, obviously a key part of this. We’re talking about sub-three seconds. It’s something that we’ve been able to achieve. On average we can get about 2.5 seconds when we talk about region to region or continent to continent, and then within a continent or region we talk about 1.5 seconds on average. Those are averages [inaudible 00:10:44] Some things may differ there, the first mile, last mile optimization matters a lot there and so your mileage may vary, but we are very confident that we will get sub-three seconds throughout the network that we provide today for this feature.

This is built on Azure, we do have parts of our workflow for the transcoder side built into Google and Amazon, in this specific case built on Azure. So we are using cloud providers here again. Currently we are using Azure as our platform and they’ve been great to work with and we look forward to lots of success on their platform and it’s really well designed for what we’re trying to do here.

Stream security, we do have some basic security today. We’re looking for more features in the near future as well. The security features today are IP whitelist on the published side and then SSL on both publish and playback, and we’re looking to do [inaudible 00:11:37] on the playback side in the near future.

Quick integration, so we are API based here, which gives us an angle on the developer-focused star bullet I have down below. With that said, one single API call can get you back … can create a stream [inaudible 00:11:55] configuration in our system and get you back all the information you need to publish and playback that stream. So it’s pretty quick and easy, you can get a stream up and running very quickly.

Our global network, talked about our need to have a global, along with scale to have a global presence. Certainly that first mile, last mile optimization comes along with that, so we have [inaudible 00:12:15] which we’ll talk about on our future slide here about where we are with this network in the future today, but it is global today.

IUC Analytics. I have a slide where we’ll talk more about that in depth, but we basically have real time and historical analytics, like we do in the transcoder traditional workflow where they put [inaudible 00:12:34] similar analytics for the ultra low latency feature.
Developer focused, again we talked about that. We’re looking at developers more and more as we look at cloud and service and how we build out features and continue to improve and expand on our API access and things like that.

In tools as well, see the last bullet is mobile ready, that lends itself to the Wowza GoCoder SDK and how we’ve expanded that to support playback. That’s an addition to publish on applications built on both iOS and Android.

Key features and benefits, footprints. The next slide is talking about the global network I talked about on the previous slide. So we are in 5 regions today. We’re in what’s called central US, Western Europe, West India, East Asia, which is Hong Kong, and then Japan East, which is Tokyo. And if we look at the rest of the year, we have the blue dots which represent future regions. We’re talking about west coast, east coast, in the US. Presence in Germany and another presence in Europe. We’re talking about Australia as well, we’ve got some demand that’s increasing there. And then we have, actually demand in mainland China, so we’re working with Microsoft on how to get into their two regions in mainland China as well.

It’s a good point to make that these are the regions we have today, these are based on demand and where we were when we were in a beta preview state. We will go wherever we need to go as far as the demand, the customers drive with us. So folks need us to be in South America, we will move to South America as well. We’ll expand at our own leisure, and we will expand based on customers.
So we dive a little deeper into the technical specifications on the publish side, which is where the camera and encoder are. We’re talking about the standard protocols we use today which is RTMP/S, RTSP, and then WOWZ and WOWZ/S, that S is for that SSL language on the publish. The stream ingest can be push and pull. IP cameras tend to mostly use a pull distribution, where our servers will actually pull from the camera. Encoders tend to use mostly a push distribution method, where they will push into our infrastructure from the encoder.

On the playback side, we’re talking about our WOWZ protocol, which is very much like RTMP, but it’s been enhanced in various ways. It is used over WebSocket to get into our Wowza player on the browser. That avoids the need to have a plugin. Then of course we have Apple HLS as our fallback, and then we have WOWZ as a protocol which is used on the GoCoder SDK side, both in the publish and playback side if you’re building mobile apps on the iOS and Android platforms. The WOWZ GoCoder SDK enables as in the mobile applications on iOS and Android as I just said, Wowza player enables Wowz over Websocket and [inaudible 00:15:37] browsers. Talking about WebSocket it works in everything that pretty much MSC works in, that’s where Wowza player is supported and that tends to lend to every market leading modern browser except for IE 10 and 11, basically IE, all of IE does not work with MSC. At least not reliably. Unfortunately there’s that one doesn’t work, but Edge does, so we still have an angle with Microsoft there.

Codec support again. We’re not using transcoders so keep in mind this is single bitrate and we are using H265 and AAC as our codecs and they remain that way all the way through the publishing workflow. Since we publish and playback and you cannot use a transcoder in the middle to do any transcoding where you would swap codecs or, you can’t do any trans rating or [inaudible 00:16:30] That’s the only thing that is supported, but the other transrate and transcode are not supported.
Resolution support. We’ve tested, just for fun, well above this into the 4k range, but today we’re consistently saying we support 1080p, 30 frames a second at 6 Mbps. And again the latency we’re talking about is sub-three seconds, but we are again seeing averages of 2.5 across continents and 1.5 on average within a continent.

Talked about security already, but again IP whitelist on the publish side, and SSL on the publish and playback side. Then we have support for what we call meta data synchronization, we can support AMF data types in the the [inaudible 00:17:12] protocol and we can actually ingest that as part of the stream and that can be extracted on the other side and used in Wowza player or the Wowza GoCoder. In the case of HLS, there’s a a future coming soon where we will have a conversion capability to convert AMF to ID3 so we can support the HLS playback with meta data as well. Key feature that a lot of customers want to use.

Analytics, I’ve mentioned this briefly before, but to dive in a little deeper, we’ve got stream metrics and viewer data. We’re talking about connection data for targets from the ordinance server including the average inbound bitrate of stream and number of dropped connections, viewer data, location where viewers watched the stream and number of unique viewers at each location, you can use date ranges and all sorts of flexibility to look at this data over time for historical reasons, and again you can access this through the UI and API.

Configuration management, we’re talking about configuring and managing through the API again. This is an API driven feature. Look for access to do configuration management in the user interface in the future. Analytics are accessible through the rest API and I should mention here, they are accessible through the UI as well, as read only data. I should also say that once you’ve configured something in a live stream configuration in the API you can go into the UI into the read only data there too. Kinda helpful to grab the data and plug it into your encoder and plug it into your player and go from there.

[inaudible 00:18:46] access, account management documentation, and usage data are all available through the UI as well. Talk a little bit about commercials, we have four plans. We’ve got what we call platinum, gold, silver, and starter. The gold, silver, and platinum plans all match up with Wowza premium support entitlement, so platinum has platinum support, gold has gold support, silver has silver support. If you’re not familiar with those, you can check out our website and go to the support area and learn more about those plans.

What’s included here is CDN delivery, as a measure of dollars per gigabyte, and they are broken down by what we call zones, which are geographic regions. We do have some fluctuation there to account for infrastructure costs on Azure. Zone 1 starts at $0.15 per gig, zone 2, which is Asia Pacific, starts at $0.20 per gig, and zone 3, which is Latin America starts at $0.25 per gig. Basically the platform fees you see on the left will, as they go up the zone pricing goes down. For example, delivery price for each zone is cheaper on the gold plan than it is the silver plan. And respectively is cheaper on the platinum plan than on the gold plan or silver plans.

We have a starter plan that is $49, it is essentially what we call our paid trial today. You do get the GoCoder SDK as I call a perpetual license, not to mistake it for a perpetual license on Wowza streaming engine. What it means is you get a forever license that lets you build apps for for publish and playback included in this pricing. You get that with every plan except for the starter plan. I didn’t note that here, but please note the starter plan does not include the GoCoder SDK, you get a trial version of the SDK if you want, and that way you can actually test it out. Starter plan, again, is really meant for people testing, kinda doing some development, getting going, and then jumping to the other plans where the pricing is more effective and more relevant to what they’re trying to do.

What’s a little bit complicated but important to note is that you get all of the, what I call [inaudible 00:20:59] included in this pricing as well. What that means is the standard rates that apply to transcoding and recording and all the other features specific to the transcoder workflow where HLS is the delivery format. That’s the workflow we have today. It’s been around since the beginning of the service offering. That is all included at the standard pay as you go rates, and those are all available on the website, so you do get access to the transcoder workflow. These are separate workflows, as I showed you in that diagram earlier though. There’s some different features there. Eventually these workflows will merge into a more singular workflow. Today they are separate. It just gets a little complicated, just talk to us about that if you get confused. But you do get access to that other workflow as well as the ultra latency work flow, which is very key. We really want to move towards a model where customers are getting … when they get access to Wowza Streaming Cloud, there’s access to everything and they simply pay for what they use.

And that’s all I have today. If you have any questions or comments, my name is Jamie Sherry again. Jamie@wowza.com is where you reach out to me on email. I hope this was helpful to you, and I look forward to presenting and talking to you in the future on more exciting things coming for Wowza Streaming Cloud.