7 ms·
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 laye
by jsheard 1y 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).
- jsmith45 1y agoChrome has finally just landed enabled by default native HLS playback support within the past month. See http://crrev.com/c/7047405 http://crrev.com/c/7047405 I'm not sure what the rollout status actually is at the moment.
- jsheard 1y ago> 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.
- kccqzy 1y agoI 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.
- deleted 1y ago[deleted]
- deleted 1y ago[deleted]