3 ms·
So it's not that hard to do a good job of it, but it is work, and it's work with diminishing returns if you're not comfortable managing the lift. And once you g
by eropple 4y ago
So it's not that hard to do a good job of it, but it is work, and it's work with diminishing returns if you're not comfortable managing the lift. And once you get it working, it might require some experimentation here and there to get exactly what you want out of it. The HLS spec is readily available and ffmpeg can, given a video input, emit an HLS manifest with a set of renditions. (For research purposes, the magic words are probably "ffmpeg hls adaptive streaming". Also, tweaking those renditions is a rabbit hole. Bring lunch.) At that point you've just got video files and text-based manifests that can be uploaded somewhere, and you point a sufficiently smart video player at them.
For context, I work at Mux [ https://mux.com https://mux.com ] where SaaS video streaming is our bag; having previously built DIY solutions as mentioned above I think that Mux is probably the right choice for most folks who just want to ship a VOD or a live stream in a usable format--and you pay for it, you're the customer--but the tools are there if you want to take a swing at it.
- jeroenhd 4y agoWhen it comes to recorded lectures, even just HLS is probably overkill in my opinion. All modern browsers support video playback of simple H.264/VP9 files natively anyway. Stuff like HLS only tends to break the browser's native download button.
- eropple 4y agoAs with anything, it depends, right? Like, native video does have strong arguments for simplicity. It doesn't have strong arguments for usability. Do you want to seek? Do you want it to continue to work if a user's phone hits a rough patch of the internet? Nothing stops you from letting somebody download a static rendition too, though. (Not trying to shill too hard for Mux, but that comes out of the box.)