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.)
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.
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 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.
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?"
while True:
downloadVideoFromDW2A();
while True:
downloadIndexHtmlFromCSMPLTN();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.
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!
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?
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.
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.
It may work, but … ugh. This is a spec issue.
Wow, really? You can write a full HTTP 1.0 server in a 15th-20th of that.
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).
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.)
now try the same in any other runtime... go mess with different compressions, encodings, color spaces, list goes on and on...
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.
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.
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.
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.
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
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.
- 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.
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.
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.
I think apple shipped H265 but they are also part of the AV1 consortium
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.
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.
Youtube is the best solution.
Video/audio tags works as good as image tags.
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.