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.
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.
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
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...
A better one is "easy sharing" + "pirated content" + "Lonely Island."
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.
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>
Because my first thought to your above was "Hmm, who has massive bandwidth and storage and could offer something at a competitive price?"
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.
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.
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();
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.
For example, on many browsers (Chrome and Safari at least) if you put a video on loop, with certain sizes, the internal logic makes it re-download the same video ignoring any server cache headers. That's it, if you leave a browser open with the same video in loop, it will suck your bandwidth forever.
I think the same happens if you seek through video playback.
To avoid this you need to put in some javascript that preload the whole video and make it a blob, or something similar.
https://www.avvo.com/legal-guides/ugc/copyright-101-is-strea...
Especially for mobile devices with fairly small storage sizes, this can easily represent a sizable fraction of their total write endurance.
And just you don't need to limit all devices by the lowest common denominator either.
Which is the entire point of the article: Most of the time even trivial video playback is done using JS due to the shortcomings of the <video> tag itself! This also means that browsers are unable to perform such optimizations.
> And just you don't need to limit all devices by the lowest common denominator either.
Unless the video site is intentionally sending cache control headers preventing caching of the video assets, this behavior is presumably already caused by the browser itself, not the site.
Funny you mention that, google / youtube does the same thing to jank'ify its own user metrics on my laptop, regardless of whether it's a 5 minute video or a 3 hour video (by auto-playing the next one). Even if the laptop is asleep.
The hard part is the transcode infrastructure, and that’s frequently unnecessary for the small videos: if you use multiple sizes and formats, you increase the amount of traffic you need to see cache hits. YouTube has built a ton of infrastructure but most sites won’t see enough return to be worth the ops cost.
Thanks Google!
We both know that's BS. I never thought I'd say this but Google is doing good by not selling this "product" to anyone that just asks.
Can you elaborate?
FairPlay and PlayReady are there too.
So I see, Apple and Microsoft have offers, but that's also not open source or easily accessible? It doesn't matter to me anymore personally. Google cut their own source of income by denying us access to widevine, since the site was fully monetized via Google.
The day YouTube will charge for the embedding, a lot a website will find something like. Like a lot of website started using a solution based on OpenStreetMap when Google maps changed its pricing.
YouTube also works 100% of the time. I've encountered countless other sites, including major ones, like CNN or The Guardian, where half of the time video doesn't work, or it's terrible in some way (impossible to seek or pause, ...)
Disclaimer: Founder of service that lets you use <smartvideo> tag with raw, unfiltered videos, and automatically turns them into optimized, streaming, cdn enabled playback.
I do use the <video> element from time to time, but only if I want to optimise the loading of an autoplaying video or there is some other technical reason.
If only we had easy access to scalable video (SVC). If a container format supported it, the web browser could perform range queries to get the interesting bits as needed, no need for additional code.
And the uploader would need to transcode only once. This doesn't solve the codecs issue, but I think you could get away with offering one or two common codecs.
Everyone hangs out on Daily Motion, Vimeo, Cinnamon, D.Tube, and PeerTube all the time. Right?
The reason small websites prefer YouTube embeds is because they want to avoid bearing the storage and bandwidth costs of serving it. And the logistical costs of transcoding it to N different resolutions times M different codecs. No amount of improvements to HTML alone will change that. (Not that the changes are entirely worthless, but they still do not and cannot address the real issue.)