WordPress Tutorial: How to Embed a YouTube Video in Your Website

WordPress Tutorial: How to Embed a YouTube Video in Your Website


Hi and welcome to WordPress.com. This video will show you how to embed
a YouTube video in a page or a post. To embed a video in a post, open up
the post editor, and click where you want your video to go. Make sure it is on a new line. Go to YouTube, and open the video
you want to embed. You can embed any video
that isn’t set to private. Click on the URL of the video,
and paste it in your editor. You can also set your video to play
at a specific time. Click on Share to open up more options
below the YouTube video. Set the time you want the video to start
playing, or, drag the cursor to the right spot and copy the URL generated below. Paste in your post editor, and that’s it. Update or publish your post,
and view your video in action. For all your WordPress.com questions,
visit our support section at en.support.wordpress.com.

Google I/O 2011: YouTube’s iframe Player: The Future of Embedding

Google I/O 2011: YouTube’s iframe Player: The Future of Embedding


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]

Editorify – Import Reviews Videos and photos to Shopify

Editorify – Import Reviews Videos and photos to Shopify


Hey guys this is a quick video to show
you how Editorify works and how i can import reviews videos and images to
specific product page on Shopify. This is the product page I would like to use, let’s go to Ali express click the Editorify icon I will pick few of these reviews okay this is the product and import now ok now click “view” And scroll down and you can see the
reviews and the images The next thing I would like to show you
is how to import video to this product Just go to youtube pick any video that
you would like to add to the product page again click the Editorify icon Pick the video you would like to import and…import let’s click the view here is
the video thank you for watching this video bye bye

Crossbow Enchantments in Minecraft

Crossbow Enchantments in Minecraft


Hey guys, it’s DigMinecraft here and
welcome back to another video Thanks for watching Please subscribe and leave a like
on the video if you enjoyed Also, check out our website
at DigMinecraft.com

PHP Inbox System Introducing

PHP Inbox System Introducing


How to create PHP Inbox System from scratch,
we’ll use HTML,PHP,Jquery,CSS People who don’t know much about PHP don’t worry I’ll
try to explain it more Here i’m showing only 5 messages on the page, and i have pagination
moving throught messages Also i’m showing on the table the message “ID”, “From”, “Email”,
“Subjec”t, “Message”, “Sent time” and the “message” is opened or not, we will take a look to the
database i created a Database i called it “Messages” I created table inside it and called it “Messages” the “messages” table contains “ID”, “From”, “Email”, “Subject”, “Message Content”, “Date”, “Time”, “Open” And If message is opened it will be 1, if not it will be 0, here i’m showing
inside every message “From”, “Email”, “Date”, “Time” Time Format is like Facebook, Also you can
Delete The Message Watch Part 1 of this tutorials now.

YouTube Developers Live: Embedded Web Player Customization

YouTube Developers Live: Embedded Web Player Customization


JEFF POSNICK: Hey, everybody. Welcome to this week’s show of
YouTube Developers Live. I’m Jeff Posnick coming to
you from New York City. I’m a member of the Developer
Relations team. And this week I’m really excited
to talk to you about different ways of customizing
the YouTube-embedded player. Before I get started though, I
want a couple of ground rules to just talk about what we’re
going to be covering in today’s show. There are a lot of different
embedded players, and there’s lots of ways to customize
them. But for this particular show,
we’re going to be focusing on customizing be iframe-embedded
player, which is our current recommended way of embedding
videos on web pages. And we’re going to specifically
focus on the options that are most relevant
for desktop web browsers. A lot of these customization
options we’ll talk about do have some effect with mobile
browser playback, but not all of them do. And we’re going to just focus
today on how these options affect desktop playback. Another thing that we’re not
going to be covering today is using the JavaScript API for
controlling playback. This is obviously a very
interesting topic and a very important topic, it’s just a
little bit outside the scope of what we wanted
to talk about. So we’re not going to be
covering any of the methods that you could use in JavaScript
to start playback or control playback, or receive
events when playback changes happen in the player. What we are going to be covering
is things that are covered in the documentation
on the specific page, so if you pull that up, we’ll
share that with you. And as I’m going through this
demo, a lot of what I’m going to be covering refers to
specific web pages. When we go back and post this
video on YouTube, I’ll have annotations linking to all the
web pages, so that you could go there and check them
out yourself. So this is our main jumping off
point for talking about the customization that
you could do to the YouTube-embedded
iframe player. And you could get here from
our main Developers.Googl e.com/YouTubedocumentation. And everything in this parameter
section in the docks is fair game for what we’re
going to talk about now. One other thing before I
actually get into explaining these parameters is explain
the two different types of ways that you can load the
iframe-embedded player onto your web page. And we’re kind of agnostic as
to the way in which you load it, these parameters are going
to behave the same way regardless. But I just wanted to point out
that there are two different ways of doing it. The first way is using the
iframes kind of like YouTube player, YT. Player constructor. And this is a more programmatic
way of loading the iframe player onto
your web page. So I have this jsFiddle right
here that demonstrates what that will look like. It basically involves loading
in this JavaScript API and calling the YT. Player constructor, and passing
in the ID of a div that’s on your page. And you’ll see here that there
is this playerVars section that you could pass
in to the YT. Player constructors. So this is where you get to
specify all the options that we’re going to be covering today
if you’re using the YT. PLayer constructor. And just quickly jumping over
here, this is where I stole that code from in our Getting
Started guide for the iframe API. We talk about how you could
actually get that code. So feel free to borrow it there
or from that jsFiddle. The second way that you load
the iframe player onto your page is just with a simple
iframe tag that you could add to any web page. And this has the same sort of
parameters that the YT. Player constructor is,
kind under the hood. They really end up creating
the same thing. Just that the YT. Player constructor is a
programmatic way of creating this tag using JavaScript. This is if you’re just writing
out [? initiable ?] template, or even if you’re not
a JavaScript programmer at all and just want to include
some HTML on your page, you could use this tag. And the same parameters we are
going to be talking about can go at the very end of the URL
that you use as a source of the iframe tag. So over here we have autoplay
equals 0 and controls equals 0. And that corresponds to what
we’re seeing over here for the playerVars. And the actual documentation for
using that iframe tag is found over here. If you look in the docs over
here, we give some examples. So that’s the ground rules for
how you actually will use these parameters that
we are going to be describing in your own code. So I just wanted to run through
pretty much from the top, all these parameters
here. We do have really nice
explanations what they mean in the documentation. So it’s going to be a little bit
repetitive in some cases. But I did want to highlight some
specific ones that are the most useful. So autohide comes in
handy quite a bit. This is something that controls
the behavior of the controls, more or less, that
are on the bottom of the YouTube Player. It’s not necessarily the initial
state of the controls, but it’s more like what happens
the controls once playback starts. And I’m going to demonstrate
the ways of setting those different values by going to
this page over here, which is our YouTube player demo. So this is another really
great resource. And it’s an alternative to
writing this code over here or writing this in jsFiddle. It’s just a way to play around
with these parameters in a live setting. And we can think of it like our
API explorer, if you’ve ever used that for
our data APIs. This is the equivalent
for our player APIs. So what it lets you do is go
over here on the right and start choosing different values
for the parameters. And I’m not going to do this
for every single parameter that we didn’t talk about, but
just to show you how you could experiment in real time
without having to write any code. Let me just try setting autohide
to 0 over here. I’m going to click
Update Player. And once I set it,
Begin Playback. This is a very old video. Actually, part of what I plan
on doing is replacing the default video that we use in
this demo with this video, so we’ll have a very meta
experience, if you happen to be watching this while on the
demo page trying out these parameters. So the main thing to keep in
mind though is that the controls at the bottom
over here did not disappear during playback. And if I were to go over here
and change the autohide to 1, Update Player– it says, loading in the player
with the parameters– you’ll see that when I mouse
over, the controls are there. When I move the mouse away,
the controls disappear. So for experiences where you
want maybe a more of lean-back type of situation, where people
aren’t going to be interacting with the controls,
or you don’t want the controls to overlay the video playback,
it’s a very useful parameter. Autoplay is next on the
list alphabetically. Somewhat self-explanatory, if
you add in the autoplay parameter, then the video will
start playing back as soon as the iframe embed is loaded
on the page. I’ll give a quick demo
of that over here. And this time, instead of using
the player demo page, I’m going to use that jsFiddle
that we have set up. And I’m going to just change
the autoplay value to 1. I’m going to click Run. And you could see,
here’s the embed. It started playing as soon
as the page loads. So there are certain scenarios
where that’s useful, certain scenarios where it’s not. You have to use your judgment
as to whether autoplaying is the right thing to do. cc_load_policy is something that
controls whether closed captions or subtitles are
displayed by default. And the default behavior–
we don’t set anything for cc_load_policy– is that the user’s preferences
[? basic ?] on YouTube. There is a way of going in and
saying whether you want closed captions or you don’t want
closed captions. That’s normally what
takes effect. If you have a specific video and
you know that you always want the closed captions to
be shown, you could set cc_load_policy to 1. Color’s a bit interesting. It’s not something that I see
widely used and necessarily, but there are some cases where
you might want a little bit of flair, let’s say,
in your player. And you don’t want the
default behavior. So I’m going to go to the
player demo page really quickly and just show
you what it does. You could set color to white
instead of red, and you update the player. Controls should look slightly
different depending upon whether they’re red or white. So it just basically changes the
branding a little bit on the player. Not necessarily the most useful
thing in the world, but it does give you a little
bit more control. Speaking of control, next item
alphabetically is controls. And this is actually
quite useful. There are cases where you can
actually see a lot of performance benefits by changing
this value from the defaults to a specific
option, which is 2. We have a note in the
documentation explaining more about what this does. And if you read the note, it
says that controls=2 can give you a performance improvement
over the default behavior. And the reason why that is is
controls=2 has a way of loading the iframe embedded
player that does not initialize the underlying
Flash player by default. It doesn’t initialize it until
you actually click on the video thumbnail to start
the playback. This obviously only applies to
playbacks that do involve the Flash player. The iframe player might decide
that HTML5 video is going to be used instead, in which case
this isn’t quite as important. But in situations where Flash
playback is being used, you could really see a significant
performance benefit from setting controls=2. And that might be the default
that we use at some point in the future, as mentioned here,
as soon as some UI issues are worked out. And I’m going to give you an
example of how you could see that performance benefit. It mainly comes across
when you have– let’s say, I don’t want to say
a specific number, but if you have multiple iframe embeds
on the same page. So this one over here has– I think there might be 50 from
the Google Developers channel. So the first thing that we’re
going to look at is behavior pretty much by default, where
there’s controls=1 or if you leave out controls. It’s the default. And it can take some time for
these underlying Flash players to all initialize, and can add
some latency to the point where things look like
they’re ready to be interacted with on the page. So not necessarily the
best user experience. If you take the same thing and
you change it to controls equals 2 explicitly, then you
should see a much better performance. It’s quite remarkable,
actually. So what’s going on? [? You can see ?] now again,
it’s just loading in these thumbnails. It’s not initializing the Flash
player for each video. And you could have– I don’t want to say you should
put thousands of embeds on the same page– but if you do happen
to have a large number of embeds on the page, you
will see a difference. So very important to
keep that in mind. A few other parameters
that are not necessarily as exciting. There’s keyboard support for
the ActionScript player. I’m not really sure why you
would want to turn this off. I think it’s actually kind of
nice to keep it on, but we do have the option of turning
it off if you want. This particular parameter
is quite important, the enablejsapi. And what it’ll let you do is
ensure that you are able to talk to the iframe player
on the page using the JavaScript API. So as I mentioned, we’re not
actually going to be covering anything about the JavaScript
API in this particular session, but plenty of
people have used it. And the one case where you
really need to be sure you’re explicitly setting this is when
you’re writing the iframe tag directly to the page. So kind of like this. Because when you’re
using the YT. Player constructor, it pretty
much will be set automatically for you by default. Just because by virtue of the
fact that you’re using JavaScript to initialize the
player, chances are you are going to want to talk to the
player with JavaScript. So it always gets set for you. But that’s not the case if you
explicitly are writing an iframe tag to a page. So you really do need to make
sure there that you have enabled jsapi set to 1. And that’s necessary in order to
talk to the iframe player. The end tag, and a little
bit further down the alphabet is start. So these are two corresponding
tags. This gives you a really easy way
of putting an embed on a page that has its custom end
time and a custom start time. So if you have a three-minute
video and you really want to embed 30 seconds in the middle
of the video, you could use those two tags to do it. As soon as playback reaches
the end tag, playback will effectively stop. So that could be useful. fs parameter– not super useful anymore. Basically, it lets you control
whether there is a full-screen button on the ActionScript
3.0 player. But I don’t think it has an
effect on the HTML5 player. So not really sure why you would
want to change that. iv_load_policy is something that
controls whether, I guess interactive video
annotations– for lack of a better way of
describing it– is shown on your video by default. So there’s a couple of different
values over here. You use 1 or 3. Basically, setting at 1 will
make sure that those annotations are shown. Setting it to 3 will make
sure that they’re not shown by default. But at any point, the user can
change the setting explicitly in the player, if they want to
show or hide the annotations. List is a really interesting
one. And there is quite a bit to
talk about with list. So I’m actually going to defer
at this point to a whole blog post that we put together to
talk about the different types of values that the list
parameter and the listType parameter, which is
an associated parameter, can take. I’ll link to this blog post in
the video annotations, so you can read it in more detail. But the long and short of it is
that it’s a really easy way to take a simple embedded player
on your page and use that to display a list of videos
without having to hard code the video IDs in advance. So you could have one specific
player on your page and say, play back the most recent videos
from a specific YouTube channel or specific playlist or
specific search term, even. So you could say, this is an
embedded player that will show the latest videos that
match the search from the YouTube API. Something along those lines. It’s quite useful. I don’t think as many people
know about it as they should. So hopefully people will watch
this and start using it a little bit more. listType goes hand in hand
with the list parameter. There is a loop parameter. And the loop parameter will– as explained in the
documentation– allow you to automatically
restart playback of a video when the playback has ended. You have to have a little bit of
a hack, if you’re trying to do this for a single video,
where you create a playlist that has only one video
entry in it. So we have a little bit
more info there. modestbranding is something
that’s covered in a different blog post, which we will also
link to from the annotation. And it talks about the option
down here at the bottom. It’s not exactly a fully
logoless player. There still is a YouTube logo
involved that shows, I think, on the pause screen in the upper
right-hand corner, or in the queued screen. But it is one parameter that you
could set to tone down the YouTube branding
on the player. And that’s something that you
might want to keep in mind if you have a scenario where you
want to embed, but don’t want to make it fully YouTubed. The origin parameter is
something that can be used when you are using the iframe
embed tag, and you’re going to be interacting with the iframe
embed using JavaScript. So as mentioned before, you
might want to explicitly put in enablejsapi. You also might want to
put in the origin parameter over here. And you set it equal to the full
URL for your web page. And this is a security mechanism
to make sure that only JavaScript that’s run from
your host web page is able to talk to the player. And if you’re using the YT. Player constructor, it gets
set automatically for you. So this is another instance
where you really only have to worry about this when you’re
explicitly writing out an iframe tag. And sometimes people run into
issues where they explicitly were using the iframe tag, and
they’re trying to talk to it using JavaScript, but their
code just isn’t working. One thing to debug in that case
is check to see whether you are setting the
origin parameter. And if you are, make sure that
it’s really set to the full URL of the host name
for your site. playerapiid– this isn’t really relevant
anymore. It’s more of a way of using the
older JavaScript API for identifying your player. There’s a playlist parameter
which is easily confused with the list parameter. And it is something that
actually takes in a different set of values. The playlist parameter takes
in a list of video IDs. So this does not have to
be a real playlist, a [? list that ?] exists
on YouTube. It doesn’t have to be anything
that uploads from a specific channel. It could just be a list of any
video IDs that you want. And it’s a way of generating a
dynamic, on-the-fly playlist. So some use cases where
that might be useful. There’s the rel parameter. And this controls whether or not
the end screen of a video will display related
videos or not. Most folks are familiar with the
fact that once you reach the end of a YouTube video,
you’ll see some configuration of thumbnails with suggestions
for other videos to play. We do have the ability to turn
that off if you feel like you do not want that
on your embeds. showinfo is something that will
control what is displayed initially in the
queued states. There’s ways of taking the
default behavior and kind of toning it down a bit, again,
where you don’t see quite as much before the video starts. And you can set it to
show info equal 0, if you want that. showinfo’s actually used
in another case. And that’s when you’re using
the list player. And explicitly setting showinfo
equal to 1 will make it so that there is a list of
queued videos in the playlist in your list player. So if we look over here,
this is a case where showinfo is set to 1. This is a playlist player that’s
loading everything from Google Developers. And you’ll see, before playback
has even started, you have this handy thumbnail for
all the videos that are queued up in the playlist for
the next videos. It will let you choose what
you want to start with. So it is actually quite useful
for scenarios where you’re doing the list player. Start parameter we really
covered before, hand in hand with the end parameter. And the last one is the
theme parameter. This is something similar to
that earlier color parameter that just lets you change the
default way that the player looks and gives you some degree
of customization in that regard. There are now a couple of
deprecated parameters. I’m not going to cover those. They’re deprecated
for a reason. We don’t want folks using
them anymore. I wanted to point out that
there are occasionally– I don’t want to say rumors–
but certain parameters out there that people pass around
and say, hey, you can use this player parameter to force HTML5
playback, or use this player parameter to force
playback in a certain quality level or something along
those lines. Those are undocumented
for a reason. We really do not want people to
use parameters that aren’t explicitly mentioned in the
documentation, partly because we’re not fully committed
to supporting them. They might sometimes work in
some cases, and they might stop working at any time
in the future. So we really don’t want people
to build things that rely on those parameters. And there’s also just cases
where we want control to be in the hands of the person who’s
viewing the embed. So we want control over the
default playback to really lie in the person who’s using the
web browser and might have Flash enabled. Or the default auto quality for
the quality level in many cases gives the best playback
experience. So if you don’t see something
listed as a supported parameter, please
don’t use it. And if you do happen to find
some parameters, please don’t complain if they ever break at
some point in the future. I guess that’s the
main takeaway. That covers the list of all
the supported parameters. We had a lot of different
web material here. And be sure to check out the
annotations on the video for links to everything that
we covered today. Thanks very much for watching. And we’ll see everybody
next week. Cheers.