[usrbinbash]

> It's absolutely insane to me how bad the user experience is with video nowadays

Has nothing to do with video per se. Normal embeddings, using the standard `<video>` element and no unnecessary JS nonsense, still work the same way they did in the 90s: Right click the video and download it, it's a media element like any other.

The reason why user experience is going to shite, is because turbocapitalism went to work on what was once The Internet, and is trying to turn it into a paywalled profit-machine.

[ryandrake]

I've always found it insane how much software development web sites are willing to undertake, just to avoid using the standard video, audio, and img HTML elements. It's almost hilarious how over engineered everything is, just so they can 'protect' things they are ultimately publishing on the open web.

[jsheard]

Plain <video> elements are easy to download, but not great for streaming, which is what most people are doing nowadays. Much of the JS complexity that gets layered on top is to facilitate adaptive bitrate selection and efficient seeking, and the former is especially important for users on crappier internet connections.

I'm not a fan of how much JS is required to make all that work though, especially given the vast majority of sites are just using one of two standards, HLS or DASH. Ideally the browsers would have those standards built-in so plain <video> elements can handle them (I think Safari is the only one which does that, and they only do HLS).

[kccqzy]

I totally agree. And much of the JS complexity on smaller niche video sites aren’t even implemented properly. On some sites I just open developer console, find the m3u8 file URL and cookies in the request, and download it to view locally.

Browsers generally do allow native seeking if the video is properly encoded and the site supports such niceties as Accept-Range: bytes.

[jsmith45]

Chrome has finally just landed enabled by default native HLS playback support within the past month. See http://crrev.com/c/7047405

I'm not sure what the rollout status actually is at the moment.

[jsheard]

> See go/hls-direct-playback for design and launch stats analysis.

Is that an internal Google wiki or something? I can't find whatever they're referring to.

[demetris]

The standard video element is really nice:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

I have used it on a couple of client sites, and it works really well.

You can even add a thumbnail that shows before the video starts downloading/playing (the poster attribute). :-)

[Aurornis]

> still work the same way they did in the 90s: Right click the video and download it, it's a media element like any other.

I’m so confused reading these comments. Did everyone forget RealPlayer? Flash videos? All of the other nonsense we had to deal with to watch video on the internet?

[LaGrange]

RealPlayer was 1995, so a few years later, and arguably was a start of the trend of enshittification. Flash videos was around the times things really got bad.

That does mean we go, essentially:

Step 1: We barely have video at all.

Step 2: Everything is terrible.

[nurettin]

Technically, you can profit off of ad revenue and subscriptions without exploiting the labour of your workers, so in this particular case it has nothing to do with the economic regime. Enshittification is its own thing.

[noirscape]

The problem with a standard video element is that while it's mostly nice for the user, it tends to be pretty bad for the server operator. There's a ton of problems with browser video, beginning pretty much entirely with "what's the codec you're using". It sounds easy, but the unfortunate reality is that there's a billion different video codecs (and a heavy use of Hyrum's law/spec abuse on the codecs) and a browser only supports a tiny subset of them. Hosting video already at a basis requires transcoding the video to a different storage format; unlike a normal video file you can't just feed it to VLC and get playback, you're dealing with the terrible browser ecosystem.

Then once you've found a codec, the other problem immediately rears its head: video compression is pretty bad if you want to use a widely supported codec, even if for no other reason than the fact that people use non-mainstream browsers that can be years out of date. So you are now dealing with massive amounts of storage space and bandwidth that are effectively being eaten up by duplicated files, and that isn't cheap either. To give an estimate, under most VPS providers that aren't hyperscalers, a plain text document can be served to a couple million users without having to think about your bandwidth fees. Images are bigger, but not by enough to worry about it. 20 minutes of 1080p video is about 500mb under a well made codec that doesn't mangle the video beyond belief. That video is going to reach at most 40000 people before you burn through 20 terabytes of bandwidth (the Hetzner default amount) and in reality, probably less because some people might rewatch the thing. Hosting video is the point where your bandwidth bill will overtake your storage bill.

And that's before we get into other expected niceties like scrolling through a video while it's playing. Modern video players (the "JS nonsense" ones) can both buffer a video and jump to any point in the video, even if it's outside the buffer. That's not a guarantee with the HTML video element; your browser is probably just going to keep quietly downloading the file while you're watching it (eating into server operator cost) and scrolling ahead in the video will just freeze the output until it's done downloading up until that point.

It's easy to claim hosting video is simple, when in practice it's probably the single worst thing on the internet (well that and running your own mailserver, but that's not only because of technical difficulties). Part of YouTube being bad is just hyper capitalism, sure, but the more complicated techniques like HLS/DASH pretty much entirely exist because hosting video is so expensive and "preventing your bandwidth bill from exploding" is really important. That's also why there's no real competition to YouTube; the metrics of hosting video only make sense if you have a Google amount of money and datacenters to throw at the problem, or don't care about your finances in the first place.

[jsmith45]

Chrome desktop has just landed enabled by default native HLS support for the video element within the last month. (There may be a few issues still to be worked out, and I don't know what the rollout status is, but certainly by year end it will just work). Presumably most downstream chromium derivatives will pick this support up soon.

My understanding is that Chrome for Android has supported it for some time by way of delegating to android's native media support which included HLS.

Desktop and mobile Safari has had it enabled for a long time, and thus so has Chrome for iOS.

So this should eventually help things.

[9cb14c1ec0]

Any serious video distribution system would not use metered bandwidth. You're not using a VPS provider. You are colocating some servers in a datacenter and buying an unmetered 10 gigabit or 100 gigabit IP transit service.