> We’ve had the HTML <video> element for over a decade. Yet, everyone still defaults to embedding YouTube frames instead of hosting their own videos. The underlying problem is that the <video> element isn’t suitable for embedding short video files on webpages.
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.)
It’s not just small websites, though. Government information websites use YouTube too. Even activist websites criticizing the tech monopolies host with YouTube embeds. Even the distributed web/P2P platform IPFS hosts videos on YouTube instead of using it’s own P2P stack.
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.
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.
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.
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.
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.
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.
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.
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>
No one wants to host a 480p video and pay for it. They want to host a 4k video for free. YouTube captured the entire market by giving it away and now it's the expectation.
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.
That doesn't mean people don't want to serve 4K video.
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 wasn't talking about consumption, I was talking about the people making the videos. They do not want people to watch it in 480p unless it's the last resort. It's a similar mindset to famous directors hating when people watch their movies on phones.
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.
Thankfully YouTube gives you different qualities depending on screen size and network speed, without you having to recode the video a dozen times. And for free. ;)
Leave it to HackerNews to downvote the only sensible answer in this thread, rooted in a simple technical understanding of how distributed caching works.
It's probably not downvoted because it's wrong, but it's because it doesn't help anyone who don't have "simple technical understanding of how distributed caching works."
I don't disagree but a nice counter example is Chaos Computer Club. They host their content on https://media.ccc.de/. With all the videos from their conferences it is not very small site either.
In their case, as in certain other online video providers, the reason not to use YouTube is they're likely to remove the videos for some kind of policy violation.
Agree with your points, but the HTML5 video tag is still broken.
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.
Can you elaborate on the "with certain sizes" please? If the video file is something in the tens of GBs, it would be quite understandable for the browser to avoid keeping the whole file in memory.
Disk caching is still a thing. Kids watch the same videos on repeat for hours on end, so maybe almost-indiscriminately caching the entirety of the last watched video would be a good idea.
Disk caching probably invokes Flava Works vs Gunter [1] which is a case that distinguishes streaming from copying under copyright law. There are probably later updates to this, but this is the one I'm aware of.
Leave it to the copyright people to make a huge legal mess out of the simplest concepts. Now people can't even cache data without lawyers showing up. I wonder how long it's gonna take before I see them arguing memcpy should be illegal.
So maybe be a bit smarter about it. The browser will know if the video is set to loop unless that is done with JS. In all cases it will know if it has looped and can start caching then.
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.
Why? I have 64 GB of RAM. Linux is using most of it to cache file system pages. I already do that kind of stuff anyway when I download videos to tmpfs. The browser should just use the memory.
> That's it, if you leave a browser open... it will suck your bandwidth forever.
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.
This is correct. I’ve written the JavaScript to select sizes dynamically – it’s 599KB smaller than the 600KB claimed.
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.
I blame Google for making mpeg-dash so inaccessible.
Want/need to use DRM? You won't receive a response from Google/widevine, no matter how often you write to them, despite them claiming otherwise and no matter how much money you already earn them via their advertising network.
They have the defacto monopoly and they want to keep it.
This doesn’t mean DRM is impossible, it means it’s only available to really big players who can cut deals with Google. Which makes it one of the few parts of the Web API that smaller companies and independent devs can’t use (not that I’d personally want to). Keeping it tightly controlled like that also makes it harder to crack.
Thanks I didn't know about those.
The previously successful site that needed DRM isn't online anymore because we couldn't find a solution to the streaming audio/video problem with DRM and monetization.
Because of that we lost our access to content so the site had to shut down.
For 9 years it was the leading news source for an, unnamed here, African country.
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.
Even without the storage/bandwidth problem. Why develop internally a system to upload and distribute video which will have, at best, the functionalities YouTube provides for free.
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.
> The reason small websites prefer YouTube embeds is because they want to avoid bearing the storage and bandwidth costs of serving it.
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, ...)
Exactly correct. Video is on a different level of cost/complexity than images, html, etc. Video is not one of those things you can have your build pipeline automatically optimize for you as part of deploy (well at least not if you want deploys in a reasonable amount of time).
Disclaimer: Founder of service that lets you use <smartvideo> tag with raw, unfiltered videos, and automatically turns them into optimized, streaming, cdn enabled playback.
One of the many reasons I use YT or Vimeo is that I simply upload the high-res render, edit some metadata and I'm done with a simple embed in most cases. Alternate versions for lower bandwidth are automatically made and automatically served, streaming is taking care of (YT really excels here), and there is a nice API to do interactive stuff.
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.
> And the logistical costs of transcoding it to N different resolutions times M different codecs.
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.
Youtube is free vs others which are paid. And youtube is the most known video hosting service while I have barely heard of others. Are they really competitors?
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.)