The HTML video element needs to go back on the drawing board
ctrl.blog
ctrl.blog
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.)
Everyone hangs out on Daily Motion, Vimeo, Cinnamon, D.Tube, and PeerTube all the time. Right?
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>
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.
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.
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!
Can you elaborate?
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.
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.
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.
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.
https://www.avvo.com/legal-guides/ugc/copyright-101-is-strea...
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 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, ...)
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.
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.
Disclaimer: Founder of service that lets you use <smartvideo> tag with raw, unfiltered videos, and automatically turns them into optimized, streaming, cdn enabled playback.
Streaming video is too hard, 100% agree with that, but <video/> element is the reason nor the biggest problem. Biggest pain in my opinion is DRM. That is huge pain in the ass which is poorly standardised (getting better but still) and is constantly broken. Second is transcoding, which is hard because it is hugely complicated problem. Even after the years I don’t feel I understand more than 10% of what is going on. Luckily there are companies like Bitmovin and Mux that can help with those 2. Distribution of the video is easier with modern CDNs, it’s just insanely expensive. Where we could do better though is to better integrate low level libraries like VideoJS and Shaka to web frameworks like React or Vue. Everything that is out there feels like hobby project someone just played with. Full respect and big thanks to the authors for putting it out though. You did way better than me in supporting open-source.
The html video tag is the smallest bit of the problem, adaptive streaming is much more complex and there isn’t just one file per resolution.
For that matter, I want audio sources to support media queries, so that you can present dark and ominous music in dark mode and light and bouncy music in light mode if you really want to, but mostly just so that <source>’s properties are consistent regardless of the parent element.
As for making poster support multiple sources, I came up with a technique that makes this work a while back. I should finish that pair of blog posts off. Short version: poster="data:image/svg+xml,<svg><foreignObject><picture><source …/>…</picture></foreignObject></svg>". Yep. Seriously! :-)
Okay I feel like this computer/internet thing has been a grave error, maybe it's time to pack it in and start over.
It may work, but … ugh. This is a spec issue.
You’ll love what they’ve done in Windows 11.
Whereas if you do two videos and hide the one that doesn’t match, and you have a computer that switches to dark mode at sunset or based on ambient light, your video is going to stop playing and you’ll lose your place as soon as it switches from dark to light or light to dark.
The <video> element is very capable, but the amount of combinations of possible video files has greatly increased. When it was developed, the biggest complexities were codec compatibility, and fallbacks.
While it would be possible to have the ability to select different video sizes/quality rates based on HTML elements and attributes, it is likely impractical to handle, say, adaptive video streaming (where the quality of the video is based on the connection), purely in HTML.
I'm no fan of Javascript for everything, but handling video is a scenario where there's generally a need, due to the complexities of video streaming.
But then you still want to serve a small video file (320px wide) for mobile and a larger one for desktop (600px wide).
> While it would be possible to have the ability to select different video sizes/quality rates based on HTML elements and attributes, it is likely impractical to handle, say, adaptive video streaming (where the quality of the video is based on the connection), purely in HTML.
Adaptive streaming where the quality changes over time as you watch is only needed for longer videos. You don’t need that for a short one minute video or a GIF equivalent. Just picking a resolution appropriate to the screen size would be enough.
Safari does this (at least the src), but nobody can really use it since Chrome doesn’t.
There’s a huge thread somewhere of devs arguing that Chrome should implement. I would fall on the implement side. If we want to replace gifs with better formats browsers should make it easy.
https://bugs.chromium.org/p/chromium/issues/detail?id=791658 https://github.com/whatwg/html/issues/7141
What about addressing the problem from the HTTP-side of things: have a simple video tag (just defining the viewport and an endpoint) and a host response providing options (as a manifest), which may be selected by the browser situationally?
HTTP Client Hints spec can send the viewport size and pixel ratio and even a low-bandwidth preference as HTTP request headers. It’s only supported in Chrome and requires extra round trips. The other browser vendors have been unwilling to implement the spec.
(Putting all information in the tag is a bit, as if we were to define in an image tag, whether the image was encoded progressive or not, what size the color pallet is, etc. However, we can't put this in a video header, as this comes too late, as we decided for a specific source already. But there's the 300 "Multiple Choices" response, maybe, we may build on this.)
Edit: What really matters to an editor of an embedding document is selecting an endpoint (like "example.com/videos/cute-cat1") and defining its visual properties, probably responsively and by means of CSS. An editor is not concerned with quality levels and bit rates vs bandwidth, actual display size, etc. The editor even isn't in any position to make a suitable decision for every situation beforehand. Available options should be advertised by the endpoint and the browser should select adaptively the optimum to fill the viewport on its own behalf (and not by delegating this to the providing host by means of a handshake, which makes things not only unnecessarily complex, but also leaks information).
I like the idea of a human readable manifest to select for preffered quality based on the browser environment. That would be much preffered over loading the tag. Maybe just a quality attribute and point it to the manifest. A man can dream.
now try the same in any other runtime... go mess with different compressions, encodings, color spaces, list goes on and on...
Isn't the cardinal rule of the web to not waste people's time?
This has certainly not been my experience on the web!
Jokes aside, I agree with your point on controls loading first.
Personally I love how powerful the video tag is, you can even render it to a canvas tag and do all sorts of manipulations on top of it. But it’s the preparation of videos on the web that’s still a huge pain (and why folks use things like YouTube embeds): you’ve got your h264 standard encoding, but if you care about your users you’ll want to save them bandwidth and make h265 and vp9 encodings as well. What settings you apply to each encoding feels like a dark art to me, thankfully there are cloud services to help you but I wish it was simpler.
- prefers-reduced-motion - prefers-reduced-data
… without JS.
Edit to add: also, Safari won’t play <video> at all if your server doesn’t support HLS/respond appropriately to range headers. Which is probably well-meaning but absurd.
Edit:
Without range requests the browser can't play a video that hasn't been saved correctly. The MP4 format supports the header atom written to the end of a file, so in cases where a file is streamed to disk a header isn't written until you know the stream is complete and can fill in the details. "Web Optimized" (there's a variety of names) are MP4s with the header atom written at the beginning of the file with the media atoms following.
Without the header data you can't know much about the media tracks in the file so you can't effectively set up a decoder pipeline. A browser will request a file and if it doesn't find the header atom will use a range request to grab the last few kilobytes of the file to grab the header data. It can then set up the decode pipeline and play back the file.
If the server doesn't support range headers and the file isn't "Web Optimized" a browser needs to download the whole file before it can begin playing it. HLS/DASH streams store a lot of data in the manifest file and the MPEG-TS/MP4 chunk streams contain redundant track metadata to inform the decoder pipeline.
Wow, really? You can write a full HTTP 1.0 server in a 15th-20th of that.
I can't see those two interactions needing that much code.
edit: that's gzipped, but still, less than 600KB w/ many more features.
The point is that's for a feature packed video lib which also covers resolution handling
(not sure if it handles fullscreen resolution changing, but I don't see why they wouldn't.)
If you are just doing standard video playback, something like video.js is an order of magnitude less code (on the order of 50KB minimized + gziped).
Youtube is not an option as it requires a popup for the General Data Protection Regulation.
The only working thing we have atm is OS specific forced downloads that require downloading the entire file.
Thus therefore as a result thereof the reason forwhich one can not put a video on the website is that playback may be terminated unexpectedly. It's just too embarrassing, I don't want to see myself explain why it doesn't work to anyone.
You can disable controls entirely or javascript the seek event but I don't consider those nice solutions. The video player should work by default. The millions of crappy web devs simply want to use it without investigating the weirdness and hacking up some event listener to allow seeking in already downloaded parts. Or is that seeking backwards only? I don't want to know the answer honestly.
Perhaps I should just offer a download? Just like things use to work? But then the browser may play it in a tab and pretend seeking is supported again.
Ah! So I have to use the old forced binary file download with application/octet-stream so that the user can watch the video in a different player. One with expected behavior.
I just want to drop the file in a folder and send the link to someone. Adding a header to it is already asking to much.
I could see myself bother to provide multiple formats in multiple sizes because that is an actual hard problem (I'm lying to be polite here)
I find it amazing how well everything in our world works. We humans are very hard working but we tend to do everything wrong most of the time. Look how much effort it took to get embeded video on a web page. It actually works! Well, almost....
This comment is getting so long, I'm probably wrong in more than one way, made a dozen grammatical boo boo's and misspelled a bunch of words. Still, plenty of room left for mis-interpretations and -understandings.
I hope no one is watching us.
It's very easy to say things like this when you're not proposing a standards update that browser developers then have to implement. HTML is littered with examples of elements, attributes, whatever, that aren't consistently supported because browser developers disagree with, or just don't know, the details of how they're supposed to work. Case and point, focus management when invoking or moving within a modal created via the native dialog element.
In theory, this single user would be okay with the fact that switching video quality or size might do something weird if the underlying videos aren't compatible because of length. In practice, someone has to develop the code to make or let the "something weird" happen, define what it is, define what conditions trigger it, and so on.
I would argue it shouldn't even need JS in the first place.
But then again Youtube solves that problem for you with practically zero code.
The videos play almost instantaneously, in any browser with DRM installed and without, even on, e.g., a 2013 netbook.
I think that, just as with many other things in HTML/JS land, there is a way to do it simply and elegantly, though it requires paging through dozens of StackO posts, random docs, etc.
For example, I used to think that paste-to-upload was difficult to achieve, until I'd paged through all that and discovered it's no more than a couple of lines, including creating the form elements and all.
Dig deep and you will find the way. There's no need to use more complicated options which also don't work in 99% of existing browser base.
However, Gfycat features many anti-patterns, such as heavy layout, inaccessible scrolling and cookie notification overlay, while RT omits these.
Gfycat et all aren't lead-ins to paid services so they're going to festoon pages with low paying ads. The porn content is also usually more fungible than a meme gif. A particular gif of a cat or something is what people are after vs the porn where it's anything that turns them on.
Youtube is the best solution.
Video/audio tags works as good as image tags.
I think apple shipped H265 but they are also part of the AV1 consortium
Yes.
Keeping things simple is arguably better. MP4 is wonderful. MP3 is also wonderful. Most browsers use these well established codecs as baseline. A few matchmedia queries and rather unreliable navigator - et voilà - my method.
I literally hacked together from scratch a simple HLS stream player in half an hour using VideoJS, not having worked with that one (or video streaming in browsers) before at all, and I'm a backend/ops-focused person. Further two hours saw the addition of a basic playlist for the stream recordings of nginx-rtmp.
I agree that the HTML5 video element lacks features, but the existence of VideoJS alleviates a lot of that.