WEBVTT

00:00:00.200 --> 00:00:04.000
[Music]

00:00:04.500 --> 00:00:08.380
Thanks for joining us today. I am
super-thrilled to be sitting

00:00:08.430 --> 00:00:11.150
here with a good friend of my and
a colleague from way back,

00:00:11.200 --> 00:00:16.840
Ryan Groom, who was kind enough to
come and sit with us and talk

00:00:16.890 --> 00:00:20.250
a little bit about some of the
amazing stuff he's doing with

00:00:20.300 --> 00:00:23.400
online video, and particularly
with Azure Media Services.

00:00:23.670 --> 00:00:25.980
So for folks that don't know you,
Ryan, maybe you could give

00:00:26.030 --> 00:00:28.520
us a little bit of background on yourself
and what you've been doing.

00:00:28.570 --> 00:00:32.200
>> Sure. I've been working on the Microsoft
platform for a long time.

00:00:32.250 --> 00:00:35.330
I was a Microsoft partner
back as 2002.

00:00:35.850 --> 00:00:40.250
Exited that in 2004 and sort of
went my merry way, and now I've

00:00:40.300 --> 00:00:45.390
come back. I do a small TV show,
so video is in my blood, and

00:00:45.440 --> 00:00:48.870
it just matches nice with Azure Media
Services. So in the summertime,

00:00:48.920 --> 00:00:52.810
I film, and in the wintertime, I
edit and also do coding projects

00:00:52.860 --> 00:00:55.350
against Azure Media Services.

00:00:55.640 --> 00:00:58.210
>> So tell us a little bit about
your show. What do you do?

00:00:58.260 --> 00:01:01.910
>> Well, it's called Trekkit. It's
about getting computer people,

00:01:01.960 --> 00:01:04.890
office people, off their rear end
and out to do a little bit

00:01:04.940 --> 00:01:08.570
of adventuring. We're all out of
shape, and we pretend to be

00:01:09.570 --> 00:01:13.390
Indiana Jones. Like we've done the
Knife's Edge in Mount Katahdin.

00:01:13.440 --> 00:01:16.010
So we've got a guy that goes across
the Knife's Edge. It gets

00:01:16.060 --> 00:01:20.190
to three meters wide. It's a 1,000-feet
drop on either side,

00:01:20.240 --> 00:01:23.010
and I'm sitting there holding. I'm
crying on the side, I don't

00:01:23.060 --> 00:01:26.290
want to go any farther. But there's
guys that have done it, and

00:01:26.340 --> 00:01:29.280
they're like, come on, Ryan. It's
not like I'm an adventurer,

00:01:29.330 --> 00:01:32.900
but I want to be, so we've done
that. We have headed to the UK.

00:01:32.950 --> 00:01:36.240
We went the Isle of Skye, out where
there's more sheep than people.

00:01:36.290 --> 00:01:37.090
It was fantastic.

00:01:37.140 --> 00:01:37.680
>> Amazing.

00:01:37.730 --> 00:01:40.550
>> And even last summer, there was
four of us that went to Iceland,

00:01:40.600 --> 00:01:43.110
and instead of just doing the golden
circle that most people

00:01:43.160 --> 00:01:47.340
do, we did the whole island. We
went to places as magnificent.

00:01:47.640 --> 00:01:51.030
There was no people. We set up the
cameras and had a good time.

00:01:51.080 --> 00:01:54.880
So I come back, I edit it all
on my Windows PC. Most people

00:01:54.930 --> 00:01:57.010
come back, do all their editing
on a Mac, but we do it all on

00:01:57.060 --> 00:02:01.230
Adobe Creative Cloud on my big
Windows 8 box. And then all my

00:02:01.280 --> 00:02:03.590
video encoding is done in
Azure Media Services.

00:02:03.640 --> 00:02:06.910
>> So how did you come about to
use Azure Media Services?

00:02:06.960 --> 00:02:11.240
Was it because you were used to the
Microsoft way of doing things?

00:02:11.290 --> 00:02:15.800
>> No. We were looking at a way to
deliver multiple video types

00:02:15.850 --> 00:02:20.540
to multiple devices. I do live streaming
for a local telco, and

00:02:20.590 --> 00:02:23.750
we were just doing Smooth Streaming.
But as the world's changing,

00:02:23.800 --> 00:02:27.980
more devices need HLS. The new ones
want DASH, and we still have

00:02:28.030 --> 00:02:31.020
the Smooth Streaming component. And
we didn't want to give three

00:02:31.070 --> 00:02:34.920
different signals and have to encode
it three times. The PCs

00:02:34.970 --> 00:02:38.540
were overwhelmed. So I was looking
at the live services, and

00:02:38.590 --> 00:02:42.760
luckily, I was on the preview, which
has gone finally live this fall.

00:02:42.810 --> 00:02:45.740
But we've built a service where
we can take one ingestion and

00:02:45.790 --> 00:02:49.950
actually spit out HLS, spit out
Smooth Streaming and spit out

00:02:50.000 --> 00:02:54.720
DASH, all at the same time, so
we've got iOS devices, but we

00:02:54.770 --> 00:02:58.110
still consume Windows 8 apps
or the set-top box.

00:02:58.850 --> 00:03:02.720
And DASH, a lot of the new JavaScript
video players use DASH,

00:03:02.770 --> 00:03:06.290
so like Chrome and the new IE can
consume that, but I don't have

00:03:06.340 --> 00:03:09.490
to bring in three signals and worry
about the quality of three signals.

00:03:09.540 --> 00:03:13.000
I'm bringing one, and I can spit it
out in all those different formats.

00:03:13.050 --> 00:03:17.910
>> That's amazing. So this must have
been a journey for you, learning

00:03:17.960 --> 00:03:23.450
about not just how to film a TV show
and how to produce the content,

00:03:24.120 --> 00:03:28.480
but how to actually work with a
cloud-based provider like Azure

00:03:28.530 --> 00:03:30.110
for doing media.

00:03:30.960 --> 00:03:33.570
What are some of the things that
surprised you about that?

00:03:33.620 --> 00:03:38.340
>> To go way back, I've been responsible
for a server since 1991.

00:03:39.260 --> 00:03:42.520
In some form or another, I've had
servers or banks of servers

00:03:42.570 --> 00:03:46.240
or managed servers for customers,
and just last week, I shut

00:03:46.290 --> 00:03:50.140
down my final server I'm responsible
for, so it's been a big transition.

00:03:50.190 --> 00:03:53.420
I'm a megalomaniac. I like to control
things, and to be able

00:03:53.470 --> 00:03:57.500
to give up seeing a server, installing
it, be able to configure

00:03:57.550 --> 00:04:02.260
it, and go to the cloud, for me, with
this gray here, is a big step.

00:04:02.310 --> 00:04:04.910
So it was a journey, because
it's the trust factor.

00:04:05.460 --> 00:04:08.970
It's the trust that I'm going to have
enough Internet connectivity

00:04:09.020 --> 00:04:12.260
to the cloud, that it's going to
have the uptime, it's going

00:04:12.310 --> 00:04:13.380
to have the redundancy.

00:04:13.900 --> 00:04:16.180
When I was building server infrastructures,
I made sure, like

00:04:16.230 --> 00:04:19.630
when we did SQL, we had mirroring.
Sometimes, we had mirrors

00:04:19.680 --> 00:04:22.870
of mirrors. We had lots of load
balancing, and when things went

00:04:22.920 --> 00:04:25.240
wrong, we could troubleshoot them,
because we could touch the wire.

00:04:25.290 --> 00:04:26.830
>> Sure. You could shake it.

00:04:26.880 --> 00:04:31.730
>> So it was a hard call, but once
the Azure tools start bubbling

00:04:31.780 --> 00:04:35.570
into Visual Studio more, where I
could build a website or build

00:04:35.620 --> 00:04:38.900
a service and be able to publish
it from Visual Studio into the

00:04:38.950 --> 00:04:42.240
service and then be able to connect
to that, then the light bulbs

00:04:42.290 --> 00:04:45.510
start coming on, well, this is
a very interesting workflow.

00:04:45.560 --> 00:04:48.020
Now, on Saturday, when I want to
relax, I don't have to worry

00:04:48.070 --> 00:04:52.170
so much that the servers have gone
down. And being in New Brunswick,

00:04:52.220 --> 00:04:55.330
I didn't have a lot of... a lot of
our server farms were in Montreal

00:04:55.380 --> 00:04:59.260
or Ottawa or Toronto at different
times of my career, and sometimes

00:04:59.310 --> 00:05:02.340
really bad things would happen, and
those service providers couldn't

00:05:02.390 --> 00:05:06.290
fix the issue, and I'd be driving
with a buddy of mine to those

00:05:06.340 --> 00:05:09.280
locations to fix things, with new
equipment. Maybe a new server,

00:05:09.330 --> 00:05:13.200
maybe a new switch, maybe a new
firewall, and I don't have to

00:05:13.250 --> 00:05:14.300
do that anymore.

00:05:14.820 --> 00:05:18.030
I'm going on vacation after this
conversation, and all I have

00:05:18.080 --> 00:05:21.710
to do is give a friend of mine authorization
to my Azure account,

00:05:21.760 --> 00:05:23.310
and I trust this guy a lot.

00:05:23.360 --> 00:05:24.880
>> Sure, you would hope.

00:05:24.930 --> 00:05:28.560
>> But now he doesn't have to have keys.
He doesn't have to have passcodes.

00:05:28.610 --> 00:05:32.280
He now has access to my Azure infrastructure,
and he understands

00:05:32.700 --> 00:05:36.210
what we've built, and it's exciting
times. It's sort of freeing.

00:05:36.260 --> 00:05:40.200
The dog collar has come off from
the server farm, and now I can

00:05:40.250 --> 00:05:42.310
be anywhere. When we were in Iceland,
we had a slightly little

00:05:42.360 --> 00:05:46.160
problem for a customer, so we had
Internet access. I'm on my

00:05:46.210 --> 00:05:48.920
Azure account, we fixed it up, and
away we went. It was really cool.

00:05:48.970 --> 00:05:52.980
>> That's amazing. That's really
cool. So assessed you started

00:05:53.030 --> 00:05:55.930
to learn about using Azure Media
Services, were there any things

00:05:55.980 --> 00:05:59.890
that surprised you about it, things
you didn't expect about it?

00:05:59.940 --> 00:06:03.340
>> Yes, the Encoder. I didn't expect
to have a method to bring

00:06:03.390 --> 00:06:07.870
in large files and encode them into
different formats. The indexing

00:06:07.920 --> 00:06:12.170
service was real surprising, so
to do close captioning now.

00:06:12.220 --> 00:06:14.990
I would love to hook that up to
a Bing Translator. I mean, it

00:06:15.040 --> 00:06:18.020
may not be the greatest, but it's
better than nothing. I don't

00:06:18.070 --> 00:06:22.040
have French, Spanish, Chinese,
all those people on staff, but

00:06:22.090 --> 00:06:24.370
for a community channel, maybe that's
good enough. I don't know,

00:06:24.420 --> 00:06:29.110
so we're experimenting with that.
The uptime, because the servers

00:06:29.160 --> 00:06:32.440
aren't in Canada, there's such
a great connection from where

00:06:32.490 --> 00:06:35.610
the data sits... we use US East
and East 2, mainly, and there's

00:06:35.660 --> 00:06:38.630
a great connection into the Canadian
infrastructure. I was always

00:06:38.680 --> 00:06:41.610
worried about that, because sometimes,
we'll have up to 10,000

00:06:41.660 --> 00:06:45.860
to 20,000, sometimes 50,000 simultaneous
users on our live events,

00:06:46.530 --> 00:06:49.970
and the pre-roll comes right off
Azure Media Services, right

00:06:50.020 --> 00:06:52.990
on the streaming media unit, because
it's a 200 megabit circuit.

00:06:53.040 --> 00:06:54.880
I was wondering, is that
going to get saturated?

00:06:55.770 --> 00:06:59.620
How many VMs do I need? Because
that's a website that's being

00:06:59.670 --> 00:07:03.450
hit, as well. So we've got a website
being hit, we've got Azure

00:07:03.500 --> 00:07:06.610
Media Services being hit, and we
also have blob storage, because

00:07:06.660 --> 00:07:09.750
all the graphics are custom uploaded.
Like the banners and the

00:07:09.800 --> 00:07:14.910
ads come from blob storage. Can it handle
it? And it's been very interesting.

00:07:15.210 --> 00:07:18.530
And what's really funny, I made...
this summer, I was switching

00:07:18.580 --> 00:07:22.260
a system over, and I made a mistake
in my caching algorithm.

00:07:22.310 --> 00:07:23.610
Well, the site was slow.

00:07:24.250 --> 00:07:27.090
Oh, no, was Azure down and what's
wrong? You always blame it

00:07:27.140 --> 00:07:30.330
on somebody else, right? Well, it
was a problem in my code, but

00:07:30.380 --> 00:07:33.050
you know what saved me? I could
go in and scale it up while I

00:07:33.100 --> 00:07:34.970
fixed the problem. So the scale

00:07:37.080 --> 00:07:39.910
made it a little bit better, like
a salve on a wound while I

00:07:39.960 --> 00:07:43.060
was going. Then I could scale it
back down. It cost me a fortune,

00:07:43.110 --> 00:07:46.640
but it only cost me those servers
for a day, right?

00:07:46.690 --> 00:07:49.800
>> So scale on demand seems to be
a big part of this, as well.

00:07:49.850 --> 00:07:52.210
>> Oh, it's huge, because when you put
a new app out, you don't know.

00:07:52.260 --> 00:07:55.110
You really don't know the scale.
You can load test it, whatever.

00:07:55.160 --> 00:07:58.760
Until you get real people... we
launched a service in 2007 with

00:07:58.810 --> 00:08:03.040
CBC, and I remember going, do we
have enough servers? For that

00:08:03.090 --> 00:08:07.040
day that CBC launches us on TV and
does an ad, are we going to

00:08:07.090 --> 00:08:10.570
get crushed? Because we didn't
know. But now, when I launch

00:08:10.620 --> 00:08:13.720
stuff, I sit there, I watch the
Performance Monitor. I see what

00:08:13.770 --> 00:08:16.970
my response time is, and I can
scale it up and down as I need

00:08:17.020 --> 00:08:20.660
to, and that saves a lot of money
and a lot of heartache.

00:08:20.710 --> 00:08:25.690
>> That's amazing, and are there
things that... so this seems

00:08:25.740 --> 00:08:29.730
to have given you a lot of opportunity
to innovate in terms of

00:08:29.780 --> 00:08:33.030
how you're delivering content
and with your show. Are there

00:08:33.080 --> 00:08:37.440
things that you want to do as a
next step with Azure that are

00:08:37.490 --> 00:08:38.930
really exciting for you?

00:08:38.980 --> 00:08:43.070
>> Yes, it's to build some video
portals, to really build more

00:08:43.120 --> 00:08:44.500
new live services.

00:08:45.090 --> 00:08:47.940
Looking at a company, they have
some technology from Germany,

00:08:47.990 --> 00:08:51.820
so in order to send a live stream,
be able to use a webpage,

00:08:51.870 --> 00:08:55.110
so the webpage has a plugin that
hooks to the camera. But we

00:08:55.160 --> 00:08:58.040
can configure it all in the back
end, so they don't have to use

00:08:58.090 --> 00:09:02.410
a complex application on the front end
and have all the settings right.

00:09:02.460 --> 00:09:05.380
All they have to do is login, put
when they want to stream, make

00:09:05.430 --> 00:09:08.550
sure they can see the camera, and
we can set all the details

00:09:08.600 --> 00:09:11.120
up in the back end and
stream that to Azure.

00:09:11.170 --> 00:09:14.900
>> So it sounds like it allows you
to actually get even more removed

00:09:15.160 --> 00:09:20.090
from the production of content and
handle it where and when you can.

00:09:21.130 --> 00:09:23.990
>> For sure. We can have up to eight
to 10 live events simultaneously

00:09:24.240 --> 00:09:25.860
with the live streaming
we do now.

00:09:25.910 --> 00:09:26.930
>> That's fantastic.

00:09:26.980 --> 00:09:28.880
>> So you think of the support. And
you know when all that live

00:09:28.930 --> 00:09:32.790
streaming is? Friday night, Saturday
and Sunday, and that's when

00:09:32.840 --> 00:09:35.460
I don't want it to break, because
I want to have my weekend.

00:09:35.510 --> 00:09:36.100
>> Absolutely.

00:09:36.150 --> 00:09:39.530
>> Right? So we need to build this
robust, so I don't have to

00:09:39.580 --> 00:09:42.650
sit there and put my fingers in
dikes to make sure it works.

00:09:42.700 --> 00:09:46.310
I want to be able to go away on
vacation, have a weekend with

00:09:46.360 --> 00:09:49.900
my buddies and my family and just
know it's going to work.

00:09:49.950 --> 00:09:53.900
>> It brings up an interesting point.
You talked little bit about

00:09:53.950 --> 00:09:56.400
wanting to have some weekends and
that, and I've known you for

00:09:56.450 --> 00:09:57.260
a long time.

00:09:59.730 --> 00:10:03.300
You have always been a great tinkerer
and you know how to write code.

00:10:03.350 --> 00:10:08.450
What did you find with the Azure
Media Services? Was it largely

00:10:08.500 --> 00:10:12.590
turnkey, or did it give you an opportunity
to really customize

00:10:12.640 --> 00:10:15.030
your experience and your
usage of the services?

00:10:15.080 --> 00:10:17.680
>> Well, what I liked about it
the most, it was a toolset.

00:10:18.130 --> 00:10:21.300
If it was turnkey, I think it would
have had some rough edges

00:10:21.350 --> 00:10:25.610
that we couldn't smooth off, and
I really like the .NET SDK.

00:10:25.660 --> 00:10:28.200
I'm still not a REST service guy.
I use them when I have to,

00:10:28.250 --> 00:10:31.950
but I like the .NET SDK. I like
how I can link against it, so

00:10:32.000 --> 00:10:35.280
I can do queries like what live channels
are running, what events

00:10:35.330 --> 00:10:38.410
are running? Because Media Service
is all exposed that way in

00:10:38.460 --> 00:10:42.690
the .NET object model, so I really
like that, so we could slice

00:10:42.740 --> 00:10:46.810
and dice the way we wanted to do
it. We're not running one event.

00:10:46.860 --> 00:10:49.130
We're running multiple events,
so we need to be able to query

00:10:49.180 --> 00:10:51.290
things and see how
things are going.

00:10:51.340 --> 00:10:55.610
>> Sure. Did you end up writing
any tools of your own to help

00:10:55.660 --> 00:10:58.560
you produce these live streams
or to manage them?

00:10:58.610 --> 00:11:01.660
>> I do. I have a scheduler currently.
It looks at the database

00:11:01.710 --> 00:11:04.890
of events. It turns the live streams
on or the channels on at

00:11:04.940 --> 00:11:08.850
the proper times. It shuts them off.
It also msn the auto-archiving,

00:11:08.870 --> 00:11:11.630
so after the stream, there's a
workflow where it knows it was

00:11:11.680 --> 00:11:14.840
a certain event, so it takes those
URLs, puts them in the database,

00:11:14.890 --> 00:11:18.580
so we can have the archived content
afterwards, so people can search.

00:11:18.630 --> 00:11:21.920
We also, some of our legacy live
streams that don't use Azure

00:11:21.970 --> 00:11:26.320
yet that we're migrating produce
a 2-gig MP4 file. Right now,

00:11:26.370 --> 00:11:31.040
that's now punted from the location
to blob storage. Then, on

00:11:31.090 --> 00:11:35.170
a schedule, on a web job, we bring
that into Azure Media Services,

00:11:35.220 --> 00:11:37.910
kick off an encoder, and when the
encoder's done, it puts that

00:11:37.960 --> 00:11:39.210
back into the database.

00:11:39.460 --> 00:11:43.300
>> That's fantastic. So it sounds
like these services do a lot

00:11:43.350 --> 00:11:46.420
for you. It must cost you a zillion
dollars to run this type

00:11:46.470 --> 00:11:46.990
of stuff.

00:11:47.040 --> 00:11:51.160
>> It does, but when you take a look
at the people we don't need,

00:11:52.190 --> 00:11:55.710
what it would cost in server hardware
for uptime. The thing

00:11:55.760 --> 00:11:58.270
is, with a live event, you can't
have a problem, because if you

00:11:58.320 --> 00:12:02.350
miss it by an hour, you miss the event.
So we need the scalability,

00:12:02.400 --> 00:12:05.660
redundancy, and it's worth what we
pay for it. The most expensive

00:12:05.710 --> 00:12:06.960
part is the encoding part.

00:12:07.900 --> 00:12:14.830
I've run up to 20,000 viewers on an
event on two medium instances.

00:12:14.880 --> 00:12:15.970
>> That's fantastic.

00:12:16.020 --> 00:12:19.770
>> You have the right caching model
in place, and then the video

00:12:19.820 --> 00:12:23.140
is all coming off Azure Media Services,
and all the graphics

00:12:23.190 --> 00:12:27.160
come off the CDN. You don't have
to kick the crap out of the

00:12:27.210 --> 00:12:29.770
two little instances that are running,
so it's a good model.

00:12:29.820 --> 00:12:30.690
>> That's fantastic.

00:12:31.220 --> 00:12:35.640
So this is fantastic. I love hearing
stories like this that really

00:12:35.690 --> 00:12:39.950
show the power of the cloud and
the real applicability not just

00:12:40.000 --> 00:12:42.940
to big huge corporations, but to
anybody who wants to use it.

00:12:45.220 --> 00:12:49.800
If I were a developer or somebody that
has an idea, a video producer,

00:12:50.150 --> 00:12:53.080
a company that has online assets
that wants to get started with

00:12:53.130 --> 00:12:55.710
this, how do you get going
with this type of stuff?

00:12:56.380 --> 00:13:00.360
Is it a huge learning curve? Are
there ways to get started that

00:13:00.410 --> 00:13:01.800
make the most sense?

00:13:01.850 --> 00:13:04.640
>> Sure, I mean, you can use...
because I'm a tinkerer, I like

00:13:04.690 --> 00:13:07.410
to use the .NET SDK. There's a lot
of things you can do through

00:13:07.460 --> 00:13:10.640
the dashboard, so you can log into
the Azure account and upload

00:13:10.690 --> 00:13:13.880
an asset. So you take an MP4 file,
so take your show. It's a

00:13:13.930 --> 00:13:17.110
20-minute show or an hour-long show
or whatever. You can punch

00:13:17.160 --> 00:13:19.340
it up to Azure, and then you say
I want to encode it, and it

00:13:19.390 --> 00:13:23.950
has options. Do you want to encode it
for iOS playback or PC playback?

00:13:24.000 --> 00:13:26.040
So it's got predetermined
settings.

00:13:26.090 --> 00:13:26.770
>> Perfect.

00:13:26.820 --> 00:13:29.300
>> And then it gives you a URL. And
you can publish it. You can

00:13:29.350 --> 00:13:31.330
publish it if you want to or not.
So when you want to make it

00:13:31.380 --> 00:13:34.440
public, you say publish. Then it
gives you a URL. You take that

00:13:34.490 --> 00:13:38.490
URL, put it into some sort of either
flash player or an HTML5

00:13:38.540 --> 00:13:42.250
video player on a simple HTML page,
and you've got playback.

00:13:42.300 --> 00:13:43.080
>> That's wonderful.

00:13:43.130 --> 00:13:46.400
>> So now you take that one step
further, you create a database,

00:13:47.120 --> 00:13:50.150
so people get a list of your shows.
They click on the show,

00:13:50.200 --> 00:13:53.570
it opens up a webpage, takes
that URL from the database.

00:13:53.620 --> 00:13:54.750
>> Sure. Punts it in there.

00:13:54.800 --> 00:13:55.530
>> And you're done.

00:13:56.410 --> 00:13:58.150
You're now YouTube.
Done.

00:13:58.760 --> 00:14:00.590
>> Wow. That's fantastic.

00:14:00.640 --> 00:14:03.250
>> One thing you want to do, though,
if you get a lot of bandwidth

00:14:03.300 --> 00:14:07.400
on your stuff, you can hook Azure
or Limelight or other CDNs

00:14:07.450 --> 00:14:12.850
to your Azure Media Services. Azure
does have a CDN, but if you're

00:14:12.900 --> 00:14:16.160
an Akamai customer or a Limelight
customer or an Edge customer,

00:14:16.750 --> 00:14:20.820
there's ways to connect that quite
easily to your Azure Media

00:14:20.870 --> 00:14:22.180
Services assets, as well.

00:14:22.230 --> 00:14:26.370
>> Beautiful. There's tons of providers
out there in the cloud,

00:14:26.420 --> 00:14:31.350
like the cloud is full of people,
other folks other than Microsoft

00:14:31.400 --> 00:14:37.110
with Azure that have services to support
the type of media workloads.

00:14:38.360 --> 00:14:42.300
Why would somebody want to go with
Azure versus, say, something

00:14:42.350 --> 00:14:46.650
that's based on another media platform?

00:14:47.170 --> 00:14:50.720
>> Well, what I like, it gives me
all the different pieces I want.

00:14:50.770 --> 00:14:54.790
It gives me great storage, great
elastic storage, so I can put

00:14:54.840 --> 00:14:59.860
as much video up there as I want. I
know the security, the redundancy,

00:14:59.910 --> 00:15:04.010
the resiliency of that data. Then
I have my application front

00:15:04.060 --> 00:15:07.550
end, my website stuff, so I can
build the application. It sits

00:15:07.600 --> 00:15:11.250
in the same sort of spot. Then
I can build my intelligence or

00:15:11.300 --> 00:15:14.340
the media services is there, as
well. So I can sit in Visual

00:15:14.390 --> 00:15:18.340
Studio and build all these layers.
Then, when I'm done, I go

00:15:18.390 --> 00:15:22.020
publish and it's there. That's
what I really like. I can be

00:15:22.070 --> 00:15:24.740
sitting here in a hotel room.
I can be sitting in Iceland.

00:15:24.790 --> 00:15:27.240
If I want to make a tweak, I want
to publish that code up...

00:15:28.180 --> 00:15:31.500
all my code's in TFS on Visual
Studio Online, which is backed

00:15:31.550 --> 00:15:32.400
by Azure.

00:15:33.020 --> 00:15:36.650
So it's a great workflow. Being
a small guy, I don't have to

00:15:36.700 --> 00:15:38.780
have a bunch of guys.

00:15:39.920 --> 00:15:44.150
>> That's fantastic. Now, the one
thing I kind of notice about

00:15:44.200 --> 00:15:46.330
what you're describing is
we talked a lot about

00:15:47.820 --> 00:15:52.460
TFS and .NET and this sort of stuff.

00:15:53.510 --> 00:15:56.420
I know a lot of times, when I'm
talking to customers for the

00:15:56.470 --> 00:16:00.720
first time about Azure, they really
do think it's a Microsoft

00:16:00.770 --> 00:16:04.310
only sandbox to play in.

00:16:04.960 --> 00:16:08.060
Has that been your experience with
the Azure Media Services?

00:16:08.110 --> 00:16:11.940
Is it very much a Microsoft playground?
You've got to learn Microsoft

00:16:11.990 --> 00:16:14.340
programming languages and
Microsoft services?

00:16:14.390 --> 00:16:16.580
>> No. They have SDK for Java.

00:16:17.910 --> 00:16:22.440
Actually, my WordPress blog is
PHP. You can spin up lots of

00:16:22.490 --> 00:16:26.930
different Linux images. The Media
Services is very API driven,

00:16:26.980 --> 00:16:29.770
so it's whatever language you want.
You don't worry about Windows.

00:16:29.820 --> 00:16:32.430
You don't worry about Microsoft.
You work about taking an h.264

00:16:33.070 --> 00:16:37.550
or a video asset and encoding it.
The default encode is for iOS.

00:16:38.630 --> 00:16:39.010
It's HLS.

00:16:39.060 --> 00:16:40.320
>> That's fantastic.

00:16:40.370 --> 00:16:42.610
>> That's Apple's streaming protocol.

00:16:43.580 --> 00:16:47.240
So it's not just for Windows 8
or Windows Phone. The defaults

00:16:47.290 --> 00:16:49.880
are for Android and iOS, so you
can very easily get assets up

00:16:49.930 --> 00:16:52.150
and get them to all those
mobile services.

00:16:52.960 --> 00:16:56.450
>> That's fantastic. So tell me,
what's next for the show?

00:16:56.500 --> 00:16:57.270
What are you planning?

00:16:57.320 --> 00:17:01.900
>> Well, we have just bought plane
tickets to Norway, so we've

00:17:01.950 --> 00:17:05.000
just released our first episode
to Iceland. We've got seven

00:17:05.050 --> 00:17:08.600
more to go, so you'll see us get
more foolish as we get around.

00:17:08.900 --> 00:17:10.020
We eat rotten shark.

00:17:11.160 --> 00:17:13.930
We have some horse
on our plate.

00:17:14.430 --> 00:17:16.620
>> Anthony Bourdain, eat
your heart out.

00:17:16.670 --> 00:17:22.840
>> Then we go. We fish the Mid-Atlantic
Ridge, and then this summer,

00:17:22.890 --> 00:17:26.400
we're heading to the fjords. We take
our DJI Phantom, our drone,

00:17:26.450 --> 00:17:29.670
and we're going to do a road trip
from Oslo to Trondheim, and

00:17:29.720 --> 00:17:33.610
get to the tallest fjords we can
and fly the drone off to get

00:17:33.660 --> 00:17:35.250
some spectacular views.

00:17:35.300 --> 00:17:38.320
>> I can't wait to see that. That's
absolutely very cool.

00:17:38.370 --> 00:17:42.890
Have you got any thoughts about
your future and things you'd

00:17:42.940 --> 00:17:45.740
like to do with Azure Media
Services going forward?

00:17:45.790 --> 00:17:49.630
>> Well, we're really going to try
to simplify delivering live,

00:17:50.650 --> 00:17:53.560
so it's much easier for people
if they want to stream a live

00:17:53.610 --> 00:17:58.600
event and get the archived piece
afterwards, because it can be

00:17:58.650 --> 00:17:59.910
recorded on the back end.

00:18:00.620 --> 00:18:03.640
So we want to push that and make
it very turnkey, but also make

00:18:03.690 --> 00:18:06.280
it turnkey for organizations. So
say you're a university and

00:18:06.330 --> 00:18:10.630
you've got 40 sports. How do you
manage all those points?

00:18:10.680 --> 00:18:14.980
And that's what we're playing with
right now. We have over 45

00:18:15.030 --> 00:18:17.290
different encoders in the field
that all could be going at the

00:18:17.340 --> 00:18:20.600
same time, so how do you manage that?
It's easy to do one stream

00:18:20.650 --> 00:18:24.920
in one event. We're really putting
a management system over top

00:18:24.970 --> 00:18:28.280
of all that and taking away the technology,
so people can do that.

00:18:28.330 --> 00:18:32.440
I want to stream from 7:00 to
8:00, how do I do that? Tick, tick,

00:18:32.490 --> 00:18:35.790
tick, and they can go. So we're really
trying to bring the user-friendliness

00:18:36.000 --> 00:18:40.540
into people to self-broadcast or broadcast
events like baseball, hockey.

00:18:40.590 --> 00:18:41.890
We've done volleyball.

00:18:42.630 --> 00:18:45.090
I was involved in broadcasting
the Canada Games on the web in

00:18:45.140 --> 00:18:51.460
2011, 2013. We had over 400,000
viewers per event, like for the

00:18:51.510 --> 00:18:54.150
two weeks, so it's
been real fun.

00:18:54.200 --> 00:18:57.330
>> Excellent. If somebody wants to
reach out to you and contact

00:18:57.380 --> 00:19:01.440
you about the work you're doing,
what your company does, or even

00:19:01.490 --> 00:19:04.690
just to chat a little bit and share
their experiences, how would

00:19:04.740 --> 00:19:05.480
they do that?

00:19:05.530 --> 00:19:08.780
>> Well, my email is Ryan, R-Y-A-N,
at ryangroom.com,

00:19:10.000 --> 00:19:13.800
or on Twitter at @RyanGroom.
That's that easy.

00:19:13.850 --> 00:19:17.750
>> Wonderful. Well, Ryan, hey, thanks
so much. I really appreciate

00:19:17.800 --> 00:19:23.090
you taking the time. Ryan is based
in Atlanta, Canada, and he

00:19:23.140 --> 00:19:25.730
was gracious enough to come down
to Monckton, New Brunswick,

00:19:25.780 --> 00:19:31.070
today to sit and chat with me and
cut his way through the massive

00:19:31.120 --> 00:19:35.710
amounts of snowfall that recently
appeared. Good luck. I hope

00:19:35.760 --> 00:19:40.240
you enjoy some well-deserved time
off on your trip, and thank

00:19:40.290 --> 00:19:45.220
you for joining us and
watching this episode.