Search code examples
audiostreaminghtml5-audiohttp-live-streamingopus

Building adaptive audio streaming for web and mobile web

I am building a site where I'd like to stream audio files from a S3/CDN. Like with video, I'd like the stream to adapt to the bandwidth of the users. It seems like I have the following options -

  1. Encode to, say 128kbps and 320kbps audio, and switch based on bandwidth? This has the additional complexity of determing the bandwidth.

  2. Encode to HLS/DASH as an audio-only stream. I am not sure what the equivalent bitrates in that format will be? For video, there is a lot of information online but not sure what is the equivalent of being able to stream - 1080p, 720p, 480p, 320p (my video encoding presets).

  3. Use something like OPUS but it doesn't seem to be supported by any of the mobile browsers?

I am reluctant to have any server-side software and use CDNs which already support HLS/DASH.

Given all of that, I am wondering which of those ways are actually valid, and recommended?

Solution

  • Encode to, say 128kbps and 320kbps audio, and switch based on bandwidth?

    Sure, but if someone can play 128kbps, they can probably play 320kbps just fine as well. At least in the US, there are mobile devices that can do around 64kbps reliably. Much above that, they usually are connected to LTE or similar technologies, with reliable backhaul, and can transfer at the higher speeds. I would have a 64kbps stream, and a 192kbps stream, if you're talking about AAC. If MP3, go to 320kbps on the high end. (You can always have more steps in between, but it's more cost for you, and generally not worth it. As with anything though, keep an eye on your own analytics and adjust as needed for your own audience. There is no one-size-fits-all setup.)

    Encode to HLS/DASH as an audio-only stream. I am not sure what the equivalent bitrates in that format will be?

    HLS and DASH aren't codecs, they are transport protocols. Your bitrates should be the same regardless of what transport protocol you choose.

    For video, there is a lot of information online but not sure what is the equivalent of being able to stream - 1080p, 720p, 480p, 320p (my video encoding presets).

    There is no equivalent... you're talking about audio, which has nothing to do with video. And, your stream resolution is only loosely correlated to its bitrate anyway.

    Use something like OPUS but it doesn't seem to be supported by any of the mobile browsers?

    It's likely you're going to need to use multiple codecs for the broadest browser support anyway. But, this doesn't have anything to do with the bandwidth used, nor the transport protocol you're using.

    For audio codecs, Opus is on par with AAC at higher bitrates, better at lower bitrates, has broad bandwidth flexibility (as it's actually a couple codecs combined into a suite), and has fewer licensing concerns. AAC is better than MP3. HE-AAC (aacPlus) is better than AAC at lower bitrates but doesn't have the best device/software support. MP3 does okay but has by far the best client support... everything can play MP3 and it's self-synchronizing... requires no container. (Opus and AAC require some sort of container for streaming... this is easier in AAC which can be used with ADTS for this purpose.)

    I am reluctant to have any server-side software and use CDNs which already support HLS/DASH.

    You don't even need HLS/DASH, particularly if your content is pre-recorded. (Nothing stopping you from using them of course, but there's little point to the added overhead.) By all means though, you're right that it's best to use an existing CDN. The whole point of HLS and DASH is that you can re-use all this HTTP CDN infrastructure out there... for live streaming.

    For audio only though, I would just serve the regular audio files and be done with it! Much simpler to work with, and you can always go with dynamically generated DASH manifests later if you find that you need them for auto scaling of bandwidth usage.