CHRIS KNOWLTON: My name is Chris Knowlton, as you heard.
I'm with Wowza Media Systems.
And our company got started, actually,
when our founders, in 2005, thought they
wanted to start a new business.
And they weren't really sure which-- this is not mine,
I just want you to realize that-- they
wanted to get into video.
They thought it was emerging, and they thought
it would be really interesting.
So they started a video blogging business,
and they found while they were trying
to build out the business that they couldn't find a media
server on the market that met their needs.
They couldn't find one that was scalable, reliable,
and flexible enough.
And so as part of the business, they developed their own media
server.
And then they went out to trade shows,
and people kept coming to them, and saying, yeah,
I don't care about the video blogging,
but what server are you using because I want that?
And so they did a pivot, and they
started a new business around something
called Wowza Media Server.
And so it's been on the market since-- it actually went out
in pre-production in 2006.
By the time it launched in February of 2007,
it had 1,000 users on it already.
We now have folks in over 150 countries using it,
and it's arguably now the most widely used streaming media
server in the world.
Oh, there we go.
Yeah, yeah.
That's good.
It's used for a lot of things.
One of the nice things about it is
that it's been in the market, as I mentioned, since early 2007.
Every year it has won multiple awards, both reader's choice
awards and editor's choice awards
for innovation and for support.
And one of the nice things about it, I guess,
is when it came to market what it was really competing
with a lot was Flash Media Server, Windows Media
Server, then IIS Media Services, and RealNetworks.
And eventually, all of those have pretty much
either gone away or changed their focus.
Microsoft's no longer shipping Media Server software,
RealNetworks is not, and Adobe's focused
on their OTT, or their TV everywhere offering
through Primetime.
And so we came to the market with something
that supported multiple protocols,
multiple ways of streaming, so not just
Windows Media or just IIS Media, or real streaming.
But a combination of all of those.
Basically, you could take a single workflow
with Wowza Media Server, and replace
multiple parallel workflows that you had with all
these other technologies.
And some of those other technologies
were obviously based on using a certain operating system.
Another thing that Wowza has done
is based its ability to run not on any single operating system,
but on multiple, so it'll run on almost any machine you have.
So it makes it very flexible.
It's made it very attractive to a lot of folks.
It was originally aimed at developers and folks who were
streaming media professionals.
And over time, what we've tried to do
is to continue to simplify streaming, not only by offering
multiple formats in a single product,
and the ability to ingest from almost any encoder,
and deliver to almost any screen on the planet,
but to do it in a simpler way.
And to make it easier and easier,
lowering the bar to get involved in streaming,
and not having to be so technically literate to get
started.
So let's see.
What did I miss?
Anything?
We're growing fast, lots of awards.
OK, good.
Move on.
For those of you who might have heard of Wowza Media Server
originally, it's now actually called Wowza Streaming Engine.
We changed the name last year, and we released a user
interface for it.
Before then it was all about XML and command line, which
is great for a lot of you.
For a lot of folks, it was a little bit intimidating.
So we put a nice wrapper around it, web-based UI.
So that even from your Android phone,
your tablet, your desktop, wherever you are you
can control your server just by going into a web browser
to a URL.
Let's see.
Did I miss anything?
I did mention the multiple formats,
the idea that you can stream in multiple formats not
just a single one.
You can do smooth streaming.
You can do HTTP Dynamic Streaming,
Adobe's adaptive streaming format,
or as well as our TMPN and RTSP.
How many here actually know what I'm
talking about when I mention these acronyms?
OK, a few of you.
Excellent.
Let me just put it this way.
No matter what device you have, an iPhone, an Android,
a Windows Phone, a television, a set-top box, Wowza Streaming
Engine can put out a stream in a format
that those devices will be able to playback from.
So you no longer have to have multiple sets of technologies
to hit all those endpoints.
So who uses Wowza is a question I get asked.
Usually the question I ask back is, who doesn't use Wowza?
And what I mean by that is that there are almost no streaming
scenarios that you can think of where Wowza is not being used
today, from over the top scenarios that you see over
in the lower right there to live events to inside enterprises
and universities.
For surveillance capabilities as well as planes,
trains, automobiles, and cruise ships for folks who
are putting in their own on-demand delivery service.
And increasingly not just because they're
going to a fixed television mounted to a wall,
but because folks in the hospitality business
are finding that if somebody brings their favorite tablet
with them, they want to go around the cruise ship
and watch their content no matter where they are.
And Wowza can stream to all of them,
and give folks that great experience no matter where they
are in that cruise ship, as it were.
It's also used for-- we don't really address it here--
but it's also used for things like real time video
conferencing.
So a lot of folks have built online video platform
around that capability to deliver content and have
video chat and conversations using Wowza Streaming Engine.
So here is the marketecture slide for how Wowza works.
In one side you see, in the upper left, the input
and publishing.
And what it's showing is that we can take an input from almost
any source, whether it be a camera that can put out
an IP stream, an IP camera or a network camera,
whether it be content that you're pulling from a drive
somewhere, say Google Storage, whether it's internet radio,
or even just you can pick up an iPhone
and run a free app that we'll provide you called Wowza
GoCoder on it, and you can hold it up,
and point it at something that's happening that's exciting,
and you can stream it out to the world.
And we can do that from almost any encoder
just because we support so many incoming protocols.
So once it gets to Wowza Streaming Engine,
which is just a piece of software
that runs either on premises or in the cloud,
and what we really want to talk today about is the cloud,
and how it runs very well in Google Compute Engine.
Once we get it, we can take that one stream coming in.
And typically what we recommend is people send us
one HD String if it's a live event, and we'll take it,
and we can transcode it and transrate it,
which means we can take in one HD stream,
and then make different incremental streams that
can be used for what's called adaptive streaming.
So if you've ever watched Netflix or Hulu
and noticed that every once in awhile it'll get a little fuzzy
and then it'll snap back and be sharp again,
but you never see the word buffering.
That's because a few years ago adaptive streaming came out
onto the market-- about 2008-- and it allows your player
to automatically adjust as your bandwidth adjusts
or as what you're doing on your device changes.
Maybe you've got more load going and your CPU
is getting bogged down a little bit.
It'll adjust to a lower stream, one that's easier for it
to playback or to pull across the network.
And it will allow you to play back
with a seamless experience, or maybe
you just get a little bit of fuzziness
for a couple of seconds, but it keeps on going.
You don't have to wait for a buffering symbol.
And so that's what adaptive bitrate streaming is all about.
And Wowza Streaming Engine allows
you to bring in a single stream and create
these multiple streams needed for adaptive bitrate streaming.
And that's its probably most popular
use today, although it's still really used
a lot for both RTMP, traditionally flash streaming,
and RTSP streaming, which is an even older version
of streaming, a traditional stateful streaming protocol
used by many legacy devices, especially in emerging markets
now.
And then when it goes out, as I mentioned,
it can go out in many different streaming formats,
and it can go to almost any player.
You can pick a player.
You can send it to a built-in player on an iPhone
or an Android device.
You can pick a player like JW Player or Flowplayer
that plays back almost across any device and any screen,
and makes it even simpler because they help you customize
the player and everything so that you have this really
great experience that's customized
for your content and your delivery for your end users.
Other things that we can do, just in case
it's interesting to you, we can also
do things like closed captioning, a key requirement
for the FCC these days.
Lots of API extensibility here, so anything
that you can do through the UI or through the command line,
you can also do directly through the API.
So you can actually build this into an offering
that you have completely transparent to your end user
that you're using this product, and deliver the content
to them.
And then we have a couple of other things
that used to be called premium add-ons.
Now they're just part of the base
price of the product which is $65 a month for the software.
I mentioned the transcoding earlier,
that capability to bring in the content.
Not only split it up into different bitrates,
but also bring in content that maybe was encoded on an older
encoder, change the codec, the way it's compressed,
and then spit it out as multiple versions
and in multiple formats.
We also have DRM capabilities, so obviously for a lot of you
if you're delivering studio content,
you need to have that content protected all the way across.
So Wowza Streaming Engine can take in protected content,
unprotect it, decrypt it, and then send it
out to all those different devices
in multiple formats, encrypted, and protected in multiple ways.
And we have built-in integration with three DRM service
providers.
And it also works across in some very wide DRM platforms
if you want to do a little work on your own.
And then the last thing is network DVR, end DVR,
that capability to pause a live stream
or jump ahead or jump back in the stream that you get
and have been able to get for a number of years
with set-top boxes and TiVo.
All right.
So a typical workflow, to take what I just
showed you there is, for a live event anyways,
you have some kind of camera.
You have some live event.
Maybe you have multiple cameras, like we have today.
There are actually multiple cameras
in the room today capturing this event.
And if we were streaming live-- and next time
I hope we're streaming live with Wowza and Google--
you would actually pull in those multiple streams.
And you can mix them in real time in something
like-- you can either just pull it into a single encoder
or you can bring it into an encoding product such as tell
a Telestream Wirecast or NewTek TriCaster, if you've
heard of those.
Bring in multiple streams and do live mixing of those streams,
and switching shots, and putting on overlays and titles.
So that's probably what you would do at a venue.
So a lot of folks use Wowza Streaming Engine
when they're at a live event, a football
game, a house of worship service, a live concert,
an event like this even.
And they capture this event, and then they
send out one single stream that's
been compressed with the H.264 video codec and AC audio codec.
And they'll send that to a Wowza Streaming Engine in the cloud.
And there we'll do all that transrating,
the creating of the multiple bitrates files or streams,
and we'll repackage it into those multiple formats
that I talked about-- smooth, streaming, HLS, HDS-- and then
we'll publish it.
And you can actually publish directly from Google Compute
Engine instances right to a bunch of end users
who are on their phones, whether they happen to be streaming
in emerging markets over these traditional streaming protocols
that I mentioned-- RTMP and RTSP--
or you can publish directly out to a CDN such as Fastly,
which does a great job of scaling
out all HTTP type streaming.
So you get that great adaptive bitrate streaming plus you
get global scalability.
And then you hit any screen that's out there.
Because there are enough players out there
that will allow you to deliver to any screen in the world just
using one or two formats such as Apple HLS.
So why do we use Google?
We actually started using Google--
I'm going to jump ahead-- we started using Google
two years ago because we saw some things in Google Cloud
Platform that we were not seeing with some other cloud providers
that we'd been testing on.
The first thing is that its startup speed was much faster.
To some extent, this is a lot of anecdotal as opposed
to performance testing.
But our engineers realized that the startup speed
was about twice as fast as what we were
getting on other platforms.
From a storage performance perspective,
the I/O was much better.
We were able to move data in and out of drives and on disk
and back very quickly, which can be really critical if you're
pulling in a live stream and recording it in real time,
and then delivering it out, especially
with that network DVR capability.
And then you want to pull it out later
so you can have this archive file
that you play back on demand.
We also found that with some cloud platforms
we've been using, customers were finding that their experience
was inconsistent.
So they would be running our server on a cloud platform,
and they would find that it would not always
be a consistent behavior.
And sometimes they might be able to support
500 concurrent connections, and other times it was 1,000.
And it seemed to be a bandwidth limitation where
perhaps too many people were sharing the same network pipe.
We don't see those problems at all with Google Cloud.
And then from a pricing perspective
it was attractive not only for us,
but for our customers who are just running Wowza Streaming
Engine on Google, because they could not only, as it was
mentioned earlier, not only do you get to sustained use
pricing where the longer you use it the more the pricing drops,
but also for those folks who are running the short term
events or the bursty traffic, and they wanted
to be able to just pay for what they use,
the 23 minutes, not the full hour.
And the final thing that we like is
that when we're creating an image,
we don't have to create an image for each region,
as you might have to do on some other platforms.
Made it very easy.
We create a single image, we populate it out there,
put it in a storage bucket, and everyone can get to it.
We don't have to create multiple versions,
just specific for a region.
So what's coming next?
I'm showing here on one side the steps
that it takes to get started with Wowza Streaming
Engine on Google Compute.
It's not very difficult. There are a number of steps
that you have to go through, but if you
want to do this on a regular basis,
this might get a little bit tedious
if you had to do it all the time and with multiple instances.
So there's certainly a much easier way to do it,
and that's using Click-to-Deploy.
Soon I'm hoping that we're going to be
able to offer the first commercial Click-to-Deploy
offering.
Today, if you go to the Google Cloud site,
you will find that there are a bunch
of Click-to-Deploy offerings out there all open source where
you can go and very quickly click on an offering,
make a couple of configuration settings, and then launch it.
And it just saves a whole lot of steps in configuration.
And we're going to be offering that.
You'll also be able, very soon, to start
doing things where you take a whole bunch of resources
in a similar way, you could say, I
want to fire up three instances.
I want to use this storage.
I want to push it to Fastly.
And you can do it all through, essentially, one configuration
script.
You'll be able to do that very soon too, so that once you have
your settings the way you want them
you can just fire it off the same way every time.
Speaking of Fastly, we're also going
to be offering Fastly integration soon.
So today, you can do it.
There are a few steps involved.
We're going to make it a lot easier.
There are two ways you can do it really.
The first way is if you have a live stream,
you can push it to a storage bucket.
Makes it very easy.
And then Fastly just picks it up from there
and distributes globally.
We also have very low latency connections
because Fastly is co-located or has the interconnects
where Google Cloud platform is located.
So the connections there are really
low latency, which is very good for us as far
as getting content to your users faster.
So the TV, they don't hear the cheer on the TV several seconds
before they see it on their device.
And then the last thing is if you're
doing on-demand streaming, you're pulling the content off
of a Google Compute Engine instance
using Fastly as your distribution mechanism.
As Simon mentioned earlier, they have the origin shield
capability, which protects the origin
from getting too many requests at once from all those edge
nodes that Fastly runs.
They just have a single request come back all the time,
and then feed all those nodes.
And so that workflow that I showed
you earlier would look like this when
you put Fastly in the middle.
So that's it.
If you have questions, we'll have Q&A later.
I'll be happy to answer then.
And of course, I'll stick around also
as well if you have other questions
or feel free to email.