All language subtitles for 27 - Video.en

- 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, maybe, this is pretty cool.

It's very simple.

There are a couple problems though 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 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 depth, 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 a 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 image file formats that we use

are owned by someone who's charging licensing fees.

They're all public, anyone can use JPEG or GIF.

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 codec 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 codec at the same time.

We can use H.264 and WebM.

And, once there're 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 will play the first file that it understands.

Which brings us to the second problem to solve.

I've got a 480p file here

and this is probably a good choice for users

who have a smaller screen and a slower network connection.

Although, maybe an even smaller video

would be good for them, 360p or 240p.

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 the 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 want to send them a 720 video,

but then, as soon as their network speed improves,

we want to 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 talked about captions.