Wilkiewicz: Hello, everyone. My name is Jarek Wilkiewicz,
and I work for YouTube. I'm a developer advocate.
Um, I have Greg Schechter and Jeffrey Posnick
here with me today.
And, uh, we'll talk about, uh, YouTube iframe player
and the future of embedding.
So thank you very much for coming.
Um, there's another one offered today.
Um, we will talk about,
you know, what the iframe player is
and why we introduced it.
Really what is the problem that we were trying to solve?
Um, Greg will cover, uh, HTML5 Video Playback,
some of the challenges that he has faced
implementing the player,
as well as the actual API, um, design and implementation.
So if you're thinking about introducing
you're own JavaScript-based API on top of an iframe,
he'll highlight some design choices
that--that you might consider in your own designs.
Uh, we'll talk a little bit more about, you know,
what are the differences between the, um,
iframe JavaScript API
that we expose now
and the existing ActionScript 3 JavaScript API,
and what this means to application developers.
And then finally,
Jeff created a very nice sample player application
for this occasion.
And he will walk you through the implementation
of--of his HTML5-based, uh, video player,
so that you could reuse that code
in your own applications.
Uh, before we start,
um, if you would like to live-tweet about this session,
here are the hash tags--
#io2011, #YouTube.
And then we would like you to submit some feedback for us.
The QR code is right here
and the show uplink as well on this page.
So, uh, you know,
this is the summary of the session, really.
Uh, you know, what we're trying to do
is--is to let the embed, not the embedder
figure out the complexity of web video.
Uh, so as you all know, what we're facing
is really a platform- fragmentation problem right now.
There's a lot of new platforms,
new operating systems coming online,
especially in the-- in the mobile space,
so then in order to provide,
um, platform-independent portable video playback,
uh, the embedder actually is facing quite a few choices.
And we're trying to simplify this complexity.
So, uh, as I mentioned, both--
you know, we see new platforms, and the encoding standards
supported by these platforms also vary.
So we have H.263 to H.264,
uh, WebM VP8, and so forth.
And then the actual embed technology
also, um, is different depending on the platform.
So historically we had AS2--AS2.
Um, there's some RTSP streaming support for feature phones
that we still have, AS3, HTML5.
So all that actually adds complexity
whenever one wants to include video in a web page
or web application or a native application.
So the problem that we're trying to solve here
is to really provide a simple embed
that will work across all the range of platforms
and hopefully future-proof the embed,
so once you embed a video in your application once,
as new platforms come online,
we'll take the responsibility of making sure
that the video playback is really designed
for that platform, works well,
and you don't get a black box saying, you know,
you need to install this or that plug-in and so forth.
In the lower left I have a syntax example
of the iframe player,
so for those of you who have used it before,
it should be pretty familiar.
For those of you that haven't, one thing to notice--
there's nothing here
about the underlying video implementation technology.
So just by putting that snippet of code
in your web application, web page, whatever,
uh, the only thing it instructs us to do
is to actually choose
the optimal video playback technology
for your device
with an encoding that your device can actually support
and play the video back,
so you really don't have to worry about the complexity.
Uh, so next we'll talk a little bit more
about the design decisions
that drove the iframe player implementation,
as well as, you know, how we ended up
exposing the player API to application developers,
much like what we have done
with the Flash player in the past.
So now I will hand it off to Greg,
who--who will dig into the details.
Schechter: Thanks, Jarek. Uh, so I'm Greg Schechter.
I'm one of the engineers that works on the HTML5 player
and the iframe embed.
And, uh, you know, HTML5-- it's new. It's awesome.
You've been seeing all these cool demos.
But Flash has sort of been in the business
for quite some time.
Uh, so we kind of wondered, like,
why should we build this HTML5 player?
We've got this great Flash one.
Uh, you know, what makes HTML5 better?
And so we looked--we took a look at, like, both platforms,
and we looked at performance, accessibility,
something I call "device-ability,"
and all sorts of things,
and tried to compare the two, uh, platforms.
So the first thing we sort of looked at
is, like, the different features.
Uh, what does Flash provide,
and what does HTML5 have as well?
So one of the first things that's really important
that Flash has was robust video streaming.
In order to provide
this really great, excellent user experience,
we need to have, uh, fine control over buffering
and being able to change the quality.
Uh, we also want to be able to jump
to any part of the video, when the user's seeking.
And HTML5 doesn't quite have this fine-tuning yet.
Another important thing is content protection.
Uh, we don't own all of our contents.
Uh, you might have heard
that, uh, we just launched all these great video rentals.
And, uh, we've got to make sure that our content is secure.
And so, uh, Flash has a protocol for this,
RTMPE, that's, like, built in, easy to do.
And HTML5 doesn't have
an accepted standard for this yet.
After that, the sort of full screen--
uh, when I'm watching my favorite cat videos,
one thing that's really important
is I want them full screen and in HD.
And, uh, we-- we don't really have
an API to do this yet.
WebKit does have something in its nightlies.
And, uh, and the code for that is actually pretty simple.
It works pretty well.
Uh, and so it looks a little bit like this.
You can grab any elements.
Uh, so in our case, we'd grab our video player.
And we would request that it goes to full screen.
And then once it gets triggered,
we can do whatever we want with it,
you know, make it larger, change our buttons,
and--and so forth.
And so eventually, because this is in WebKit,
this will be available in Chrome hopefully very soon.
Uh, another thing that's important
is camera and microphone access.
A lot of our users come to-- come to YouTube,
and they just want to film, uh, talking to, you know,
the--the millions of viewers, uh, right there.
And, uh, HTML5 doesn't have this yet.
Uh, but Flash-- you know, it's there.
Another interesting thing is formats.
So with Flash, it's pretty much gonna--
if--if the device supports Flash,
you can play your Flash videos without any issues.
Uh, HTML5--we actually have to support
two different formats. We have H.264 and WebM.
And so browsers, uh, some browsers will support both.
At the moment, Chrome will support both.
But you know, then you get browsers like Firefox,
which will only support WebM,
and IE, which will only support H.264.
Now we have, uh, all of our videos are encoded in H.264,
and most of them are in WebM at the moment.
But it's taken a while, 'cause it's such a large database
to get through and make all these additional encodings.
Uh, so now why is HTML5 so great?
And, uh, it's--we've got this open-source technology--
open source browsers, players, and codecs,
which really allows for some great, uh,
development in the space,
and making it really fast-paced and changing really quickly.
It also should have lower latency
when we're watching these videos.
We don't have to start up this plug-in.
It's just native in the browser. It should be a lot faster.
And this is really evident, uh, in the iframe,
which I'll--I'll show later.
And, uh, so we're--we're hoping for better performance,
uh, with these different encodings.
Uh, we were hoping to get better performance for the videos
and just fidelity.
Just it works smoother without worrying
about our code screwing up the video playback.
Another great thing is accessibility.
And, uh, there's a few other accessibility talks here
that go into some really detailed stuff here.
Um, one of the--the talks that happened earlier
which was great was all about captions.
And, um, you know, I really like having captions
on my--on my cat videos.
This is one of my favorite comic strips there.
But, um, so one of the features that's important to me
is actually navigating, uh, in the browser.
And because it's native,
I can just tab around in the page.
So let me show you a quick demo.
Um, so this is the--
you know, this is YouTube, and I got the Flash player here.
And I start tabbing around the page,
and, uh, eventually I'm trying to get into the player,
but I just sort of jump below it, and I'm--
my tab focus is down here at the moment--
um, and I can't get into the player.
But if I click my mouse on it,
um, you know, I'll-- I'll give focus to the player.
and then I can tab around and use the controls,
um, but I'm trapped. I can't get outside.
I can't start to interact with the rest of the page again.
One of the great things that's great about HTML5
is, uh, I can tab around in the page,
and then I can jump right into the player,
and I can use my keyboard to start playing the video.
Um, and then if, you know,
I want to move on to the rest of the page,
I can just continue to tab around,
and, uh, and I'm out interacting with the page again.
And so, um, you know, different user agents
are gonna have, um, have to build, uh, APIs
for having these-- this special video handling,
uh, for these-- for the video tag.
Um, but then screen readers, any screen reader you have
will be able to access that,
and you'll have, you know, accessible videos.
Uh, so next thing I want to talk about
is device-ability.
And that's--basically what I mean by that is
where do these platforms that work in Flash--
where can you watch Flash videos,
and where can you watch HTML5 videos?
And at the moment,
when we look at our HTML5-capable browsers,
uh, you know, we've got just under 40%
of, uh, of browser usage is HTML5-capable.
Uh, Chrome is really kicking butt
in this space as well.
And a very small percentage of this is mobile.
So the world kinda looks like this.
There's all these places that support Flash,
uh, a good chunk that also support HTML5,
and this tiny sliver--
and this is exaggerated a little bit--
that only do HTML5,
and that's mostly iPhone and iPad.
There's a few other random things
that are in there as well.
Uh, but then what's really interesting
is when we look at actual usage of people
who are getting access to our APIs,
our YouTube APIs, and where they're playing videos,
uh, it actually kind of shifts opposite.
Uh, most of the places are actually on devices
that don't have Flash.
Uh, so that's, like, you know, really great
that, uh, we need this HTML5 support there.
Uh, so we were asking why HTML5,
but it's really about when we should be using HTML5,
uh, 'cause we clearly see that it's--
it's needed in many places.
Uh, so our first primary goal about building this player
was we wanted to recover playbacks
that would have been lost without Flash.
And so our solution for this, uh, to make it real easy,
was to have this iframe embed.
So you know, like we showed earlier,
the code for it is very simple.
You just plop in the-- the video ID,
and, uh, and you're good to go
without having to worry, uh, about anything.
And so this has, you know, great advantages,
because it gives our user HTML5 or Flash
based on the device and the user's preferences.
It allows for so much better mobile support.
And it gives us this "just works" experience.
Uh, so just a little bit about how you would get
the HTML5 player.
Uh, at the moment, you can opt in,
uh, to getting the player.
And if you go to youtube.com/html5,
you can join the experiment.
And if you're trying to view these videos on a device
that doesn't support Flash,
you'll also be opted in automatically.
And, uh, so the first thing we do is we check,
all right, does your browser support HTML5?
And the code for that is pretty simple.
We just create a video tag, and we see--
can we play the two formats I mentioned?
Uh, so the first one is H.264,
and the second one is WebM.
Now not a lot of our, uh,
not a lot of our embeds actually get clicked on to play,
so we don't load all the data about the video yet.
So we don't know if we have both formats,
uh, when we-- when we load the video.
Uh, so that's why we have to check both at the start.
Um, after that, we wait for the user to click play.
We fetch this information.
And then we say, all right, are there any business reasons
that we can't play the video,
um, the details of which are not all that important?
Um, but if we--if it's great, if we can play this video,
then we're gonna look and we'll see,
do we have, uh, a format that's available,
uh, that this browser can play?
And if yes, great, we're winning.
Otherwise we're gonna fall back.
We're gonna go to that Flash player,
or we're gonna fail out if your device doesn't support it.
Uh, so the next thing-- once we have these two players,
we can look at performance between the two.
And, uh, so the first thing we-- the first one--
pretty much one of the most important things
is the player start time.
And this is the time, uh, just so that it looks
like the player's happening.
Uh, maybe you--like, on the main page you see,
like, the little loading icon,
or at times you'll see the thumbnail,
um, on the-- on the iframe embed.
And so you know, it's the first cue that the user has
that's something's working, something's interacting.
And at the moment, we can see HTML5
is just a lot-- you know, a lot faster.
It's a full second-- a full half a second faster,
which is great.
Um, and so I pulled out, like,
this little, uh, strip line thing
that--that's got all these photos.
And this was in a controlled environment,
and the times got exaggerated a little bit.
Um, but the comparison is pretty accurate
about how much faster the HTML5 player is
just to show that initial thumbnail.
And so, uh, I want to-- I want to show you it,
uh, in action now.
So I've got, uh, the two players here.
The top one's the Flash player,
and the bottom one's the HTML5 player.
And, uh, when I reload the page,
we can see that the HTML5 player comes in a lot faster,
which is great.
And then when I actually go to play the video,
uh, sometimes... Chen: Hi, everyone,
My name is Steve Chen. Schechter: Um...
Chen: I'm one of the co-owners of YouTube, and I run
the engineering team here. Schechter: I don't know.
Stearns: Hi, my name's Jeff Stearns--
Schechter: I don't know what's going on
with the Flash player today, but that's another reason
I like the HTML5 player more. [laughter]
Schechter: Um, but you can see that the, um,
the HTML5 player started a little bit faster.
And I actually think that I just got lucky there,
'cause a lot of times
the Flash player will start first,
um, so we're still sort of tweaking performance on our end.
Um, one of the advantages that the Flash player has
is because all the formats are the same,
it sort of can take advantage of caching those formats
a little bit better.
Um...
Uh, so the next thing is, like, you know--
that I want to talk about is the details
of our new JavaScript API
and how, you know, you control the player.
And so since we have this new--
this new way to embed videos, this iframe embed,
you know, we had to write a new API to interact with it.
So the most important thing was about communication.
We don't have this object in the--
we don't have an object in the DOM anymore,
uh, that we could just, like, add things to directly.
So, uh, we had to think of a way
that this API could communicate with the player and this iframe.
So the first thing we thought of
was to pull the URL fragment.
So that's just a little, uh, fragment at the end of the URL.
And you can--you can update it.
It won't cause the page to refresh.
And there were a couple problems with this.
Uh, the messages are very one-dimensional,
so it's hard to send complex messages.
Uh, polling is gonna eat up your CPU,
and it's not gonna be instantaneous,
uh, 'cause you're being--you're gonna have to set a timer.
And, uh, then you have, like, of different timers conflicting,
and it's just a little bit of a hassle to manage.
Uh, and then the really difficult part
is since both directions of communication, uh,
sending messages to the player,
and the player sending messages back out the page--
have this--have to use the same fragment.
And so then you run into issues--all right, our--
you know, am I reading data, or am I writing data?
Am I overwriting data I haven't read?
And it just gets very complicated.
Um, so instead we decided to use the postMessage API.
Now this isn't available in as many browsers
as just being able to pull that fragment,
um, but it works a lot simpler.
And the majority of our-- of our users
will be able to use, um, postMessage
to communicate with the player.
So it's very simple.
Uh, basically you have a window.
You just send a message,
um, and you specify the-- the target of your message.
And so, uh, we basically can use JSON
to encode and decode our messages,
so it's very native to the browser.
Uh, we don't have polling anymore,
uh, so we can use the native event listeners to communicate.
And, uh, the communication is sandboxed per window.
So, uh, you know,
they're using different channels,
but now all the messages
are being sent to the parent windows.
So if you have multiple players on the page,
it gets a little complicated, but we were able to, uh,
easily, you know, differentiate between the different play--
iframes on the page.
And one interesting thing is the calls are now asynchronous,
uh, so if you wanted to read data from the player,
uh, you know, you might have to wait some time.
so instead we just store the player--
the player state for you.
And so when you interact with the player,
you'll get those--you'll get that data that you want,
uh, right away.
Uh, so now I'm gonna hand it back over to Jarek,
who'll talk about, uh, comparing the iframe API
to the AS3 player API. Wilkiewicz: Thanks, Greg.
So Greg went through the design decisions
that went into the API implementation.
And I wanted to talk a little bit about, you know,
what this means for an application developer
that is used to interacting with our player API
in the AS3 world
and what the differences are,
how you can take advantage of the new API
and what other things to watch out for.
And then, you know, to prove that it is in fact possible
to use the API and create very interesting experiences
around YouTube Video Playback,
Jeff is going to follow up with his example
after my, uh, part.
So for those of you that have worked with the player API,
uh, you know, this is very straightforward,
but I just wanted to refresh your memory.
So there are three ways in which YouTube Video Playback
can be controlled by an application developer--
through player parameters, ActionScript API,
and JavaScript API.
So let's walk through the three mechanisms
and see how they differ if you are interacting
with the Flash versus HTML5 player.
Um, so when it comes to player parameters,
there's really two cases.
One is--down the line video implementation
is based on Flash.
And again, the decision that drives this
is something that Greg has described before,
so he had this nice, uh, decision tree
that was deciding whether to, uh,
start HTML5 Video Playback versus Flash Playback.
So if it's actually Flash Playback,
then all the player parameters
that you are used to taking advantage of--
it's just passed through.
So they work just like before.
And here's an example of a player parameter.
This one will trigger the video to start playback
as soon as somebody navigates onto a page
where the embed is present.
Uh, if the underlying implementation
is based on HTML5 video,
then we are subject to some of the limitations,
uh, that Greg has described
as well as some of the features
that we haven't frankly implemented quite yet.
Uh, so here's a-- you know, an overview
of things that, uh, are-- fall into these two categories.
I'll just walk through them quickly.
Uh, one thing to watch out for, um, on iOS
is the autoplay player parameter.
It's not really honored, so if somebody embeds a video,
and then an iOS device navigates to it,
uh, then the user actually has to confirm
the playback selection.
And I guess it's just to protect somebody's data plan
from getting taxed.
Even though the application developer
would like the video to start playing right away,
iOS will not let that happen until the user selects play.
Uh, caption support--
our HTML5 player does display captions,
but there are some categories that we haven't implemented yet.
For example, the ASR captions are not, uh, shown yet,
but this is something that is under active implementation.
Uh, full screen support
is not quite there yet.
Uh, the limiting factor here is the browser standardization.
And Greg mentioned, uh, the work that is done
for WebKit to make that available,
and hopefully you will see that across the board,
but don't count on it yet.
Uh, annotations--another very popular YouTube feature,
is not implemented by the HTML5 player.
Uh, I expect Greg to start doing that
as soon as he gets back to his office after this session,
because it's a very popular feature.
People have done amazing work with it.
And then finally, related videos--
uh, you know, if you watch a YouTube video,
uh, at the end of the playback you will see a bunch
of videos that we think are of interest to you.
Uh, that functionality can be disabled,
uh, through the rel parameter.
Uh, that is something we don't have in HTML5 player yet.
Um, so next let's talk about the ActionScript API.
So--so for those of you
that have built, um, custom Flash players,
um, what typically people do is--
we actually offer a Chromeless player
that is based on, uh, AS3.
That player has an API that can then be used
in a Flash application.
And then you can build your own experience
around the core YouTube Video Playback experience.
So if you don't like, you know, the way our controls look,
any kind of aspect of the user experience,
you have full control over that, and just invoke API methods.
So, uh, you know, for the purpose of this talk,
this is not, you know, entirely applicable,
because, uh, we're talking about the iframe API,
and the only API that we expose to the iframe
is actually an HTML, um, JavaScript-based API.
One thing to note is, um...
you know, in the new world of mobile devices
that may not necessarily support, uh, Flash--
you know, iOS is a good example of that.
For those of you that are building applications
that get mobile use, you know, you probably noticed
that this is a very nicely growing area.
For everybody, mobile applications are quite hot.
Uh, so you know, if you invested time
in building a Flash-based player
around our Chromeless player,
the bad news is some platforms will not support it.
So all you will get is a black box.
Uh, so it's a little bit of a bummer.
Jeff has a remedy for that,
as he will show later in the session.
But this is one of the things that--that you run into,
and very quickly if you actually build mobile applications.
And people that have devices
that don't support, uh, the Flash technology
actually navigate to your page
that has a very nicely crafted custom player
that you have built that-- you know, it no longer works.
Uh, so you know, instead of that,
what you can do is use our JavaScript API
for the iframe player.
And, uh... whoops.
Um, let's just quickly go through the differences
between the AS3 JavaScript player API
and the iframe JavaScript player API.
So there's three operations, three categories
that I would like to describe-- the player init,
the actual methods that we expose,
and the event handling.
So player init is quite different
between the, um, AS3-based player
and the iframe player.
I have a side-by-side example.
Hopefully you can see that.
But, uh, really, on the left-hand side
you see the new, uh,
JavaScript-based API usage
that we exposed.
You can load the API library asynchronously
and then create instances of YT.Player,
which is really the player object
that allows you to then control the player behavior.
When you instantiate the player, you can specify a video ID
that you would like to load, as well as any player parameter
and, uh, event handlers.
So there's a set of events
that we allow application developers to subscribe to.
If you would like to do that,
you can actually specify the handlers for these events
right when you instantiate the player.
And on the right-hand side, this is the, uh,
old-school AS3 JavaScript API initialization,
uh, using the SWFObject
to load the Chromeless player library.
And the event handling is actually done
through DOM event registration.
It's slightly different.
Uh, that method also works in--in, uh,
the iframe player JavaScript API,
but now we have a convenience way of--
convenient way of creating the handlers
right when the player is instantiated.
Um, so when it comes
to the actual core player functionality,
um, there is five kind of major groups
of operations that we expose.
So queuing functions would allow you to load video, queue video.
Uh, playback controls, player settings--
you know, you can set the volume of the player,
navigate to a specific time stamp in the player.
Uh, playback status operations
that tell you more about, you know,
the actual--what's happening in the actual video.
Uh, playback quality-- so you can actually, uh,
override the selection that we make
on behalf of the user, um,
when it comes to, you know,
what is the optimal, uh, resolution
that we should be trying to, uh, stream to the user.
So, uh, by default we actually try to detect, you know,
what is the device capability? What is the size of the window?
And then, you know, for example, if HD doesn't make sense,
we won't be trying to ship HD--HD.
But if you want to override it,
you can do that programmatically.
Uh, and then finally, uh, we provide
some additional metadata information,
such as the duration of the video,
the embed code for the video through the API.
So comparing these two groups of operations,
really everything works pretty much the same.
Uh, the playback status is the only area
where we still have some work to do,
so right now the getVideoBytesTotal
returns a hard-coded 1,000.
Uh, and that is hopefully going to change in the future.
But other than that, you know,
all the other operations pretty much work the same.
Um...
So a quick note about event handling.
Uh, as I mentioned previously,
uh, the way you initial-- initialize the handlers
is slightly different,
uh, but the actual, uh, semantics are very similar.
The only note that I wanted to make
is that, uh, today if you are counting
on the YT.PlayerState.BUFFERING event
or the state to be actually delivered to you,
we don't actually generate that yet in HTML5 player.
So if the underlying video playback
is based on HTML5,
you will never actually see that, uh, state.
Other than that, uh, there are some, you know,
syntactical differences
with respect to event registration.
So the AS3 player API
relied on the kind of typical DOM-based registration,
whereas for the HTML5 player API,
uh, what we recommend is using the event registration
that is conveniently possible through--
as a part of the player init.
And, uh, one note that I wanted to make
is that if you would like to, uh, kind of play around
with the API,
for those of you that have used Chrome Console,
uh, you know all about it.
But for those of you that haven't,
uh, you can very easily, you know, learn more
about, you know, what these, uh, methods are
and, uh, invoke them and so forth,
using the console right from the browser window.
Just again, a quick way to get up to speed
on, you know, all the functionality
that is exposed.
And I believe we have actually a session about, uh,
Chrome Dev Tools at I/O.
So if you haven't caught it, that's a good recording
to catch up on later.
Okay, uh, next I will hand it off to Jeff.
And Jeff will talk about his experience with the API
and prove to you that you can in fact build
very interesting video experiences around YouTube
using the new, uh, JavaScript API
and HTML5 Video Playback.
Posnick: Thanks, Jarek. Um, so I'm a member
of the YouTube API developer relations team.
And part of my job
is to help developers use these APIs,
so I certainly wanted to familiarize myself
with the iframe player API.
And, uh, this example application
I'm gonna show off
is, uh, something that I did
to get familiar with the API,
but also, um, just hopefully something
that will help you guys learn.
And I wanted to share some best practices
that I picked up while writing code
that hopefully I'll be able to share with you.
So this example, uh, provides
basic YouTube feed player functionality.
Uh, and what I mean by that-- uh, think of it
kind of like a playlist player,
but instead of only playing back YouTube playlists,
you can play back any feed of videos.
And it's powered by the YouTube Data API.
Uh, this is kind of a separate set
of restful APIs
that can be used for interacting with YouTube
in a variety of ways.
One of the ways is to retrieve feeds of videos.
So you can, uh, for instance,
plug in a search term
and get back a list of all the videos
on YouTube that match that search term,
or you can get back a list of videos that are uploaded
in given users' accounts, for instance.
So this particular example,
uh, makes use of some modern web technologies,
as you might expect.
Uh, there's a bit of HTML5 in there.
Uh, a lot of JavaScript is going on under the hood
for interacting with the iframe player API.
And you know, there's some CSS as well.
And, um, hopefully, you know,
as I said, this is useful in its own right.
Feel free to take a look at the code
and, uh, you know, use it and adapt it
in your own applications.
But you know, my main purpose was to illustrate,
um, some iframe player usage best practices.
So I just want to talk in a little bit more detail
about the different components that go into this demo.
Uh, obviously on the HTML5 side of things,
the video element is quite important.
It can be used for the supported videos.
And this again is based on that kind of flow chart
that Greg was going over earlier.
Um, so assuming a given video that we attempt to play
can be played back in the HTML5 video element,
it's going to use that.
And we're actually using some of the player parameters
that Jarek was talking about,
uh, in this case specifically
the controls=0 player parameter.
So this is gonna give us a version
of the, uh, YouTube HTML5 video player
that doesn't have a type of--
I guess "Chrome" is the term that we use for it.
It doesn't have the standard play button.
It doesn't have the seek bar.
It just gives us the video playback.
And, uh, you know, we're going to actually implement
the specific playback functionality
in HTML5 and CSS and so on.
So, uh, to that point we're using SVG,
which is scalable vector graphics,
and that's just used in a fairly straightforward way,
just for implementing the pause and play buttons
in our example.
And we're making use of .
Uh, this is a fairly new input element
that can be used for doing scroll controls,
more or less.
So, um, you'll see it in a little bit
when I show you the example.
But this is something that allows you to drag
and select a new value for a given control.
So Google Chrome currently supports all those features
that we're using, which is great,
because that's what I'm using to demo this.
But, uh, some browsers offer just a subset,
um, and in particular
there's not a lot of support for ,
um, in a wide number of browsers right now.
And that'll probably change over time,
but at the same time, you know, feel free to, you know,
adapt this and use something different.
There's plenty of open-source libraries
for doing slider controls.
Uh, that would certainly work as well.
Uh, as you might imagine,
there's quite a bit of JavaScript involved
in writing this sort of example.
Uh, I'm using jQuery
just as a matter of personal preference
for doing a lot of kind of the heavy lifting.
And one of the things that's nice about jQuery in particular
is that it simplifies the interaction
with the YouTube Data API.
Um, I'm not gonna actually focus too much
on the interaction with YouTube Data API,
but I definitely recommend looking at the code,
if you are curious as to how you can write
a web application that will, you know,
do read-only requests to YouTube,
get the results back, and display them in some way.
Uh, so it's actually gonna be using JSON-P
under the hood, which is a method
of dynamically inserting a script tag into a page
and having that script tag
point to a URL basically on their servers.
And the server knows to respond back
with kind of a wrapper
that will invoke a native function
in our own JavaScript code
with whatever the payload is for the response.
So we're basically getting around
some of the cross-domain limitations
that would normally prevent you from, you know,
using something like XML-HTTP requests
to directly, you know, ask our servers
for a response.
And jQuery will make that pretty easy.
jQuery, you know,
also just makes a lot of other things easy as well.
And everything is JavaScript, more or less.
I'll show you, you know, the actual HTML source.
It's very short.
Most of--all-- most of the important things
are done in the JavaScript section.
And we'll focus on some specific sections there
in a second.
And there's, you know, CSS, as you might imagine--
uh, very basic CSS styling.
One thing I did decide to do was just use, uh, Web Fonts,
which are part of one of the newer CSS specifications.
And I'm using the Google Fonts API
just for pulling down something
a little bit flashier, let's say,
than, um, the built-in fonts
that might be present
on a given user's computer.
So this is the example.
I have this open over here.
Uh, I want to just quickly load up
the uploads feed
for the Google Developers YouTube channel.
And Google Developers is just a great channel in general
for having a variety of different developer content.
So this is playing right away.
Ross: My name is Max Ross.
Posnick: And you see, you know, these controls down here.
This is SVG, as I mentioned, um, yeah, right now,
because for pause-- the pause button is disabled.
The play button is enabled.
Uh, these are the slider controls
using .
If I do start the playback,
we should be able to toggle the volume.
Ross: I focus primarily on...
Posnick: And we should also be able to use this
to jump to a different portion of the video.
You know, much as you'd imagine,
you have the current time listed over here.
Um, just all the basic type of controls
that you would normally see in the YouTube player,
but implemented, you know,
completely with our own code.
And just to show you,
we can also jump to the next video in the feed.
man: All right, hey, there.
Posnick: You can do that pretty much indefinitely.
So just to show you really quick the source,
uh, for the HTML.
Pretty straightforward-- it's just this page of code.
Um, most of logic, as I said,
is done in JavaScript.
So I wanted to jump to that
and show you, uh, just a little bit
of the JavaScript.
And particularly, I wanted to focus
on the JavaScript that's used to handle player events.
And, uh, this is
kind of what I found
the most, uh, difficult to get correct.
And--and when I've worked with developers in general,
um, and just spoken to folks,
I think this is the hardest thing
to kind of wrap your head around,
how to respond to the proper YouTube player events.
And it's really key if you're writing
a custom player experience to get this right.
Otherwise you end up, um, having, you know,
UI elements that are disabled
when, you know, they actually need to be enabled
or just, you know, not taking into account
the fact that an error has happened and things like that.
So, uh, there are kind of three main characters--
categories of events, uh, that are handled
via the YouTube iframe API.
There's the onReady events.
Um, this is fired when the player API
is initially available.
So if you wanted to do something
as soon as the player API is available,
you know, as Jarek mentioned before,
the iframe API right now is, uh,
the way we recommend loading it is asynchronously
so, uh, it doesn't necessarily--
it actually would not be available
whenever, you know, your DOM is fully available.
It's gonna be at some point afterwards.
If you want to put in some code that gets fired
only when everything is fully ready,
you would put it in your onReady handler.
The onError handler, as the name suggests,
is something that would get fired
whenever there's any sort of playback error.
Um, for instance, if a video is not playable
on your particular device for any number of reasons,
uh, that will get fired.
It's pretty important to put in some code
for--for handling that.
It might be as simple as moving to the next video,
if you happen to have a list of videos,
um, or displaying some sort of error to the user.
But it definitely helps the user experience
if you were to put in some code to handle that.
And the third category of events
is onStateChange.
Uh, you can kind of think of it as a catchall
that has a bunch of sub-events
for the different changes in the YouTube player state.
And I wanted to focus most of my time talking about that.
So kind of five main events,
uh, ENDED, PLAYING, PAUSED, BUFFERING, and CUED.
As Jarek mentioned, the BUFFERING event
won't be fired for the HTML5 player now,
uh, but those other events are all relevant.
And...
in general, um, my recommendation
is just not to make assumptions
about the global state of the player
or what triggered the events in your event handler.
And you know,
one example where somebody could go wrong
is they see that the YT.PlayerState.PLAYING event
was fired in their event state change handler.
And they figure, okay,
well, if that event was fired,
it must be because somebody clicked on the play button.
But there's actually a number of other ways
that playback can start for a given video.
Um, the user might have clicked
on the actual YouTube video itself,
which is something that will trigger playback.
Or you know, as Greg was illustrating before,
there are ways to use keyboard controls
for, you know, tabbing into a video
and starting playback.
So if you have any specific assumptions
that are built around the fact, okay,
somebody must have clicked on the play button,
uh, they might be wrong
i-in your play handler.
So I would recommend, uh, explicitly--
you know, especially when you're changing the state
of other UI elements in response to events,
I would recommend to explicitly set the states
each time through in your event change handlers
to whatever the appropriate value
you know it should be for that event,
rather than, you know, just, like, toggling given elements.
Uh, and I think, you know, that leads
to a much better user experience.
So I wanted to get into some code that, uh,
is relevant to that point,
and just a few helper functions here
for enabling and disabling,
uh, a list of different elements
given their element names--
element ideas, rather--
and, uh, just a helper method
for setting up the, um,
the task that fires in the background basically,
that updates the current time in--
you know, what we saw in the lower left corner
of the player-- the current playback time.
So we have, uh, something that will set that up for us,
'cause we're gonna need to clear that in certain circumstances
and then reestablish it later.
So this is just, uh, some snippets of code,
uh, where you, for instance,
would handle the CUED state events.
And this is what gets fired when the player is load--
the video is loaded into the player,
but playback hasn't actually begun yet.
And in that scenario, as you might expect,
you'd think, okay, what controls
do I want to be enabled in that case?
And you want the play button to be enabled.
And what controls, you know, just don't make sense
to have enabled?
You know, pause, volume, and seek--
they're not gonna be able to do anything
when you're in that CUED state.
So, um, you want to explicitly change
those values to those states,
uh, each time we get into the CUED state.
And something, you know, very similar--
the thing about the PAUSED state,
except there's gonna be a different set of things
that you'd want to have enabled.
So you want the play button enabled.
You want the volume controls to still be enabled,
'cause you can still change the volume of the video,
even though it's not playing.
And you'd still like the person to be able to jump
to a different point in the video,
so you want the seek bar to still be enabled.
But you know, again,
you don't want the pause button to be enabled,
because it certainly doesn't make sense.
Uh, and you know, and we're also gonna clear
the background time-out
that, uh, that would be fired to update the player time,
because, you know, if the video is paused,
we know that the time is not gonna be increasing at all.
And PLAYING is in some respects the opposite.
We want to enable the pause button,
the volume button, the seek button.
We want to re-create that interval.
Uh, we want to set the volume
and the duration values
to whatever, uh, they are
by reading that via the API call.
And you know, this might be overriding the existing values.
There might already be a value for the duration there,
or the volume might already be equal
to whatever the current volume is,
but it's--it's really not gonna hurt anything
to set that again.
It might be wasting a couple of CPU cycles,
but I've found it--
it just simplifies things greatly
if you don't make any assumptions
about what's already there in the state,
and you explicitly set it.
And finally, ENDED--
very similar, uh, to what we've seen before.
One thing I wanted to point out... [clears throat]
Excuse me. One thing I wanted to point out
is that it really makes a difference, I've found,
to explicitly set whatever the current time is
in the playback.
And that's the value that you see over here.
This is the current time. This is the duration.
Uh, once the video is over,
you want to make sure that that current time is set
to the duration of the video.
Um, you know, I'm pretty sure folks have had
the experience where you reach the end of the video,
and maybe it's because the video is not--
it has, like, a fractional second in its duration,
and there's some rounding involved,
and you know, it says the video's four minutes,
but you're at--the display says 3 minutes and 59 seconds,
and you're like, what?
What's in that secret one last second of the video?
Obviously there's nothing there,
but it just leads to a better user experience
to explicitly set that.
So that-- that's my recommendation
for handling the ENDED state.
And yeah, that's-- that's kind of an overview
of, um, some of the JavaScript in the example.
Definitely feel free to take a look
and explore some more.
I want to remind folks that we have those--
excuse me.
We have those hash tags--
#io2011 and #YouTube-- for this session.
And if you have any feedback,
you can go to that URL as well.
And we want to take any questions
you guys might have either about iframe player API
or YouTube topics in general.
And hopefully we'll have some answers for you.
Schechter: Um, before we jump into questions,
I actually want to promote--
we've got this awesome after-party coming up.
Um, and so YouTube's one of the main sponsors for it.
It's at Thirsty Bear. You can come grab tickets from us.
And one thing that's really important
is there's a QR code on the back.
If you, uh, scan it and register ahead of time,
uh, you'll get to skip the line to go in.
So hopefully you'll join us tonight for that.
man: I have a quick question for you.
Um, I've used the iframe player a little bit.
Um, is there a way to--
whether it's Flash or HTML5
that's being exposed on the-- on the client side,
is there a way to, um,
set the window mode to transparent
or interact with the CSS of the, uh,
the HTML5 video player?
Schechter: Uh, yeah, so, um, you can add wmode
as one of the arguments
in the, uh, URL.
So that way you'll interact with Flash,
and then you can just interact, uh, with the iframe with CSS
like you normally would,
um, for-- if it's the HTML5 player.
man: Okay, so with the oEmbed endpoint,
I know that you can add that parameter
to get the iframe code returned.
Um, are there plans to start returning the iframe code
by default on the oEmbed endpoint,
or not in the foreseeable future?
Posnick: Yeah, um,
we actually recently made a slight change
to the oEmbed endpoint
that ended up breaking a lot of folks,
and that was just changing one character in the URL.
So I think we're-- I personally would advocate
that we don't make too many changes to our defaults
and continue to allow, uh, folks
to explicitly request things
in the hopes of not breaking
too many existing implementations.
Uh, that's-- that's my personal preference.
I'm not the one actually responsible for the service.
But that's what I'm hoping.
Wilkiewicz: One issue that we've seen
is, uh, you know, people, uh, build platforms
that don't allow iframes.
And then--so the iframe actually has to be white-listed.
And that has been kind of the number one source of pain
as we were rolling it out
and working with a lot of the, you know,
say, blogging platforms, provider, uh, you know, sites,
and so forth,
so that they will actually allow this--this iframe.
And we've made a lot of progress,
but, uh, there's a lot more work to do, yeah.
man: Uh, hey, guys, I had a question
about the accuracy of the, uh,
the skip-to and skip-ahead function.
Um, I noticed during the caption talk
that was in here earlier,
um, that there was fractional seconds involved
for the start time and the end time
for a given piece of text.
Uh, my question is are there plans
to make it more accurate
as far as the skip-ahead, skip-back,
um, just to make navigational control
a little bit easier,
or to be more accurate with, uh, any sort
of external navigation we can develop?
Schechter: Uh, so one of the nice things about HTML5
is we actually don't have that issue.
Um, so with Flash you're worried about, uh, key frames
and having to jump to a key frame.
Uh, HTML5 just standard--
just goes to the time that you specified.
Uh, so you'll have that accuracy that you want.
man: Um, can you--can you do, like, fractional seconds
or, uh, anything like that?
Schechter: I, uh, I haven't tried it.
man: All right. Schechter: Um... I don't know.
man: Cool, thanks.
man: Hi, guys. Uh, the API documentation
says that the iframe player API
is currently not ready for mission
or business-critical applications.
Uh, I was wondering when, uh, what the time frame
for--for that to be removed is, that restriction.
Posnick: Yeah, I don't think we have an exact time frame.
This discussion comes up a lot.
Uh, I think just...
the important thing to realize
is it's still a work in development,
and you know, in the course of me writing
this demo application,
I know I've held about half a dozen bugs
against, uh, against Greg...
Schechter: Right. Posnick: to--to resolve.
So I-I think, um, you know, it's not there yet,
and hopefully that does not stop folks
from using it in their either, you know,
"non-mission-critical" environments
or just trying to develop against it
in parallel to whatever the existing thing is.
And definitely file bugs.
Let us know in, uh, the Google group in particular.
I think that's the best way of getting in touch with us.
And you know, Greg is super responsive
about, uh, getting things fixed.
And you know, as we get to a point,
I think, where there are fewer and fewer reports
of things going wrong,
we'll have a greater confidence in, uh, you know,
taking off that label
and being able to say, you know,
it should be as-- as supported as our AS3 embed.
man: All right, thank you.
man: What's the timeline
on, uh, getting iOS support with the autoplay?
I know that's an Apple issue and not, you know,
an iframe issue. Wilkiewicz: Yeah.
man: But when you've talked to the team,
have they given you a sense of why they've disabled autoplay
on the iframe player?
And is there an E.T.A. for getting that fixed?
Do you see a resolution happening?
Wilkiewicz: So we--you know, we work very closely with Apple.
They're obviously driving a lot of our playbacks.
And, uh, actually if you look at the documentation closely,
uh, for the video playback,
it states that, uh,
for 3G environments,
uh, the user interaction is required.
And you know, I--personally, I kinda, you know, buy that.
man: Right. Wilkiewicz: Uh, but then,
on Wi-Fi, uh, you know,
maybe it should be a little more liberal.
And in fact, this is what we've been trying to, uh,
to see if, uh, the team at Apple
could--could add that. But I don't have an E.T.A.
But you know, we have filed a--
and there has been a request for that.
And we work very closely.
You know, they're a good partner.
man: Gotcha. But they seem favorable to the idea
that autoplaying in theory would make sense
on a Wi-Fi connection?
Wilkiewicz: Uh, you know, I-I wouldn't go as far
as saying that they are favorable.
Uh, but you know, if you cannot look a the user documentation
from our perspective,
uh, there's a discrepancy in behavior.
Or you know, the Wi-Fi behavior is unspecified.
So if it is unspecified, perhaps we could, uh,
make it work just like what-- what we described.
I think that would be probably the best solution
for application developers and carriers
and everybody else involved, yeah.
man: Sure. Um, I guess, on the YouTube app,
that's, you know, native to the device--
and as I understand it, Apple built that, not YouTube.
Um, is there some work-around that you can envision that,
if you're building a native iOS app,
you'd be able to support the autoplayback?
Or is there kind of no-- no work-around?
Wilkiewicz: So for native iOS apps
that incorporate YouTube Video Playback,
there's really three approaches that you can take
for video embedding.
One is you can kick off the, um, YouTube player, right?
So that's one.
The other one is, um,
you can use the existing Flash embed,
and what iOS does is recognizes, oh, this is a YouTube embed,
and then uses a Safari plug-in in order to play back the video.
And this is where this approach falls apart,
if you build your own Flash player
and no longer can, you know--
iOS recognizes the signature,
and then you get a black box.
And the third approach is the, uh, iframe embed.
So, um, if you build a native iOS application,
uh, you can actually use UIWebView
and embed the AS3 embed
or the, uh, iframe embed,
and then, uh, iOS would recognize it.
In one case it uses the Safari plug-in.
In the other cases it uses HTML5, uh, Video Playback.
The HTML5 Video Playback has the advantage
of actually having an API around it.
So I know more and more application developers
are using the iframe API for iOS applications
because it is the only game in town.
So even though, you know, technically we're saying
that, hey, it's not mission-critical,
but, uh, the argument we're making--
it's still better than nothing, you know.
So you can actually do something.
man: Yeah. Wilkiewicz: So--so that's
kind of the story that we have.
But I think all of them suffer
from the same fundamental limitation
when it comes to autoplay.
man: Yeah, I've seen some hacky solutions
where you can fire a touch event,
and then you kind of crawl the-- the player,
then find out what the play button is,
then you send a touch event, which, you know,
apparently isn't allowed by the documentation,
but they've let apps kind of do it.
Wilkiewicz: I see. man: Is there any other
solution beyond that that--that works,
or is that kind of the only-- only thing for autoplay
using iOS? Wilkiewicz: Uh, yeah,
so we don't have anything that we support right now for that.
man: Good. Thanks.
man: Hey, so I have a habit of putting Linux on old laptops.
And then, uh, at previous companies
I was always--always trying to get, you know,
real movies playing on old hardware.
Is the performance of HTML5 video
so much better than Flash that, like,
it really makes it possible to watch movies
on old hardware?
Schechter: Um, it's--
it's sort of a little bit tricky.
So, uh, when the encodings are in H.264,
uh, the performance
is generally a little bit better than HTML5,
although I don't have any numbers to give you.
Uh, WebM--I usually don't see performance being as good,
because, uh, you don't have a specialized chip for it.
Um, but you know, they're making a lot of improvements there.
Uh, but also the-- a lot of--
a lot of what we've been doing on WebM--
uh, it's got, uh, less bytes for the same amount of quality.
Um, and so, you know, it's a better--
we think that it's a better encoding.
But yeah, we're still sort of, uh, struggling
on making sure that the performance
of, like, the CPU is gonna be equal or better.
Cool.
Posnick: Okay, um, doesn't look
like there are any more questions.
So thanks, you guys, for coming.
Schechter: Thank you. [applause]