Comment by jsheard
8 hours ago
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).
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.
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.
> 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.