Hacker News Reader

Comment by achairapart | Hacker News Reader

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.

View on HN

Then the <video> element is not to blame but browsers’ handling of video playback/caching.

Playback and caching is part of the implementation of the <video> element.

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.

On the other hand, in a typical Netflix binging scenario, this would cause tens of gigabytes of avoidable SSD writes.

Especially for mobile devices with fairly small storage sizes, this can easily represent a sizable fraction of their total write endurance.

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.

> unless that is done with JS.

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.

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.

https://www.avvo.com/legal-guides/ugc/copyright-101-is-strea...

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.

Sadly the threshold is something around >5Mb, if I remember correctly.

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.

Reply on news.ycombinator.com