Actually, You Should Probably Use HLS or MPEG-DASH

If the videos you’re serving are long or frequently accessed, you should use one of the Adaptive Bitrate formats, either HLS or MPEG-DASH to serve it.

In fact, on iOS, you have to serve video over ten minutes using HLS.

What are HLS and Dash?

They’re streaming formats that break up a video into small chunks, each a few seconds long, on the server, and serve a plaintext file playlist, called a manifest, to the browser. The browser then downloads one chunk at a time. This is how live video works over HTTP.

So why use it for VOD (non-live) video?

These formats can support multiple nitrates at a time, so you can serve different quality videos to different users, depending on their bandwidth.

For instance, you might serve HD quality to a user with a great connection, a dvd quality stream to a person with a so-so connection, and a vhs quality stream to someone with a really poor connection. The HLS spec demands you serve at least one audio-only stream too.

But the browser can switch between these streams dynamically. You see this all the time on YouTube or netflix...the picture looks great, then all of a sudden it’s crummy, then it returns to its original greatness. The video is being served in a streaming format, and the connection between your device and the video server just dipped. Rather than pushing the video and buffering, the player switched to the lower bandwidth version.

The principal is play at all costs, even if quality is worse. The idea is that a low quality video is better than a video that constantly breaks to buffer.

How long does your video have to be before you use HLS or MPEG-DASH? Well, Apple requires it at ten minutes, but I usually switch to it after 1 minute.

This is much less important for audio, but still useful for live audio. This is the only way to serve live video.

Should you use HLS or Dash? Dash used to have some technical advantages, but those were pretty much matched by the last three versions of Safari, and HLS is the only one supported on iOS, so probably HLS is the right choice. If you’re streaming a very frequently accessed video, it may be worth serving both. But encoding these formats is quite resource intensive, and you need to consider that tradeoff.

Again, this is a series of tradeoffs, and you should hire an expert to help you determine what you serve.

Safari and Edge support HLS natively, but Chrome and Firefox require a JS plugin to serve either format.

Current Elm Difficulty = Pretty Hard

Easy to implement in a browser that supports it natively, but if you need to support Chrome or Firefox or Linux (and you do), you need to use a javascript plugin to decode it. The plugins don’t play well (ergonomically) with ports.

It’s doable through a web component, but it’s really hacky, and I’d be very careful about using in production.

Honestly, this is part of Elm media support that really depresses me. This is a best practice, mandatory in some cases, and Elm currently makes it much harder than it needs to be.