Tip:
Highlight text to annotate it
X
[MUSIC PLAYING]
BILL LUAN: Shanghai GDG is a very
interesting developer community.
SUSANNAH RAUB: I'm glad somebody
has asked this question.
RETO MEIER: This is where the magic happens.
JENNY MURPHY: This is primarily a question and
answer show, so if any of you out there
would like to ask questions.
JAREK WILKIEWICZ: Hello everyone.
My name is Jarek Wilkiewicz.
Welcome to you YouTube Developers Live.
We have an exciting show for you today.
In the studio with us is Greg Schechter.
How are you doing, Greg?
GREG SCHECHTER: I'm doing very well.
How are you doing?
JAREK WILKIEWICZ: I'm doing good.
Greg is our HTML5 developer at YouTube, and he will talk
about, not surprisingly, HTML5 at YouTube.
We have Jeremy Walker.
JEREMY WALKER: Hello.
JAREK WILKIEWICZ: How are you doing, Jeremy?
JEREMY WALKER: Pretty good.
JAREK WILKIEWICZ: How's life?
JEREMY WALKER: Good.
I got a full night of sleep last night.
JAREK WILKIEWICZ: All right.
Congratulations.
We're going to have to keep you down in your seat.
All that energy level, I think it's coming through.
JEREMY WALKER: Yeah, my four month finally slept through
the night, so--
JAREK WILKIEWICZ: Wow, that's a milestone.
JEREMY WALKER: I'm pretty stoked.
JAREK WILKIEWICZ: And then live from New
York, Jeffrey Posnick.
What up, Jeff?
JEFFREY POSNICK: How's it going?
JAREK WILKIEWICZ: Good.
How are you doing?
JEFFREY POSNICK: Pretty good.
Haven't quite fought off my cold yet, but I'll do my best
to keep the coughing to a minimum as always.
JAREK WILKIEWICZ: Still summer in New York,
or is it fall yet?
JEFFREY POSNICK: It's actually a lovely period before it gets
too cold, and not quite as hot as it has been.
So very, very nice.
JAREK WILKIEWICZ: Cool.
Later on in the show, Jeff is going to discuss our upcoming
migration tool, Stack Overflow.
We are not going anywhere, but the way you will get your
support questions answered is going to change.
And Jeff has worked on that over the last couple of weeks.
He will give us an update of what's happening there.
But first, let's turn it over to Greg, and talk a little bit
about his experience at YouTube and HTML5.
So first question is, how long have you been at YouTube, and
what do you do there?
GREG SCHECHTER: So I've been at YouTube for about two and a
half years now.
And I like to call myself the web warrior at YouTube.
And specifically, I spend most of my time working on the
HTML5 player and other HTML5 related
things around the site.
JAREK WILKIEWICZ: So what do you like about working on
YouTube and working on HTML5 player?
GREG SCHECHTER: So YouTube is pretty amazing.
And a lot of it is just because it's such a-- there's
so many awesome cat videos that I get to watch at work.
But I get to work on bleeding edge technologies.
This stuff is all changing every day.
I'm working with a lot of the browser vendors to really
change the web.
And not only just for people who are watching videos.
But some of the things that I work on do help HTML5 in
general, and moving the web forward, making new APIs.
And this is very exciting for me and it's a lot
of fun to work on.
JAREK WILKIEWICZ: So as a web warrior, who
do you get to fight?
GREG SCHECHTER: Most the time, my battle is against those
flash developers.
I'm sorry if there's any out there in the audience.
JAREK WILKIEWICZ: We kept them out today.
GREG SCHECHTER: OK, good.
JAREK WILKIEWICZ: I think we have to do that in the
following session.
GREG SCHECHTER: So at YouTube, one of the big battles with
our player is, do we serve HTML5 or do we serve Flash.
And Flash is this experienced player.
And HTML5 is the new young guy.
It's sort of a David and Goliath situation.
Although I think Flash isn't really Goliath anymore.
But that's the main battle, is kicking those
Flash player guys--
JAREK WILKIEWICZ: I bet that gets pretty
tiring after a while.
Does it?
GREG SCHECHTER: Sometimes.
JAREK WILKIEWICZ: So what do you do in your free time when
you need to recharge?
GREG SCHECHTER: In my free time, I actually--
I do a lot of nature things.
I do a lot of bird watching.
I find weird salamanders and stuff all over the place.
I take a lot of pictures and stuff.
I actually have some of my photography to share.
JAREK WILKIEWICZ: Oh, great, yeah, let's look at that.
I think we're sharing them here in the studio.
GREG SCHECHTER: So let's see.
The first one we have here, this is one
of my favorite pictures.
It's a green-eyed tree frog and it's
eating a Huntsman spider.
And I love how the little legs are sticking out of its mouth.
I was really happy with that shot.
One of the other ones I have that is also pretty cool is a
nudibranch.
And this one is just a really weird creature.
And I found this Australia.
But I love this picture so much that it's the background
on my Android phone.
And so the next picture I have is, this is more my bird
watching thing.
And wanted to have some that were local to the Bay Area,
since that's where I live.
And so this one I thought was great.
This is a white-throated sparrow that I found near
Santa Cruz.
And it's just in the reeds there.
It's just really pretty.
And I really like how the colors came out with the
yellow in its eyes.
So the next picture, this one was really cool.
This was a little bit further south, in Morro Bay.
But I've got a horned grebe eating a fish.
And it was this nice action shot.
And I had a bunch of shots in this series.
And the last one was actually really close to Mountain View.
This was just in the Palo Alto Baylands.
And so this is a lovely Anna's Hummingbird showing off its
nice gorget and the nice pink.
And yeah, so that's also a great one.
JEFFREY POSNICK: That's pretty nice.
JEREMY WALKER: That's really pretty.
Now, to step aside, you've done Google I/O presentations
the last two years, right?
GREG SCHECHTER: Yeah.
JEREMY WALKER: So what's changed in web development or
YouTube since your first presentation to your second
presentation?
GREG SCHECHTER: Sure.
So I think some of the biggest changes that I've seen are
actually around the mobile space.
And my talk--
that sort of--
I do HTML5 things.
And the biggest difference between the first talk that I
gave and the second talk is the focus on mobile.
And more people are getting smartphones and tablets.
And it's really becoming something that web developers
need to think about when they're building a product.
JEREMY WALKER: So your 2012 was mostly focused on the
mobile side?
GREG SCHECHTER: Yeah.
The talk was HTML5 at YouTube, stories from the mobile front.
And the idea was basically to show all the stuff that we're
doing HTML5 related, and talk about best practices, and how
a lot of those things are really important to mobile.
And how in the past, you can't--
you have to use plug-ins--
for example, Flash-- to watch video, or even Flash to do a
lot of your uploads.
But now with HTML5 being available, you can make a
richer experience.
And then it's also going to work on mobile, and with that
being such an emerging place for development, it's that's
really important that you also have all that development--
that the time that you put in to develop also contributes to
your mobile products.
JEREMY WALKER: That's awesome.
I hear there's some things in the deck quite often, if I'm
not mistaken, that you enjoy on YouTube.
The feline persuasion.
GREG SCHECHTER: Of course.
I got a lot of--
I'm a big fan of cat videos.
And certainly there's a lot.
In my talk, there's plenty of cat references, and famous
YouTube references there.
JEREMY WALKER: Yeah, I watched that.
It was pretty funny.
I really enjoyed it.
GREG SCHECHTER: I'm glad you enjoyed it.
JAREK WILKIEWICZ: And we will post a link to the
presentation on our stream, YouTube Developers, in case
you have missed a session at Google I/O.
Couple of questions about your session and
mobile web in general.
So I have noticed you have a lot of web browsers installed
on your phone.
How many?
GREG SCHECHTER: So I think at the moment there's nine.
And to be fair, some of those are different versions.
So I have both the Chrome browser and the Android
browser installed.
I've got Firefox mobile, Firefox mini, Fire--
sorry, Firefox Mobile, Beta, Alpha, Aurora, and Opera Mini
and Opera Mobile, and Opera Next.
And then every now and then, I'll even end up installing
one of the lesser known ones like Dolphin, for testing and
making sure things are working properly.
JAREK WILKIEWICZ: You think that should be the standard
practice for application developers
targeting mobile web?
Or why do you do that?
Is it just for fun, or are there any significant feature
differences between these browsers?
GREG SCHECHTER: It's a little bit of everything.
So certainly being a web developer, it's actually quite
common that I never have just one browser open.
I'm always jumping in and seeing the new features.
But that's because I enjoy it.
For developers, I think it's very important to know what
kind of user experience your users are getting.
And so by me having all these different browsers on my
phone, I'm able to constantly look to see what's YouTube
like on Firefox, what's it like on Chrome,
what's it like on Opera.
And I can understand how these different browsers work.
And also, for me, I do talk a lot with the different browser
vendors, and I'll report bugs back to them so that I can
make sure that YouTube is working properly for everyone.
And I mean, it's pretty low cost to install all these
browsers on my phone.
Most of them are in the app store.
And the ones that aren't, update really easily if you
just pull them up from one of the websites.
But yeah, so it's pretty simple, and it's definitely
something that's helped me get a better understanding of what
the mobile environment looks like on all the different
platforms and all the different ways that users
might be experiencing YouTube.
JAREK WILKIEWICZ: So there's a lot of talk about mobile apps,
native apps for mobile.
And the question that I have in my mind is, in your
opinion, which types of apps benefit the
most from mobile web?
What are the apps that are well-suited for mobile
web-based implementation?
GREG SCHECHTER: So I really think that any app can do well
with HTML5 on mobile.
I think that it's probably most compelling for a site
that also has a desktop experience.
Because what you have there is you have code that you would
share between your desktop environment and your mobile
environment and maybe even your-- if for whatever reason,
you're putting it on a TV as well.
And it's really easy to make sure that your code works the
same, and you don't have to rewrite things in a new
language or something.
Everything will convert onto mobile pretty simply.
Of course, you do have to make changes.
The interface has to be different.
Make sure that touch is working.
But as far as some of the core structures, like how you would
serve a video or do AJAX calls and all that,
that's all the same.
That's not going to change if you're on mobile or if you're
on your desktop.
So that's certainly something that--
anybody who has to support both, it's certainly going to
save them a lot of development time if they don't have to
basically reinvent all their code in both places.
JAREK WILKIEWICZ: Which features do you think are
still missing, and are high priority, when it comes to
HTML5 support, for mobile and maybe even
for desktop as well?
GREG SCHECHTER: Sure.
At least for mobile, I spend most of my time doing video
development.
And I think there's actually a lot missing there,
specifically on phones.
We have sort of two main issues.
One is the screen size is very small.
And so we haven't really been able to optimize our controls
to deal with when your player is just very, very tiny, and
it's hard to click on, and you don't have enough room for
your fingers to interact.
But on top of that, a lot of times the full screen
experience is out of the developer's controls and just
goes native playback.
And so all this richness that we add to our YouTube videos--
whether that be annotations, or captions,
or even a 3D effect--
we lose that power and that ability
to make these features.
And so this is, I think, something that's really
lacking in the mobile environment, is being able to
have that richness that we saw on the desktop for video on
mobile as well.
JAREK WILKIEWICZ: Is this something that is being
tackled by browser vendors or standards right now?
GREG SCHECHTER: Absolutely.
Some of it is, and some of it isn't.
One of the things that I've actually worked
on recently is WebVTT.
WebVTT is a standard for captions.
And so with this new HTML5 track element, we can have
native browser rendering of our closed captioning.
And so this is great, because that's one of our features.
That's really important for people, especially for
accessibility.
I'm often in a crowded place, and I can't necessarily--
maybe I forgot my headphones.
I can't hear it.
And I would still find a lot of use for it.
So this will allow us to do--
the browser to do it natively, and it to work on all these
different mobile places.
I'm excited when that will finally launch.
JAREK WILKIEWICZ: So it sounds like some of the features will
basically move into the browser, so there's no need
for the developer to implement it as some sort of an overlay.
GREG SCHECHTER: Certainly there's a less of a need.
Now, things like annotations at YouTube, we'll still need
to do that, because that's specific to us.
But some of the more general things that we think all video
should have, like closed captioning, will be integrated
more and more with the browser as time goes on.
JAREK WILKIEWICZ: Great.
So how happy are you with what has happened over the last
year, over the last two years, three years, in this space as
far as the velocity of that progress?
This kind of goes back to Jeremy's question about what
has changed between the I/O 2011 presentation that you
gave about our iframe embed and the iframe API, and the
2012 experience about mobile.
| mean, clearly mobile is accelerating.
And YouTube, we have recently announced that we've hit a
billion views per day, which is a staggering number.
But from a technology standpoint, a browser support
standpoint, is the progress fast enough?
Is there things that you think should be done differently?
And what can the developers do to help accelerate it?
GREG SCHECHTER: Sure.
So I've got mixed feelings on it.
Mobile has a lot of issues at the moment.
And I look at this mostly with video.
And the differences between-- there's so many differences
between each browser, how they do different things, what
controls they show.
Can you control the playback speed?
Does autoplay work?
And there's all these differences.
And it's really difficult as a developer to build a rich
experience when I don't necessarily know how the
browser is going to work.
And the fact that it's much different
than the desktop space.
And we also see that some of these mobile browsers aren't
quite on par with the desktop experience.
For example, it took us a really long
time to launch Chrome.
The Android browser was different, it was out of date,
and we didn't have a lot of the richness that we saw on
the desktop.
Once we got Chrome, that closed the gap a lot.
But there's still a lot that needs to be done to match the
richness that we see on the desktop.
Now on the other hand, I actually think that Firefox
has been doing a great job.
They've been promoting mobile a lot with their Boot to Gecko
stuff, and really trying to make sure that is the central
platform for things.
And in the past year, they've released a lot of new APIs to
deal with the fact that the mobile is sort
of a primary device.
And so they've released things like being able to do
vibration, just with the JS API, detect ambient
light and all that.
And I think that they're really moving quickly and
adding that richness to make it even a richer experience
than you have on a desktop.
So I would like to see some of the other browsers step up and
do as much as they are.
But of course, it's a lot of work to get all this
awesomeness into the mobile.
JAREK WILKIEWICZ: What's your development environment like?
What tools do you use for your hacking and free time, what
frameworks do you like?
Tell us a little bit more about how you work.
GREG SCHECHTER: Yeah.
So I spend--
I mean I work.
I spend most of my time in Vim in a simple terminal.
And as far as what frameworks I use in my free time, I love
JavaScript libraries.
And being a hard core JavaScript guy, I spend most
of my time working on the client.
And recently I've been doing a lot of jQuery, but I'm a die
hard YUI fan when I can.
I used to work at Yahoo in the past, and I know a lot of the
guys there.
I think that they've built a really great project.
I'll do either jQuery or YUI on my own.
Yeah, you know, it's really pretty simple, just terminal
stuff, nothing too complicated.
JAREK WILKIEWICZ: Cool.
JEREMY WALKER: Out of curiosity, do you write your
own code for checking HTML5 stuff, or do you use something
like Modernizr?
GREG SCHECHTER: I often write my own stuff.
At YouTube, we're always really concerned about making
sure that our JavaScript is as minimal as possible.
Depending on the situation, we might already know ahead of
time that we're going to be in a HTML5 supported environment,
so we won't necessarily do all the check-in that Modernizr
does, because we can make it smaller and just not need all
that extra code.
So we normally do it on our own.
JEREMY WALKER: So for a third party developer, would you
suggest they write their own, or would you suggest they use
something like that?
GREG SCHECHTER: I would suggest
that they use Modernizr.
I don't think they should necessarily waste their time
writing it themself when somebody else did it, and did
it well already.
Some of the stuff that we're doing isn't released yet.
So the stuff I was mentioning earlier about the track tag,
at the moment you can try that out, but it's hidden behind a
flag in Chrome, and it's only in the Opera Next build.
And so the feature detection there hasn't made it to the
frameworks yet, because it's not live.
So we have to build these things, because we're testing
them and helping those browser vendors move forward with
their things.
But not everybody needs to spend the time doing that.
JAREK WILKIEWICZ: Another question that frequently comes
up is, if I use YouTube, when do I get the HTML5 player?
How can I get the HTML5 player, and kind of, what is
the logic. how is that implemented that decides is it
going to be Flash, is it going to be HTML5?
Can I use HTML5 for my testing?
Can I force HTML5?
Any hints of how that works and what the developer should
do if they really want to experiment with HTML5 support?
GREG SCHECHTER: So my hope is that we can get all the videos
on HTML5, and that'll be the default experience.
We're not quite there yet.
Flash has just a couple core features that we don't yet
have the capabilities to do in the HTML5 world.
So once that changes, hopefully we'll be able to get
HTML5 out as the default experience.
Until then, the easiest way to get HTML5 is to go to
www.youtube.com/html5, and you can opt in to the experiment.
And then, assuming that you're watching a video that supports
all of the--
where our HTML5 player supports all the features that
we need for that video, we'll give you HTML5.
JAREK WILKIEWICZ: Does the opt in stay with the browser from
which I opted in, or is it associated with my account?
How does it work?
GREG SCHECHTER: It's cookie based, so it's going to be
just with that browser, with that sess--
with that machine.
JAREK WILKIEWICZ: And will that apply to embeds as well,
or just for YouTube.com?
GREG SCHECHTER: It will apply to all YouTube views.
Yeah, so embeds and just on YouTube.com.
And so if you ever don't see a video--
if for whatever reason a video doesn't play, or it plays in
Flash, that's usually because either the video might have
just some business logic that--
maybe the stream is secure and we don't have the ability to
do that yet in HTML5.
So it's things like that, where it's just features that
we don't yet support.
But you'll still get the Flash player.
JAREK WILKIEWICZ: Do you do-- if I opt in to HTML5, is there
client-side logic that kicks in, or is this
on the server side?
Like for example, I'm on a platform that
doesn't support Flash.
Will you actually do that on the client and figure out that
Flash is not available, or is this done based on the user
agent header that is sent by the client,
or how does it work?
GREG SCHECHTER: So we actually have a bit of both.
The server side sort of does a basic check.
It guesses what it thinks your capabilities are.
And that's looking at the user agent, and so basically if
you're using an old browser, it's going to assume that you
need Flash.
If you're using a user agent that we don't know, maybe it's
on a TV or something, we're going to also assume that it's
Flash, just because we don't know it.
But then on the clients, we have a lot of code that says,
all right we're going to try the Flash Player, that didn't
work at all.
Now we have the ability to switch over to HTML5.
And once we do that, we actually essentially opt you
in to using HTML5.
So the second time you view that page,
you'll get HTML5 again.
We'll remember and we won't keep trying to give you Flash.
JAREK WILKIEWICZ: Now in addition to Flash versus
HTML5, there's always the issue of codecs, right?
How do you know which codecs will give platform support?
How you handle that?
GREG SCHECHTER: If you wanted to check to see what codecs
your browser supports that we care about at YouTube, once
again, you can go to the slash HTML5 page.
And you'll see the main formats that we support are
h.264 and WebM.
And as of today, basically all videos should you have--
all videos that get watched should have both formats.
Originally, a year ago, we didn't quite have all the
videos on WebM, but all new videos will have
both WebM and h.264.
So we support those two main ones.
JAREK WILKIEWICZ: Then in your code, does the client of
iframe embed actually do any sort of checking to see which
codecs are supported by a given browser, or
how does this work?
How is this detected?
GREG SCHECHTER: There's actually a lot of
logic behind that.
So the HTML5 video tag has APIs for us to see if it
supports a codec.
So we can see if we have h.264 support or WebM support, and
then we have a list of things.
I'm a big fan of WebM.
I think it's a great format.
So normally, we're going to pick those formats first and
serve those, unless you're on a browser that doesn't support
it, and then we'll go h.264.
But on the mobile environment, it's actually--
today h.264 is a bit of a better option.
It doesn't consume as much power because there's chips
built into the phones that specifically do
the hardware decoding.
And WebM--
there's a couple devices that have hardware decoding for
WebM, but it's not that common yet.
So in those situations, if we know that we're on mobile,
we're going to pick h.264 first.
But yeah, it's pretty much just simple, using those APIs.
CanPlayType is the specific one I'm referring to.
And then having a bit of logic that we use with user agent
checking to decide if we want to prefer WebM or h.264.
JEREMY WALKER: Do you see a lot more devices in the
pipeline that have chips that support WebM?
GREG SCHECHTER: I actually don't know much about it.
Some of the people that I talk to are pretty excited and
they're pretty gung-ho about pushing WebM and getting it to
be a better experience on mobile.
But a lot of it I just hear second-hand, so I'm not sure.
JAREK WILKIEWICZ: We actually work with the WebM team, so
perhaps we should invite them to GDL and tell
us more about it.
JEREMY WALKER: Yeah, that would be interesting.
JAREK WILKIEWICZ: That's a great idea, Jeremy.
All right, so I know we have a couple of things we wanted to
cover today.
Jeff wanted to talk about Stack Overflow.
And we wanted to look to see if there were any questions.
So why don't we transition over to Jeff.
And first of all, thank you very much.
GREG SCHECHTER: My pleasure.
JAREK WILKIEWICZ: For telling us more about your experience
building HTML5 as a web warrior at YouTube.
And thank you for sharing these
wonderful photos with us.
So now, let's transition over to Jeff, who is joining us
from New York.
Jeff, tell us more about Stack Overflow.
JEFFREY POSNICK: Sure.
And I also wanted to thank Greg because that was super
interesting and really informative, so thank you.
So, Stack Overflow.
First of all, hopefully a lot of you out there are already
familiar with Stack Overflow.
This is a very established technical resource that I use
on a daily basis just to look up answers to questions.
Not necessarily asking questions every day, but it's
kind of known as being a really high quality question
and answer site that has built-in ways of promoting the
right answer.
If maybe you get six different answers and one of them
happens to be a lot more correct, let's say, or a lot
more valuable than the other ones.
Stack Overflow is really good about exposing the right
answer to a given question.
So we're big fans.
Within Google's developer relations group, a lot of
teams have already moved over to Stack Overflow as the
primary source of providing answers
to developer questions.
Before Stack Overflow, a lot of teams, including YouTube
API, had a dedicated Google group, which had a web
interface and an email-based interface where people could
ask questions.
And it works great for basic questions and for working as a
mailing list, and we're still maintaining a Google group for
announcement only emails that folks can still subscribe to.
But we really wanted to take advantage of some of the
community features that Stack Overflow offers.
And the fact that people have been asking questions on Stack
Overflow related to YouTube and the YouTube APIs for years
now, really.
And we haven't been answering them.
It's kind of hard looking in a bunch of
different forums at once.
Our focus has been on the Google group up until now.
But now we're looking forward to being able to answer
people's questions on Stack Overflow.
So folks who are organically finding that site and asking
questions there will suddenly start getting answers from
Google's developer relations team, and YouTube API
developer relations team specifically.
A lot of the questions previously had been answered
by members of the community.
And that's another great thing about Stack Overflow.
We're really looking forward to the fact that there is an
active community of developers who are experts in all
different aspects.
And hopefully we'll get some more API questions that are
answered by people other than my immediate
team on Stack Overflow.
So that should make things a little bit better or for
everybody, quicker answers for everybody.
The gist of it is that starting on October 15, we're
not going to accept any new posts to our existing Google
group that was set up for YouTube API questions.
So it's going to go into archive-only mode, which means
we'll still be able to make references to old posts that
might have a canonical answer somewhere.
That's not going to go away.
It's still going to show up in the Google
search index, obviously.
It's just that we're not going to let people post any new
questions there.
And we're asking that people take things that are questions
to Stack Overflow.
But we're also going to be promoting, and, I guess,
making a little bit more prominent, our issue tracker
that's been around for probably five years now, and
using the issue tracker as the authoritative place to report
bugs with the API, or to put in feature requests.
Stack Overflow is very specifically a question and
answer site, and a place to go for technical questions.
It's not a place to report bugs, and it's not a place to
request features.
And I think the Stack Overflow moderators
tend to be a little--
they're very diligent about closing feature requests and
bugs that get posted there.
So please keep in mind that if you have a feature request or
you have a bug, use our existing issue tracker.
We're going to get a lot better about keeping up to
date on the things that come into issue tracker.
And it just lets us do things like assign a specific bug
number that matches up with our internal bug database with
an existing external bug, just to have the record keeping a
little bit cleaner than what we could get in the Google
group when people would report bugs there.
So that overall migration, again, is going to take place
on October 15.
Folks don't have to wait until then to start posting on Stack
Overflow or start filing feature requests or bugs in
the issue tracker.
You can certainly do that now.
And we're hoping that it leads to a better overall developer
experience for everybody out there.
JAREK WILKIEWICZ: Jeff, What tag should people use when
they file the Stack Overflow questions?
JEFFREY POSNICK: Yeah, that's definitely important.
Stack Overflow gets a very large number of questions
every day, so we have to be able to find your question if
we want to answer it.
And the specific tag that we're asking developers to use
is YouTube-API.
And that's the one we're going to be looking for.
I know that a lot of people right now are posting things
that are tagged with just YouTube without
hyphen API at the end.
Those might get our attention every once in a while, but
we're going to really going to be focusing on the ones that
are YouTube-API.
Because those, we know, are API-related questions, rather
than somebody who's just asking something about the
YouTube website, for instance, which we
really can't help with.
JAREK WILKIEWICZ: Now, as far as those people that have
gotten addicted to emails from you, is there still a place
where they can receive them?
JEFFREY POSNICK: So we have that
announcement only email group.
That's going to keep around.
We'll have links to all these groups.
Well, we have links to all these groups in a blog post
that recently went up on apiblog.youtube.com.
But we'll put it in links, either this video or our
Google+ page so you know where to sign up.
We're going to keep around that email-only announce
group, and that's where we're going to be pushing out email
notifications about important changes to the API.
We have a few other channels where people
can stay up to date.
Obviously, that aforementioned blog is a great thing to
subscribe to if you want to get notified whenever we have
a new blog post.
And we have our also aforementioned Google+ page,
which is google.com/plusyoutubedev.
And subscribing to that will let you know when we're having
all these fun YouTube Developer Live events, as well
as any other important updates that we want
to push out to folks.
And also--
this might be a nice segue-- one of you mentioned that
people can ask questions of us, not only via Stack
Overflow, but also via the Google Moderator interface
that we have for each of these weekly YouTube
Developer Live sessions.
So we can answer some live questions during these, or for
more complicated things, we might just ask folks to find
us on Stack Overflow with all the debugging details and that
sort of thing.
JAREK WILKIEWICZ: Cool.
Speaking of which, Jeremy, do we have any
questions in the moderator?
JEREMY WALKER: Yeah, actually, we have a few.
JAREK WILKIEWICZ: So Jeff, thank you for covering the
Stack Overflow migration.
I think we are really looking forward to being more scalable
and then having some community participation.
I think one thing that I personally like about Stack
Overflow is, in addition to good karma, it also helps you
with reputation, and you can earn some badges, which is
really cool, since we all play games, and life wouldn't be
the same without badges.
All right.
Jeremy, over to you.
JEREMY WALKER: Let's get started.
So the first question is actually on HTML5.
So they actually want to know from your perspective, what's
the best resource to get started?
And then second, what are the prerequisites they need to
know before they start messing with HTML5?
GREG SCHECHTER: I've been a big fan of the Opera Web
Standards Curriculum.
Now this covers web development in general, and
there is some HTML5 stuff in there.
Once you're getting into the newer things, the things that
are really awesome, HTML5 Rocks has a bunch of great
examples and links to more resources and more detail.
So those are some of the--
those two things.
The Opera Web Standards Curriculum and HTML5 Rocks are
some of my favorite places to look at good examples.
After that, you're like having to read the spec for these
things, and that can get a little complicated.
JEFFREY POSNICK: I also want to point out, I really like
the Mozilla developer network pages, specifically for
providing what seems to me, at least, the canonical
definition of different JavaScript objects and the
methods they expose, and code samples for all those.
It's not specific to HTML5 JavaScript, but if you're
doing anything, I always tend to click on Mozilla developer
network links when I have a search.
GREG SCHECHTER: That's one of the best places to find
documentation for any web development stuff.
JEREMY WALKER: And what about prereqs?
What do you think you have to know before you get
started with that?
GREG SCHECHTER: You have to know HTML5,
JavaScript, and CSS.
You really don't have to be too advanced in
it just to get started.
I mean that's--
one of the goals of HTML5 is to make it simple, so that
anybody on the web can build this richness.
And so just to get a video playing, it's as simple as
having a video tag with a source, and
just a controls attribute.
And so there's really not too much, but you do need to be
familiar with HTML5, JavaScript, and CSS.
JEREMY WALKER: Great.
So we've got a couple more.
One is, they basically want to know, if an onProgress event
is coming so that you can get the--
the refire for progress and seek.
They currently are pulling the get player
state to get the progress.
GREG SCHECHTER: That's actually an interesting one.
I actually got into a discussion with somebody about
onProgress and other APIs.
I'm currently trying to convince the team that not
only do we need to have events like onProgress, but I think
that we need to really enhance our API to be able to provide
the richest experience that we can give.
So one of the interesting things is HTML5 has some new
APIs that deal with just media in general.
And they do a better job at providing API than we do.
And I think that for us, in order to make sure that people
are still able to build great applications on the web using
YouTube, I think that we need to have an API that's not only
on par, but even better than what you get natively.
So it's something that I'm trying to
convince the team to do.
That one, I don't think, should be very difficult.
So hopefully, these things will come, but I'm not quite
sure when we'll be able to get them.
JAREK WILKIEWICZ: In the meantime, what is the
work-around?
Just set up a timer and use the iframe API?
GREG SCHECHTER: Yeah.
JAREK WILKIEWICZ: Just pull?
GREG SCHECHTER: It's just a timer.
250 milliseconds should be able to--
I believe in our documentation we say that even
GetCurrentTime is going to be, at most, out of date by 250
milliseconds.
So you can at least just have a timer on that, and that
should be the same.
But it's not-- right, it's not as comfortable to program that
way when you're using an event-driven environment.
But yeah.
250 milliseconds should be at least a good
work-around for now.
JAREK WILKIEWICZ: Cool.
JEREMY WALKER: We have another question from the Netherlands
around HTML5 versus Flash.
So in HTML5, it downloads the whole video, whereas Flash
only downloads what it needs to not rebuffer again
until it needs to.
So they basically asked if you're aware of this.
GREG SCHECHTER: This is something that we're aware of.
For HTML5, the buffering is out of our hands.
As the spec currently stands, it's decided by the browser.
For Flash, it has to do with our streaming and the
adaptive-ness.
And so we don't buffer as much because you might switch
qualities quickly and we don't want to get
all that extra thing.
It's something that's in discussion.
If you go into the Settings menu and you change the
format, if it's anything that's not auto, it should
buffer all the way through.
Otherwise, it only does a little portion of it and it'll
wait until you've start playing more.
JEREMY WALKER: Great.
Let's see, so we have another one.
Lots of developers need the classic player plus one
feature, and currently if you need that, you need to
basically get the whole entire chromeless player.
And they were--
well, it was more suggestion, but I guess the question would
be, is there any chance that we're going to release a
plug-in where you get the bare bones, and you can add like
one of the features, as opposed to getting the entire
chromeless player.
GREG SCHECHTER: Sure.
So for some of our features like annotations and captions,
where we're working on getting APIs available so you can turn
those things on and off and get that, for things like
still having our controls and adding things to it is not
something that we've really discussed.
But I'll bring it back to the team and
see what people think.
But it's not something that's in the pipeline yet.
JEREMY WALKER: Great.
And the top question, is Google YouTube developer
relations hiring?
And, of course, we are.
JAREK WILKIEWICZ: I can take that.
Both Google developer relations and YouTube
developer relations are hiring.
To learn more, go to developers.google.com/jobs,
and you will see all the types of positions that we are
hiring for, and also a little bit more information about
what we do.
There was one more question added.
I think it came through from Israel, about playback rate
control via the API.
So I can take that since I play around with that.
So the question is whether there's a way to actually
change the playback rate using the API.
So if you have been paying attention with HTML5 player,
you can actually change the speed at which the video
plays, which is a really cool feature that a lot of people
don't know about.
But I personally like it a lot.
Because a lot of times when I'm watching video on demand,
I prefer to go through it quickly, especially if it's
some kind of educational content, like
this one, for example.
With HTML5, actually, we do have an iframe API.
So if you go to the iframe API reference, you'll see two
relevant methods.
One is called getPlaybackRate.
And you can actually get the rate at which the video is
playing today.
You can see a playback rates at which the playback is
available for given video.
So that's getAvailablePlaybackRates.
And then, setPlaybackRate will let you control
the playback rate.
So that is actually already available for HTML5.
Last time I checked, we didn't actually support it for Flash.
So nothing is going to blow up if you invoke these iframe API
operations.
Again, iframe API abstracts the differences between the
Flash player and the HTML5 player.
And this is, I suppose, why you might be having some
issues trying to convince the team to add new APIs, because
we always have to look at both.
And we attempt to provide a consistent user experience for
developers across these different technologies.
So for the Flash player, if you look at available playback
rates, you only see one, and it's going to be a
multiplier of one.
And then if you set it, then you're going to get back to
where you were, which is standard playback.
So we don't have that for Flash yet, but you can play
around with it already in our HTML5 player.
GREG SCHECHTER: And just to clarify, although the API is
there and working in the HTML5 player, not all of the
browsers have support for variable playback speeds.
So this'll work great in Chrome, but Opera does not
have this feature yet.
So you'll only get--
if you query what available playback speeds are, you're
always going to get just one.
JAREK WILKIEWICZ: Hence, you have nine mobile browsers on
your phone and probably even more on your desktop.
GREG SCHECHTER: Yep.
JAREK WILKIEWICZ: All right.
I think we have run out of questions, and running out of
time as well.
So I would like to thank you all for watching.
See you next week, same time, same place, virtually on the
net, or perhaps on the hangout in the studio.
Jeff, I hope your cough continues improving.
I've been counting your coughs every session.
I think this has been the best one thus far, unless you've
been using mute secretly.
JEFFREY POSNICK: I've been secretly muted.
JAREK WILKIEWICZ: Oh no, that's cheating.
JEFFREY POSNICK: I'm going to see if I can install a mute
button, maybe, in my bronchial tubes or something like that.
Just spare everybody in the office around me.
Either that or get better.
I prefer the latter.
JEFFREY POSNICK: Yeah.
JAREK WILKIEWICZ: All right.
Take it easy, and thank you very much for watching.
We'll see you next time.
[MUSIC PLAYING]