Anyhow: the point was that it’s too difficult to embed videos even if you’re willing to bear the hosting cost.
It costs roughly 0.0015 USD per hour video in 480p/VP9 hosted with BunnyCDN. The cost is manageable.
Anyhow: the point was that it’s too difficult to embed videos even if you’re willing to bear the hosting cost.
It costs roughly 0.0015 USD per hour video in 480p/VP9 hosted with BunnyCDN. The cost is manageable.
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.
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.
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.
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
A better one is "easy sharing" + "pirated content" + "Lonely Island."
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...
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.
Because my first thought to your above was "Hmm, who has massive bandwidth and storage and could offer something at a competitive price?"
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>
It means they want the video to be encoded in multiple resolutions for different levels of connection. Another thing that's not necessarily trivial, especially at scale.
Some people want 480p video.
Some people want 1080p video.
Some people want 4k video.
Even if the browser <video> tag did a great job at codec and resolution negotiation you still have to encode _at a minimum_ three copies of the video to hit the qualities. Multiply that each time you need a different codec for different devices.
Or, upload one video to Youtube.
I've fought and lost this battle many many times, and have used mobile bandwidth as a reason too.
High resolution video hosting/streaming is free, so no one wants to pay to host it. I think there are major downsides to hosting on YouTube, but in my experience the vast majority of people do not care.
while True:
downloadVideoFromDW2A();
Good luck managing this. while True:
downloadIndexHtmlFromCSMPLTN();Leave it to HackerNews to downvote the only sensible answer in this thread, rooted in a simple technical understanding of how distributed caching works.