- The power of the web has revolutionized the way
that we connect and share experiences.
Film, television and, well, teaching,
have all been transformed
by the ability of the web to transmit video.
One way to put video content on a webpage,
is to use the video element in HTML.
Just like the audio element, we can create a video element
with both an opening and a closing tag.
We use the source attribute to point to a video file,
and we add the controls attribute
to tell the browser to create a video player for us.
Great. We're done now, right?
Well, there are a couple problems for us to solve.
The first has to do with how videos are encoded.
For the simplest version of this demo,
I've made a video file that is 480p.
Compressed using the h.264 codec
delivered as an MP4 file.
480p means that there are 480 lines of resolution
or 720 pixels wide by 400 pixels tall.
It's standard def, not HD, not 4K.
I'm using the H.264 codec
because it has the widest support across browsers
at the moment, much like choosing between PNG,
JPEG, GIF or SVG for images.
There are a bunch of different codecs
which a video file might be encoded.
Video files contain a lot of data and can get incredibly big
when they aren't compressed,
far too big to travel across the internet.
So any internet video is using a pretty hefty mechanism
for smashing all the data
into the smallest possible package.
There've been many attempts to make the ultimate codec,
Real Video, Sorenson, Windows Media Flash, H.263.
There've been a lot of codecs.
From about 2015 to 2020,
the H.264 codec is the one that's dominated.
It's the codec that most of us are using most of the time.
But the thing is, it's not open source.
It's patented.
It's owned by consortium that charges fees
for every device, every operating system,
every browser, every camera,
anything that wants to be able to record,
compress or play H.264 files.
And they are about to charge way more for H.265.
None of the underlying technology
on the web should be patented.
HTML isn't patented.
You don't have to pay to use CSS.
Why should video codecs be different?
To fix this, a lot of effort has gone into creating
a truly open, not patented,
but still super awesome video codec.
Folks had hoped that WebM would emerge the winner,
but it's still unclear if it will.
More recently, there's great hope
that we finally solved this with AV1.
It's looking like AV1 is a better codac than H.264
and is truly royalty-free.
Time will tell on how things shake out.
The good thing is that the video element has the ability
for us to point to multiple source files.
We can use more than one codac at the same time.
We can use H.264 and WebM,
and once there are tools for making AV1 files,
we can use AV1.
This works the same way
as it does for the audio and picture elements.
We use a source element to list the multiple file formats
with the source attribute to link to the file
and the type attribute to tell the browser
which type of file it is.
The browser would play the first file that it understands,
which brings us to the second problem to solve.
I've got a 480p file here.
What about the people who have a faster connection
and want HD or 4K?
We'd like to send them a pretty big file.
We have a solution for this with images,
with the image source set and picture.
But there's nothing in HTML that will allow us
to send different sizes of video
under different network conditions.
In part, that's because we don't want a device
to get only one moment to make a choice
between, say, standard def and high def.
We want it to make that choice over and over and over again.
Maybe someone has an HD screen,
but the network is kind of slow.
So instead of sending them a 1080p file,
we wanna send them a 720 video.
But then, as soon as their network speed improves,
we wanna switch from 720 to 1080.
This is how Netflix, Hulu, HBO, YouTube, Vimeo
and all those TV apps work.
They're constantly switching from one resolution to another
as people watch, using a technique called
adaptive bitrate streaming.
The whole thing is really complicated.
And basically it requires a server farm
of transcoding robots, which is why,
when you go to put video on a website,
it's likely you might not use the video element.
There's a good chance you'll use embed code
from a video hosting service,
which I'll talk about right after we talk about captions.
It's pretty amazing that we can put audio
and video on a website.
But not everyone can always hear or understand the audio.
Some people are completely deaf.
Other people can hear sometimes,
certain things in certain conditions, but not all the time.
And for people who can hear, well, they can't always listen.
Sometimes people would listen to a video,
but they're someplace where they can't use speakers
and they don't have headphones, or they are listening
but they can't really understand the people who are talking
because of an unfamiliar accent,
or maybe the person who's talking is talking way too fast.
On the web, we have the power that we need
to provide content in multiple ways simultaneously.
So let's add captions
and make our video more accessible to everyone.
To do this, we'll use the track element
and point to a text file.
The video player will provide all the functionality
so a viewer can turn captioning on and off
or switch from one set of subtitles to another.
There are many file formats for captions,
but on the web we wanna use WebVTT, Web Video Text Tracks.
It's basically a plain text file with a VTT extension
that uses a certain convention
for providing the information.
You can see here, each line of text,
with the time code information
that tells the video player when to show each line.
To get these captions to show up on our video,
we put a track element inside the video element.
Just like the sources element,
it's part of a list of options for the browser to use
while rendering the video player.
On the track element, we'll use the source attribute
to point to the file itself.
We'll use the kind attribute to tell the browser
that this is captions.
We'll add a label of English that will show up in the player
as a label for this choice.
We'll use a source lang attribute
to specify which language this is.
And we'll put a default attribute on this track element
to specify that this track is the one we want to use
by default when a user turns on captions.
We can see now that a little captioning icon has appeared.
And when we click on it,
we have options for Off, Auto, and English.
The word English shows up
because that's what I put in my label.
Now I'll add a translation into Spanish
and offer some options for subtitles.
I've got another VTT file, this time in Spanish,
and we'll another track element
inside this same video element.
This time we'll set kind to subtitles,
set source lang to es for Espanola,
and create a label of Espanol.
Now we can see that there's a second choice
in the list of subtitles, and we have Spanish subtitles.
There are a few other options for the kind attribute.
We could create a VTT file that has descriptive information
about what's happening visually in the video
and use kind equals descriptions.
This gives people the option of playing a track
that reads aloud descriptions of what you'll miss
if you aren't looking at the video.
For instance, the astronaut jumps off the ladder
and bounces a bit as he hits the ground.
This makes a video more accessible to the blind
and the visually impaired.
Kind equals chapters gives us a way to provide a text file
that lists the chapters in the video,
giving users a way to jump from one section
in a video to another.
Captions and subtitles are powerful.
And in many places, they're actually required by law.
By providing them, you'll make it far easier for more people
to find, watch or listen to your content.
Add captions and your traffic will go up.
Embedding is taking content from one site
and placing it into the middle of a page on another site.
It's common to embed something complex from a service
that takes care of all the hard parts for you.
So what HTML do we need to know to help us do this?
Well, basically you get the HTML
from the service that you are using.
Let's use YouTube as an example.
Here's a YouTube video that I made.
And let's say I wanna post it on my own website
so people can find it on my domain name
and not have to go to the YouTube website.
I'll look for a Share button or some other clue
about where I can find the embed code.
Here it is, Share.
I see where it says embed, and let me click that.
And I see some options.
Privacy enhanced, that sounds good.
I'll click copy.
And I'll get some code copied to my clipboard.
I'll paste this into my HTML, and wa-la,
now I have a video embedded on the page.
We don't really need to understand what all of this says.
The engineers at YouTube wrote it all for us.
Although, now that we know how to read HTML,
we can see a lot here that we recognize.
The iframe element has several attributes on it,
including height and width.
We could adjust those.
Source is gonna point to the source of the video file.
Iframes are powerful.
There are definitely some securities considerations
to be had about pulling in code from other sites like this.
So, if you're using a CMS that someone else set up,
like it's your job to post content
on a WordPress website or a Drupal website,
there's a good chance that you can't just paste
some random embed code from another website
into your system.
There's a good chance that the CMS is set up
with a different way to allow a URL or a shortcode
from a specifically white labeled source,
and you'll want to talk to someone who knows
how to use your CMS to find out
how to embed things like YouTube videos.
If you're the person building a site,
you probably wanna think about how security will work
when it comes to the iframe element.
If a bunch of different people are gonna be entering
content into a system, you're not gonna wanna
just allow all iframes.
Think about the security.
If it's just you, posting your own videos
on your own website, then it will be fine.
(upbeat music)