[jasode]

>Anyhow: the point was that it’s too difficult to embed videos even if you’re willing to bear the hosting cost.

That may be one reason but like the gp, I also disagree with the blog's author that it's the "underlying problem".

To further add to gp's point, Amazon AWS has:

+ tech staff with skills to deliver HTML video

+ billions to pay for self-hosting videos on its own infrastructure

+ incentives to avoid a competitor such as Google

... And yet, their official AWS re:invent page of videos points to urls on Youtube:

https://aws.amazon.com/blogs/database/amazon-dynamodb-sessio...

Microsoft is another company with technical chops internally but they also uploaded some (not all) of their Channel9 videos to Youtube instead of self-hosting them.

Yes, the complexity of HLS and DASH is also true but it's way down the list of reasons why many people host on Youtube:

+ $0 hosting costs

+ ad monetization (and by extension, viewership statistics tools)

+ audience reach (via recommendations, etc)

A hypothetical improved <VIDEO> HTML tag does not alter the motivations in the bullet points above.

[delta1]

I suspect part of that equation is that it’s going to be posted to the YouTube channel anyway, so why not just embed it from there too?

[lmkg]

Exactly. One aspect of the issue is the difficulty of self-hosting video content, but another aspect is everything else YouTube does beyond hosting the file. It's a marketing and distribution platform.

Linking from your website to YouTube will let people find your Channel, getting people to come back after the one video. People can save videos for later, youtube videos will show up in search results. You want views on your website to increment the "Views" count on YouTube because that's a signal of legitimacy. You want to be able to pull one report of "how many people are watching our video content?" without having to add numbers from YouTube and your own hosting.

All of these are benefits (or lock-in) that a YouTube embed provides beyond just hosting the file. A <video> element has no way of getting most of those.

[mikepurvis]

The extra views are probably good for their numbers too, if that's something they care about.

[supernovae]

Microsoft spent a lot of money trying to build a competitor to Youtube (And Google video) back in the day. (Soapbox) - But... no one wanted it.

People have this weird habit of just following the trends and at the time, using anything and everything google did without question.

Now they don't like it?

Go use vimeo and pay for distribution with services like Cloudflare

[latexr]

> using anything and everything google did without question.

Google Video[1] launched one month before YouTube, yet the latter won so decisively Google bought them a year later.

> Now they don't like it?

It’s been over a decade. You’re allowed to change your opinion and dislike something you previously liked, especially if the thing changed[2].

[1]: https://en.wikipedia.org/wiki/Google_Video

[2]: https://web.archive.org/web/20150323121117/http://doonesbury...

[ethbr0]

Since YouTube was already growing significantly before Google bought it, I'm not sure "Google" is the right answer.

A better one is "easy sharing" + "pirated content" + "Lonely Island."

[supernovae]

True, it was a wild west growth though - whereas Google put its PPC monetization behind it when it was purchased and no one else could compete with that prowess.

[discreditable]

> tech staff with skills to deliver HTML video

A big one that hits small sites I think is simply tech staff with the ability to properly encode HTML video. You lose them as soon as you say vp9, h264, or av1.

[acdha]

This is true, but I would also suggest that small sites would like be better off simply doing a single H.264 file, which is what comes natively off of many cameras and is an export preset in almost everything. If you're not publishing long high-res videos for many thousands of people, you're almost certainly going to be paying more in staff time than you see from the bandwidth savings.

[giantrobot]

But it's not only about bandwidth. An h.264 video file off a camera is rarely going to be a good choice to throw up on the web.

Cameras write files with extremely short GOPs and overly high bitrates because they have to capture live video and can't know what the next second of content will look like. They need to use settings such that pretty much anything captured by the lens will be captured in good quality.

An offline encoded h.264 video can have far more processing thrown at it. Typically you'll see longer GOPs and a much tighter tuning of bitrates and more features like b-frames and CABAC encoding enabled.

A file directly off a camera can have bitrates of several tens of megabits a second. Even short videos are huge and won't stream well to many. A lot of devices also have limits on the profiles of video they'll even decode.

Someone throwing a camera's direct output onto YouTube can be guaranteed better than 99% of all devices on the Internet can be served a watchable version of the content.

[seg_lol]

Well, if we are going to make hypothetical tags. I'd have a video tag that includes transcoding and hosting.

The next hypothetical tag would be an <vqgan>A humpback whale in a trench coat stares into the camera and says, "Here is looking at you kid" and the camera reverses to show a goat</vqgan>

[ethbr0]

Has anyone used Cloudflare Stream [0] [1]?

Because my first thought to your above was "Hmm, who has massive bandwidth and storage and could offer something at a competitive price?"

[0] https://developers.cloudflare.com/stream/

[1] https://developers.cloudflare.com/stream/faq