After working in video streaming company for several years and writing web player (on top of vjs & shaka) used by millions of users every month I both agree and disagree with the article at the same time.
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.
My reason for desiring the media attribute on video sources is so you can use different videos in dark mode and light mode, with no JavaScript required, which I have definitely done with image sources. (No public examples, sorry; but it’s stuff like including a screenshot of a third-party web app which has its own light and dark modes, so I take a screenshot of each and have it choose the appropriate one.)
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! :-)
The <video> element does have some usages which are underutilized, though: short, perhaps looping video, which can be used instead of animated GIFs.
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.
Hum. Not so sure about this. A fully qualified video tag would be significantly larger than any iframe tag for embedding video (and therefor also unpopular). Also, it still fails to inform a web browser precisely about the options for handling rate issues (e.g., providing information on data rates). Moreover, providing such hosting specific information is probably beyond what a web developer might know and such information might be also subject to change.
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?
might be a bit off topic than what's discussed, but actually I never cease to be amazed by how easy it is to do image processing in browser. want some pixels? pass an img element. moving pixels? pass a video element. dynamic pixels? pass a canvas element. it just works.
now try the same in any other runtime... go mess with different compressions, encodings, color spaces, list goes on and on...
If it happens, I only have one wish: make the controls available even if the video is yet to load. I've no idea why I'm unable to press pause or, say, mute the volume before a video loads. Instead, I have to wait around. I think even my old VHS player would let me press pause before the video had finished loading!
Isn't the cardinal rule of the web to not waste people's time?
Back to the drawing board feels like an exaggeration: most of what’s outlined here could be added non-destructively.
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’d add that the lack of support for media attributes is an accessibility fail. You effectively cannot honor both:
- 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.
There's zero incentive to change anything wrt to video for the gatekeepers of the web due to conflict of interest. Just saying.
> The average JavaScript library for handling video resolutions and full-screen mode switching is about 600 KB
Wow, really? You can write a full HTTP 1.0 server in a 15th-20th of that.
Should also fix seeking if the server doesn't support it. If there is a downloadable video file it should just play. Seeking should provide visual feedback and jump to the selected point only when data is returned while continuing normal playback.
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.
> What if the two video files are of different durations? There’s a hornet’s nest of potential issues, but I’d take the occasional stings over the status quo any week of the day.
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.
>The average JavaScript library for handling video resolutions and full-screen mode switching is about 600 KB. It’s a small overhead for a 15 minute+ video. However, it’s way too much for a short animation or a minute-long presentation.
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.
This is NSFW, but if you want to see how to do HTML video right, check out redgifs.com
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.
Cloudflare Stream takes a lot of the headache out of self hosting video. Highly recommended.
It would be great if <video> tag element could work some things out. There are alternatives to this that work better. Still, the tag is broken. There's nothing we can do up until it updates sometimes.
I like to use YouTube so I have a standard player across all browsers and platforms. I never know what the user is going to see when I use <video>.
I don't know, I use the video tag for videos served from an S3 bucket with great performance. Way better than YouTube for videos under 5 min. Seems to be pretty easy. Maybe the author's issues are more for long videos?
Most websites can't even optimize images, how are they going to optimize video based on the devices?
Youtube is the best solution.
Video/audio tags works as good as image tags.
Any kind of video is just a pia. I avoid it at all costs which is why youtube is so popular - video is just annoying.
This seems like a fairly narrow use case to go back to the drawing board over. I just wish Chrome supported h265
> Maybe I’m asking for a faster horse here
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.
> You also have to spend time learning and integrating a complicated new library into your documents.
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.
> 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.)