Placeholder Image

Subtitles section Play video

  • 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]

Wilkiewicz: Hello, everyone. My name is Jarek Wilkiewicz,

Subtitles and vocabulary

Click the word to look it up Click the word to find further inforamtion about it