Tip:
Highlight text to annotate it
X
JAREK WILKIEWICZ: All right.
Good morning everyone.
Quick introductions.
My name is Jarek Wilkiewicz.
I'm a Developer Advocate with YouTube.
And here with me is Doug Muir.
He's a Technical Director from Activision.
And we also have Cliff Samaniego and Kenji Arai from
YouTube who will be joining us for Q&A later in this
presentation.
So the agenda for today.
We just went through the introductions.
I will talk a little bit about why would one want to
integrate a game title with YouTube.
And then what is the process of integration, so how do you
actually get that done.
And discuss the one use case in more detail, namely Call of
Duty: Black Ops.
For those of you that are gamers, this game needs no
introduction.
And for those of you that aren't, let me just say that
it was the biggest game of 2010.
And they made an incredible amount of money on that game.
What I would like to start with is a little quiz to kind
of wake you up and see how much you know about YouTube.
I'm sure all of you guys are users, but I always like to
test knowledge of my audience.
So question number one is--
it should be pretty easy-- how many views do we get per day
on YouTube?
Any guesses?
2, 3, 10 million?
1 million.
200 million.
A billion-ish.
OK.
So actually it's over 2 billion.
And this is data from last year.
Next question.
So out of the 2 billion, how many are mobile, so used on
mobile devices?
What do you guys think?
25%.
30%.
10%.
Yeah, it's actually over 200 million.
So it's over 10%.
This number is also growing pretty fast.
Last question.
How much video is uploaded each and
every minute to YouTube?
How many hours?
20 hours.
OK.
Do I have 24?
26.
It's actually over 35 hours.
Which brings us to this presentation because we'll be
talking about uploading videos to YouTube from a game.
So why would anybody want to integrate with YouTube?
First of all, the site is very international.
We have hundreds of millions of users.
And over 70% of traffic comes from outside
of the United States.
So if you want to target global audience, putting
content up on YouTube is a good way to do this.
Gaming is one of our top verticals.
And we find that gamers are very engaged, so they create,
share, discover new content and socialize on YouTube.
And we like that because that really helps drive community
engagement around the content that you put up on YouTube.
As Doug was going to talk about a little later in the
presentation, YouTube gives you a mechanism to promote
your title.
And you can monetize some of that content as well and thus
grow your community, grow the excitement around your title.
So we talked a little bit about why to go through this
process of YouTube integration.
Since we are developers here, let's talk a little bit about
the APIs, and how does one actually do this.
So first of all, to upload a video to YouTube there's three
steps that one has to go through.
First, the video needs to be encoded.
And there are various encoding technologies available.
So I know that two of them here that are quite popular,
H.264 and WebM VP8.
Once the video is encoded, we provide data APIs that can be
used to actually push the video over to YouTube
programmatically.
So again this is not going to youtube.com and uploading this
manually, all we talked about here are the APIs.
And then finally, we have a set of player APIs.
So if you would like to build say a video portal around the
content that you have uploaded, you can use the
player APIs to customize the playback experience.
And I'll talk a little bit more about each one of these
in the following slides.
So starting with encoding.
Some platforms have H.264 encoding built in.
In the case of platforms that don't--
for example, on the Xbox, there was no encoding
available during the integration
process for Black Ops.
We have WebM, which is an open source project.
It is really designed for web video, so it provides pretty
efficient compression and streaming capability.
So you can achieve pretty high quality streaming at
relatively low bandwidth.
So as I showed here, 360p at 280Kpbs
or 720p at 1.5 megabit.
The technology performs quite well on platforms that don't
have hardware offloading.
Some platforms do have it, but they don't necessarily expose
it through the APIs, Mobilis is one case.
It's open source, so you can just fetch it from WebM
Project and try it out.
And typically video file consists of encoded video with
VP8 and audio also encoded.
I wanted to mention Ogg Vorbis which is also an open source
code that you can use to kind of combine the two and create
a video ready for upload.
So we created a video, rendered frames, compressed
it, encoded it, and now we are ready to upload.
So how do we do that?
YouTube offers Google data APIs.
For those of you that haven't worked with data APIs, just a
quick overview.
They are based on REST, so they are very easy to use.
Really designed around HTTP protocols.
Based on ATOM.
We tried to follow a couple of RFC in the API design that
kind of dictate how do you map an object model to a
REST-based implementation.
I mentioned RFCs here.
If you guys have trouble falling
asleep, I recommend these.
They are better than counting sheep.
I actually like reading RFCs myself.
So for me, it's kind of fun to kind of check out how the
design was actually driven by these standards.
And we support XML-based encoding.
So this is the representation of the actual data, as well as
JSON, JSON-C and RSS.
JSON, JSON-C are very relevant for JavaScript developers, but
also in the mobile context.
Where you really care about the amount of information
exchanged, JSON-C is a very efficient
representation of the data.
So that's something that you can request. When you make the
REST request to our API, you can actually tell it what type
of representation you would like to fetch.
The data that we expose is organized as a set of feeds.
Each feed has a bunch of entries.
So for example, video feed will have entries
corresponding to individual videos.
Subscription feed will have entries corresponding to
individual subscriptions.
And applications integrate with the YouTube platform by
basically interacting with these feeds.
So entries can be deleted, created, queried and so forth.
And that's typically how an integration works.
So let's look at a API invocation example.
Since I mentioned that the protocol is based on REST,
really all I need to do in order to invoke the YouTube
API is issue an HTTP get request to our URL,
which I just did.
And I basically asked it to show me all the top rated
videos on YouTube.
And what you see here is an XML representation, which is
the default ATOM representation.
I could have asked for JSON or JSON-C.
Each entry corresponds to a video from this feed.
And there's additional metadata information available
about each of these entries.
So I have a playback URL if I want to play the video back.
There is description, tags and so forth.
So as you see, invoking the API is quite simple.
You can do it directly over HTTP.
We also provide gdata libraries that abstract this
process out.
So if you don't want to do XML parsing or JSON parsing, you
want higher level abstractions, we have open
source libraries for that.
So again, this is kind of zooming in
on one of the results.
What you see here is the feed that's got a closing entity.
And then each one of these videos is
represented as an entry.
I'm highlighting here video ID as one of the important
attributes of this video.
And that's pretty much how one interacts with most of the
gdata APIs, Google Data APIs for YouTube.
So the process of uploading the video really follows the
same pattern.
So how do we actually upload the video from a game?
We offer several upload APIs.
Browser-based API, direct upload API, direct API and
direct resumable API.
The browser-based approach doesn't really apply in our
case here because we are talking about integration from
a game title and installed application.
It is typically used for web applications where you would
like to allow the user to upload a video to YouTube, but
you want to take control over the entire experience.
You don't want them to ever leave your site.
You can use the browser-based approach.
In this case, we are talking about integration directly
from an application.
And for that, we have two set of APIs, direct and direct
resumable uploads.
Really the important difference between these two
is direct resumable, it's very applicable to mobile context
or situations where your connectivity can come and go.
Because what direct resumable uploads allows you to do is if
your connectivity goes down, you can actually pick up from
where you left off.
This way you don't have to kind of restart the entire
upload process.
One thing that is important that I wanted to highlighted
is we have to authenticate in order to upload a video on
behalf of the user.
Historically, ClientLogin was kind of the authentication
method of choice.
But recently the industry has really moved away from
ClientLogin for many reasons and instead has adopted an
AuthSub, OAuth 2.0 or OAuth 2.0 device profile-based
authorization model.
And what that allows you to do is really to fetch a token
that you can use in order to perform API operations on
behalf of the user.
But you never actually have to store the
username and password.
And it's nice not to have to do that because if, for
whatever reason, you encounter any kind of security breach,
the only thing that one could actually obtain is that token
that is only valid for a specific subset of the data
that the user has access to.
And that token can very easy be revoked by the user.
So I wanted to take a little time and talk about OAuth 2.0
device profile, which is something that we have
launched into beta very recently.
The problem that OAuth 2.0 device profile tries to solve
is how do you actually provide a nice user experience on
platforms that typically don't have a web browser.
So what I'm trying to do is I would like to invoke a method
or service that gives me access to a token, which I can
then use to perform API operations on behalf of the
user, but I don't have a web browser on my device.
So say I'm on a gaming console--
some kind of an embedded device, a TV or what not--
so OAuth 2.0 device profile attempts to solve this problem
by really setting up a flow, which at some point takes the
user away from their couch, so they go and use a web browser
in order to obtain the application token or authorize
the device access to their data.
So let's quickly walk through the flow.
So what to see here is on the left hand side, I have the
device client.
So that could be gaming console, TV, some kind of an
embedded device without a browser.
On the right hand side, I have an authorization server, which
is something that we have implemented, and other people
in the industry are implementing that as well.
And the first step of this sequence is that the device
client actually asks the authorization server to
initiate the authorization sequence by supplying a client
identifier.
A client identifier is something that you can
actually obtain through our API console.
So when you actually register your application with Google,
you can say that this is the application name, this is
image or thumbnail that you would like to show to the user
when they attempt to perform an authorization flow.
And then the client identifier is
something you get in exchange.
This is what the device client must know in order to actually
initiate this sequence.
So really identifies the application as well.
So once the client identifier is submitted to the
authorization server, the authorization server returns a
verification code.
So you can think of it as a PIN code that the user can
then use in order to authorize this device to access the
user's data.
And in addition to the verification code, user code
is returned in the verification URI.
The verification URI identifies the place on the
net where the user has to go in order to
complete the sequence.
So what you see is the next step in the sequence is C,
where the user will visit a site--
again that's the site that is identified by the
verification URI--
and authorize access to the user's data upon which the
device will be able to retrieve the authorization
token and proceed.
So while step C is taking place, step E--
the verification code reattempt--
is initiated by the device client.
So it's basically a polling mechanism.
The device will keep polling until the user
authorizes the access.
Then when the user actually authenticates, authorizes the
access, the device will obtain the access token in step F.
And from then on, that token can be used to actually
perform API operations.
So that's kind of the big difference between how things
are typically done with ClientLogin, where somebody
tries to type username and password in front of a TV that
maybe doesn't have a keyboard, or they're on a gaming console
where typically web browsers are really not a part of their
experience because it's not optimized for that.
So this OAuth 2.0 device profile tries
to solve this problem.
So let's look through a quick demo of how this thing works
in practice.
So I built a small application here that performs the
authorization flow.
And I'm using my favorite terminal emulator from the
'80s called Cathode.
So let's just start the sequence.
So what you see here is this part would be executed by the
embedded device, so TV or gaming console or whatever.
The authorization server was contacted.
And the token returned by it is shown and
embedded in this URL.
In practice, we will actually shorten the URL.
So right now you see it's sandbox.google.com.
It's a little long.
We'll come up with something shorter.
But the idea here is that the user will be presented with
this code and the URL.
Then they go to a website actually identified by the URL
and type in the code.
So let's try to do that.
So I followed that URL.
I am presented with a prompt saying, device is requesting
permission to connect with my account.
Hit continue.
I don't need to update.
And then what I see is my application, which I
registered.
So I mentioned earlier that you can provide a thumbnail
that identifies the application, the
title and so on.
So this application is asking for permission in order to
access my YouTube account.
I will grant access.
OK.
Now that I have done this, you have noticed that the polling
has stopped.
So my client application successfully obtained the
authorization token.
And then I will complete the upload.
Yeah.
So this process now performs a resumable upload of a video
that I had on my local machine to YouTube.
That upload was actually done into my account using the
authorization token that this polling client obtained from
the authorization server on my behalf.
So you saw that in this embedded environment that I'm
showing here, there was no web browser.
So doing any sort of user experience based on web
browser wouldn't have worked.
But with OAuth 2.0 device profile, I can actually still
implement that.
So we talked about video encoding.
We have the video.
We uploaded it to youtube.com using the API.
Now let's talk a little bit about player APIs.
And how can we customize playback behavior with our
player APIs?
So we offer three ways to customize the player and the
playback behavior, URI parameter, JavaScript API, and
ActionScript API.
So let's quickly walk through them.
The simplest way to influence how the player
works is player parameter.
So in the top example, I have a parameter
called FullScreen, fs=0.
So by appending this parameter to my embed source, what will
happen is that the user will not have an option to actually
pop up the video in full screen mode.
So again if you are designing an application, which for
whatever reason doesn't want to grant the user access to
full screen playback because you always want them to see
your web application, you can actually do that by appending
a player parameter to the embed.
So it's very simple.
On the bottom, I have an example of
another parameter, autoplay.
What that will do is when the user navigates to a page,
which includes this embed, the video embedded on the page
will start playing right away.
And one thing to notice, the syntax of the bottom embed is
something that we have introduced fairly recently.
It's the iframe embed.
It is kind of the default embed right
now for YouTube videos.
And we have a session about details of this
implementation, how it works, tomorrow.
So we talked about the player parameters.
But sometimes you actually want much finer control over
what the playback experience is like.
And for that, we actually have a JavaScript API and
ActionScript API.
So if you are a Flash developer, you can invoke
methods on the player to start playback, stop playback,
register for events and so forth.
And you can do the same thing with JavaScript.
So here's an example where I'm actually creating an instance
of a player registering to a couple of events and really
what I'm trying to achieve is I want the video to start
playing as soon as someone navigates to the page.
That excuses this JavaScript.
And then I want the playback to stop after 15 seconds.
So let's try that.
Maybe we crank up the volume.
[MUSIC PLAYING --
THE ROLLING STONES, "GIMME SHELTER"]
JAREK WILKIEWICZ: So if you look through the code, really
what I did here is I embedded this video.
This is the video ID that I was showing you earlier in the
presentation.
I registered two events on ready, which is called--
this event gets actually fired when player is ready to
receive API invocations and on state change.
When player is ready, I trigger the video playback.
And upon state change, when the playback starts, I set up
a timer, which will fire and trigger the video to stop
after 15 seconds.
So I can very easily change that to say five seconds.
Let's see.
Nothing interesting happens.
But I think you get the point that you can actually control
the playback behavior through the player API.
So we talked about the APIs and platform
integration and so forth.
So now I would like to let Doug talk a little bit more
about Black Ops.
But first a question.
How many of you guys have actually played the game?
Fair amount, but I see some folks that haven't.
So why don't we look at the game trailer to give you a
little better idea of what the game is all about.
And then Doug will take you through the integration
process that he went through with his team.
[MUSIC PLAYING--
THE ROLLING STONES, "GIMME SHELTER"]
DOUG MUIR: I'm Doug Muir.
I'm a Technical Director at Activision, the company that
published Call of Duty: Black Ops.
And I'm here to talk a little bit about the theater feature
for Call of Duty: Black Ops, and how it
integrates with YouTube.
But first I want to talk about what we were trying to do.
The primary thing we were trying to do with the theater
functionality and allowing people to upload their videos
to YouTube is we were trying to let people share their cool
moments in the game.
You do something neat, you get five kills in a row, you take
out a helicopter with a Tomahawk, you want to tell
your buddies about it.
You want to show them how that happened, how that worked.
And so YouTube is a great way for us to let people share
those cool moments with each other.
In those terms, we were sort of looking at two things.
We were looking to let our existing community connect
with each other and share these cool moments.
But we were also looking to expose Call of Duty to players
who haven't gotten into the game yet.
And we obviously wanted all the reporting and engagement
and analysis that we could get, but we didn't want to
have to build YouTube to get all this stuff.
So the uploading process.
The user experience for it is not the OAuth 2.0 device
profile that Jarek just walked you through.
A, that wasn't available when we did this integration.
And B, as I'll talk about a little bit later, we came to
the YouTube party a little late.
And the game was pretty much baked at that point.
We wouldn't have been able to integrate anything for the
device profile integration anyway.
But here's a short video sort of showing the process for
uploading a clip from Call of Duty: Black Ops to YouTube.
[VIDEO PLAYBACK]
-Hey everyone.
It's Anoj.
And right now I have a tutorial on how to get your
Black Op clips onto your YouTube account
and onto your computer.
And I know some people already know how to do this, but if
you don't, I hope this video is going to be helpful.
The only things that you need are an Xbox 360 or PS3, the
game itself, an internet connection
and a YouTube account.
And the greatest thing about this method is that it
requires no capture card, cables,
wires or editing software.
And most importantly, this process is absolutely free.
I'm going to go step by step, starting with the things you
need to do on the internet and then move on to the things you
need to do with your Xbox or PS3.
The first step is to go to callofduty.com and register an
account there.
Once you do that, go to callofduty.com/theater and
link your gamertag, which will require you using your
Windows Live ID.
Now go back to callofduty.com/theater.
And on that page, click to link your YouTube account, and
then click to allow access to your YouTube account.
If you don't allow access, this whole
process will not work.
Now switch over to your Xbox 360 or PS3, and go into
multiplayer and then into theater.
Select the game play that you want.
And while you are watching that game, find a segment you
want to capture and select record.
[VIDEO GAME DIALOG AND SOUNDS]
-When you have reached the end of the clip segment that you
want to capture, hit record again.
A very important note here, your clip cannot be longer
than 30 seconds, or it will not be uploaded.
Next, you have to name the clip, save it and upload it to
a slot on your Fileshare.
Now get out of viewing the full game, and then take your
clip from your Fileshare, and click select for playback.
After that, you'll notice that the render clip
option is now available.
So click on that.
And then the clip will be opened and
will run through once.
After, you will see a loading screen for the clip, which
means it's being uploaded and rendered to the internet.
After a couple hours, your clip should be uploaded to
your YouTube account and to your Fileshare on
callofduty.com/theater.
This process does take some time, so don't expect your
clip to be there as soon as the rendering has finished.
So in other words, try to be as patient as possible.
[END VIDEO PLAYBACK]
DOUG MUIR: So that's the flow.
And you can see it sort of uses the normal web-based
OAuth flow.
And we'll talk a little bit about the details
a little bit later.
But how did we end up here?
Where we started actually was we weren't
thinking YouTube at all.
We were thinking, OK we have this cool feature.
We can let people share their clips in the game.
And you saw a little bit of that.
We have the Fileshare in the game, and people can download
the clips and look at it from there.
But we wanted to let people share outside of our world of
callofduty.com.
So our first plan was actually we were going to put the clips
available on callofduty.com.
So you could go to callofduty.com, find your
clip, download it, and then do whatever you wanted with it.
Upload it to YouTube, send it your grandma, whatever.
But that's really kind of a horrible user experience.
So the next sort of evolution of our thinking was we would
turn callofduty.com into a video streaming site.
We would serve the videos.
We would have to do some transcoding especially on the
Xbox videos.
Again sort of due to the lateness with which we came to
YouTube, we were not using WebM when the game launched.
We were using Motion JPEG on the Xbox actually because that
was the quickest free codec for us to
integrate with the game.
As we were working through this idea of streaming the
videos from callofduty.com, we started asking ourselves, how
much video are we talking about here?
Call of Duty is a pretty big game.
We expected Black Ops to do very well.
And in fact Black Ops has sold north of 20
million units so far.
As we started thinking about the size of the community, and
how much video we might be taking on here, we realized,
this is not Activision's core competency.
Let's find somebody who does this pretty well.
And that's when we thought of YouTube.
Again, because we came YouTube so late, I think we first
started talking to them about doing this integration
sometime in September for a game that was
launching in November.
We really had no way of doing any sort of
account linking in game.
Because of that, because we couldn't link your account in
game, we wanted to have a good user experience for users who
haven't linked their account.
We didn't want you to go theater, and your first time
trying to render a movie have to tell you, sorry you don't
have your YouTube account link.
You can't upload.
We wanted something to happen even for users who hadn't yet
linked their YouTube accounts, or who didn't want a YouTube
account for whatever reason.
They just wanted to share their video and not will
bother with a YouTube account.
After spending some time talking to YouTube, we came up
with these per-platform Call of Duty channels, sort of
catch-all accounts for people who haven't
linked their accounts.
And we upload the videos to those channels on behalf of
these sort of role users, these fictional users.
And that actually worked pretty well.
So this is how the flow works.
You build your clip on your Xbox, your PS3.
You upload it.
It actually goes to DemonWare, which is the Activision studio
that handles all of the multi-player backends for all
Activision titles.
They handle matchmaking.
They handle stats, backends, everything.
And we go to DemonWare, A, because we did this very late,
and we were already talking to DemonWare.
But B, some of the first parties have some policy rules
about talking to just anybody out on the internet.
So to work around those policy issues, the easiest thing to
do was to just send it to DemonWare first.
Which actually turned out to be very convenient in terms of
account linking.
Because in the user flow that we saw a little while ago for
linking your YouTube account, that token that we get back,
the OAuth token is actually stored at DemonWare.
And it's associated with your consul identity.
So when the video hits DemonWare, they look up for
the user that you're playing as, do they have an OAuth
token for you.
And if so, they upload that video to YouTube under your
account for you.
If not, then they go to one of these shared accounts, which
get a lot of videos.
And all the videos eventually end up at YouTube.
And if you have linked your account, it ends up in the
right place.
And from there, you can watch the videos directly on
YouTube, or you can go to callofduty.com/theater and
find your videos there and watch them there if that's
what you like to do.
So the benefits of integrating for us.
The big one was actually the ROI.
And it's not so much that we made a ton of money from the
YouTube views is that we saved so much money by not having to
build it ourselves.
So rather than having to spend all the money to engineer a
solution for the transcoding and streaming and buildout,
the serving infrastructure for handling what we expected was
going to be sort of a very longtail distribution of
views, we were able to push all that work off on YouTube
and have them pay us a little bit, which was a huge net win.
In terms of user engagement, it's been working very well.
Since the game launched on November 9, we've had over 3.6
million uploads of videos to people's own YouTube channels
and the shared YouTube channels.
Nearly 70 million total views.
And it's something that this is a true community-based
marketing opportunity for lack of a better word.
We get PR.
We get community buzz.
We get people sharing their videos,
talking about the game.
You go to YouTube, and you search for Call of Duty: Black
Ops, there's a ton of videos basically
advertising our game.
It's fantastic.
Here are some of the key insights from the views and
the uploads.
I'm not going to read it.
Some of the interesting ones are the male/female breakdown
is just about what you might expect for a game
like Call of Duty.
Most of the traffic is actually coming from YouTube.
The vast majority of the traffic
is coming from YouTube.
Either people going to the Call of Duty channel pages or
just searching for Call of Duty and finding
the videos that way.
In terms of player behavior, the thing that was interesting
to us was for a feature that--
as you saw from the video outlining how you upload
videos-- for a feature that's kind of buried in the UI,
we've had 580,000 plus players upload videos.
And most of them actually have uploaded more than one.
So it's not something where most players are going in and
uploading one video and then giving up on the future.
Over 80,000 players have uploaded more
than 10 videos each.
And we've got one user who, as of late April, he'd uploaded
over 500 videos.
So that guy's working at a clip of about three a day.
Which we think is great.
I mean that sort of validates our whole thinking in terms of
the feature.
We expected that there would be sort of that creative core,
who would really get into the future and
produce a lot of videos.
But we also wanted to build something that the more casual
user would use.
And we think that the usage stats are sort of
bearing that out.
In terms of views, this slide just blows me away.
Well over 90% of the videos have had less than 100 views
since November 15.
Which, when you think of the average age of the videos,
that's less than one view per day.
There's no way that we would have been in a position to
handle that number of views, building out an
infrastructure ourselves.
Akamai or any other CDN would not have helped with 90% of
the views that we would have had to serve.
So having YouTube and their scale and their serving
capability was a huge win for us.
I mean the number of of videos with over 100,000 views is 36.
The distribution is just frightening for anybody who
would be trying to build a system like this themselves.
In terms of what went right.
I mean like I said, we started this in September for a game
that was shipping in November.
And this was ready to go on November 9 when Call of Duty:
Black Ops hit store shelves.
The way I think about it, it was actually ready on November
8 when the game started launching in Australia.
I mean that was a huge win for us.
The technical support that we got
from YouTube was fantastic.
The API docks and the public forums
answered most of our questions.
The developer support was fantastic when it didn't.
And really once we launched, except for one issue where we
didn't know to watch the YouTube maintenance
notifications--
so there was one window when YouTube went into a read-only
mode, and we didn't know about it.
And so we started panicking because our writes were
failing, our uploads were failing.
Except for that, we haven't had any issues since this went
live in November after 3.6 million uploads.
In terms of what we could have done better.
Looking back, things could have gone a lot more smoothly
had we engaged YouTube much earlier in the process.
Had we done that, we might have been able to figure out
something a little bit more streamlined and a little bit
more user-friendly in terms of linking your YouTube accounts.
And the fact that we didn't have a decent codec on Xbox
kind of hurt things.
Well, not kind of.
It did hurt things.
The Motion JPEG encodings were so large, and because they do
have to go through DemonWare, we just couldn't allow clips
longer than 30 seconds.
And because of platform parity, we couldn't allow it
even on platforms that did have better encoders.
We've since added WebM encoding to one of the recent
title updates for Call of Duty: Black Ops, so we will be
looking at relaxing that 30 second limit.
That's absolutely not a YouTube limitation.
They've been asking us for longer videos since the
feature became available.
That's something we need to work through on our side.
What we learned after we launched was we really should
have had somebody ready to engage the
community on day one.
Because we didn't have a lot of time to really put this
together and build a proper UI around it, we had a lot of
user confusion about uploads.
We had users posting comments on the YouTube channel about,
hey you stole my video.
That's my video.
They didn't understand that when they uploaded the video
without having a linked account, it was going to go to
this shared account that wasn't theirs.
We could have really done a much better job of engaging
the community and educating the community early.
It took us probably two or three weeks to get branding up
on the channels, which probably also hurt the
messaging on that.
You go to this YouTube channel that has all these videos,
some of which are yours.
And it looks like just anybody else's YouTube channel.
It doesn't look like an official Call of Duty channel.
I think that added to the confusion as well.
Really until we did a similar presentation at GDC in this,
we haven't done a whole lot of PR on the feature.
It's kind of buried in the UI.
We didn't really talk about it much with the gaming press.
So we really could have done a much better job of talking
about the feature and really letting people know how cool
it is that they can go into Call of Duty: Black Ops and
make these videos.
Now we're going to see some samples that people have--
these are straight out of the game, straight to YouTube
using the exact mechanisms we talked about before.
I think the first one is an Xbox video, and I believe the
second one is a PS3 video.
[VIDEO GAME SOUNDS]
DOUG MUIR: And this is a Tomahawk killing a helicopter.
[VIDEO GAME SOUNDS]
DOUG MUIR: I've been told to remind everybody that feedback
goes to the URL right there.
The QR code is also a link to the feedback link.
Or you can use the hashtags to give us feedback that way.
And I believe we're ready for questions now.
[APPLAUSE]
DOUG MUIR: Cliff and Kenji, do you guys want to come on up?
Cliff's coming.
Kenji is too cool for it.
Are there any questions?
AUDIENCE: Hi.
That's a good talk.
I'm an Android game developer actually.
Do you have any advice on how one might implement this sort
of thing with Android games, letting users record their
video and share it?
DOUG MUIR: So the question was for an Android developer, how
to implement a similar feature for Android.
Well, the first thing I'll say is the whole bit about
capturing the game play and rendering it out, kind of
falls on you.
I mean that's going to be different for each game.
I don't know what your rendering engine is.
Beyond that though, the upload and the linking with YouTube
actually could probably be pretty smooth on Android
because you do have a browser and even embedded web views
that you could use to do the linking
right inside your game.
So that any user can immediately, the first time
upload straight to his YouTube account and have
it work that way.
If that's an option to you, I would definitely recommend
that because it works.
And it was fantastic that we were able to let people upload
their videos without having to have a YouTube account.
But it did cause all kinds of confusion for, who is this guy
who's got all these videos, and why is he
taking them from me?
So if you can get people to upload straight to their own
YouTube account right from the beginning, that's definitely
what I would recommend.
AUDIENCE: Wow.
Yeah.
Thank you.
JAREK WILKIEWICZ: Yeah.
I would like to add that on Android, you have account
manager, so you can actually obtain the authorization
tokens much easier than what we have demonstrated.
And I see two approaches that people have been trying.
There's already some titles that have this functionality.
One that I kind of like is this little application called
Talking Tom by a company called Outfit7.
My daughter really likes to play with it.
It's basically a cat.
You can talk to it, and it talks back to you.
It actually has a YouTube upload capability.
So you can hit a camera button, and they do the
rendering and encoding.
They push it up to YouTube.
So we get a fair amount of Talking Tom videos.
Then others have been thinking about, can you actually do the
rendering and encoding in the cloud?
So ship the states over to the cloud and do
the encoding there.
You could then be very creative.
You could do it in high resolution.
You could do it in 3-D.
It opens up a whole range of possibilities.
AUDIENCE: Oh yeah.
And the streaming game play events could be very small.
JAREK WILKIEWICZ: Yeah
AUDIENCE: Thanks.
JAREK WILKIEWICZ: Thanks.
VINAY: Hi.
My name is Vinay.
I have a question.
Do you have custom search features on the website?
DOUG MUIR: So the question is, do we have custom search
features on the website?
YouTube doesn't have any custom search features.
We do add some keywords to the videos when we upload them.
Most of the meta-information that we tag is actually with
developer tags.
And we do have plans for using the developer tags that we
attach when we upload the video, but there's nothing
that you can see using that yet.
But there definitely is a way to do that.
All of the videos that have been uploaded have been
annotated with developer tags that we are planning on using
at some point in the future.
AUDIENCE: Hi.
I have two questions.
One is, can you bypass a workaround the browser
verification.
So if you're playing let's say on the PS3, is there a way
that you don't have to force the player out of the game to
go and authenticate his account?
And the second question is, is there any way you can stream
from YouTube to the game?
So again, on the console, like let's say PS3, is there a way
you can take a stream and just play it?
DOUG MUIR: PS3 in Jarek might probably--
Sorry.
The question was, is there a way to bypass the going to the
browser and linking the account?
And also is there a way to stream
back to the game console?
And Jarek might be able to talk a little
bit more about this.
But on the PS3 actually, they do have native platform APIs
for uploading to YouTube and linking your account in the
Xross Media Bar.
So ahead of time or even in game.
Xbox is really the one where that's not available.
And because we are a cross-platform game and trying
to present the same experience across all the platforms we
support, we kind of work with the lowest common denominator.
It's possible now that we've done the feature once that we
would have a different implementation path for PS3
versus Xbox going forward.
But again because of how late this all came together, we
just stuck with a common path for both.
In terms of streaming back to the console, I believe it is
possible, but I don't know if there's any convenient APIs
for doing it.
JAREK WILKIEWICZ: Two quick notes.
So back to PS3.
So the former actually has the capability.
The problem is it still uses ClientLogin for authorization
and authentication, which is something that the entire
industry is really moving away from.
So that is still an open issue.
And for YouTube accounts, you see more and more cases where
ClientLogin will not be sufficient.
For example, if you enabled two-factor authentication on
your account, that might actually prevent ClientLogin
access because the box doesn't implement that flow.
There's a number-- we actually have a blog post about all the
different cases that we know of today that
ClientLogin can fail.
And then on the streaming inside of the game, this is
something that we've been thinking about.
But probably we would need to know a little
more about the context.
So we're going to hang around after this.
If you would like to talk to us a little more about what
you have in mind, then we could
definitely look into that.
VINAY: Thank you.
I have another question.
As I understand, the flow is from the game the video is
uploaded to your backend servers and from the servers
it is uploaded to the YouTube.
So the bottleneck really is how much upload your backend
servers can handle rather than how much YouTube can handle.
So is there a way that you can directly upload to YouTube?
DOUG MUIR: Absolutely.
On the PS3 that absolutely would have been an option.
It's rendered on the console for every platform.
And Sony has no first party limitations about talking to
the internet basically.
Microsoft does have some first party rules about who you're
allowed to talk to from your game.
I don't know if you're familiar with it.
But you have to go through the live service platform gateway,
which ours lives at DemonWare.
So we sort of have to stream through them no matter what.
And again because of simplicity, we just decided to
do it the same way on both platforms. But without that
limitation, we absolutely would have been able to upload
directly to YouTube.
Now the tricky bit in that case though would be knowing
the OAuth tokens because our consoles don't have them.
Those are stored at DemonWare.
So if we were going to be uploading directly to YouTube
from the console, we would have to have some mechanism.
Probably when you log into our backends, we would then have
to send the console your OAuth tokens so that the console
could go directly there.
So going through DemonWare did impose a bottleneck on us.
But it also gave us a single point where we could store the
OAuth tokens and deal with all the upload logic
and work that way.
VINAY: Sorry.
If I may extend.
The question was mainly in terms of the infrastructure
that you need to have. Right?
So probably one of the reasons that you went with YouTube is
that you don't have to have the whole lot of
infrastructure.
But still you have to have a scaled-down version or-- and
so was that--
DOUG MUIR: Well I mean yes and no.
I mean, Call of Duty already has a fairly large backend
infrastructure just because of the size of our community.
I don't know how much I'm actually allowed to say at a
public place like this.
But suffice it to say that there are hundreds of
thousands of Call of Duty matches going on every day.
And so we already have a fairly large infrastructure
for dealing with that.
The video bandwidth is actually not a large part of
what's going on.
It's only a bottleneck because of all the other bandwidth--
because of all the other traffic hitting our backends
just as part of running the Call of Duty
multi-player service.
VINAY: Thank you.
DOUG MUIR: Any other questions?
AUDIENCE: I'm not sure if I missed this.
But is there going to be a way for users to authenticate
themselves, to upload videos that's not ClientLogin and
doesn't require a browser?
DOUG MUIR: So the question is, is there a way to authenticate
for uploading videos that's not ClientLogin, that doesn't
require a browser.
And as far as I know, the answer to that
right now is no.
JAREK WILKIEWICZ: My guess is in the future there will be.
Because ultimately that's probably what you would want.
DOUG MUIR: Yeah, I mean, we would love it absolutely.
But right now I don't believe there is a way to do it that
doesn't involve a browser at some stage.
JAREK WILKIEWICZ: I think when it comes to kind of
standards-based solutions that we've been tracking, I don't
see anything.
So the OAuth 2.0 device profile in beta is probably
the closest we've gotten to something that takes you away
from the device in the standards way.
You could certainly think of a proprietary mechanism to
achieve that.
We haven't been taking advantage like of people's
smartphones, for example, for that.
So there's many mechanisms that one could envision, but
when it comes to kind of standards-based approaches, I
don't see anything right now.
DOUG MUIR: The good news is that with OAuth 2.0 device
profile, you could do it all without leaving your couch if
you have a smartphone or something like that, which
will be an increasingly common use case.
AUDIENCE: Because I guess that's kind of one of the
reasons why, despite its insecurity, people still use
ClientLogin because ultimately it does-- from the user's
perspective, it does make it flow a little bit more
straightforward.
Right?
But then of course there's the security.
JAREK WILKIEWICZ: Right.
Yeah.
But less secure.
Right?
DOUG MUIR: And the problem with something like
ClientLogin--
the potential problem would be, you don't necessarily want
to be storing those credentials on the console.
So now you're asking the user to log in every time
they want to upload.
Whereas with the OAuth solution, we do
that linking once.
And then until the user revokes those tokens, we can
use them to act on the user's behalf.
JAREK WILKIEWICZ: One thing that I didn't cover in the
flow is actually OAuth has a way to refresh the token.
So you don't actually have to go through the entire flow.
There's a refresh token that can be stored on the device.
And then when the access token expires or is close to
expiration, it can actually do the dance again.
And typically the ClientLogin tokens, their life
may not be as long.
So then you have to renew it or refresh it.
But in order to do that, you either have to prompt the user
again, or you keep their credentials.
And storing their credentials is always--
I mean, any developer that builds these types of
applications tries to avoid it as much as fire because
there's so many things that can go wrong with if you store
their credentials.
AUDIENCE: I had a question for you, Doug.
You said that you guys were using a lot of the metadata in
terms of adding developer tags and looking forward to new
ways to engage those videos that users have uploaded.
My question was, how much optimization did you guys do
in terms of search terms and keywords that users might be
looking for for the videos as they were uploaded?
So were you guys thinking about how people are going to
find these videos on YouTube?
Or was it just kind of like they name it whatever they
named it, and then it goes up, and the Call of Duty community
creates the browsing structure for its own community to find
those videos?
DOUG MUIR: Right.
So the question is--
if I were to paraphrase--
is, how much optimization have we done on the keywords that
we attached to the videos as we upload them to make it
easier for users to find videos.
And the answer to that unfortunately is almost none.
We upload your title that you attach in the game.
We attach your gamertag to that as well.
The developer tags, which we have some plans for, but we're
not using yet, do contain a little bit more information.
Things like other users in the videos, the map, the game
mode, things like that.
But those are not visible to the YouTube channel.
But yeah, in terms of that-- and that's sort of another
place where we probably should have been a little bit more
ready in terms of engaging the community.
We could do a whole lot on our backend when we upload to
organize channels, organize playlists and really curate
our channel.
And right now, we're not doing really any of that.
I don't know who has worked in the game industry before, but
there's always something else that seems higher priority
than those sorts of tasks.
So hopefully we'll get to it.
AUDIENCE: It seems like you guys are doing
pretty good, so--
DOUG MUIR: Yeah.
JAREK WILKIEWICZ: I would like to add one thing is, even
though, as Doug mentioned, there wasn't necessarily a lot
of emphasis on optimization, if you go back to the slide
that he was showing where most of the views were actually
from YouTube.
That means that users were able to find their content.
And in fact when we were looking through the data, it
looked like a lot of the views were actually related videos.
So when you watch a video on YouTube, at the end we show
related videos.
So we were able to still kind of figure out what is the
content relevant to these uploads.
And then keep them within this set of videos.
So in the end, it worked out even though maybe it wasn't so
[INTERPOSING VOICES]--
DOUG MUIR: I think we could do more to support it and more to
sort of curate our YouTube channels.
But we're fantastically happy with it so far.
JAREK WILKIEWICZ: All right.
We have two more minutes.
So if there are no more questions, thank you very much
for coming.
Enjoy the rest of Google I/O.
Thank you.
DOUG MUIR: Thank you.