Better podcast delivery through HLS – key questions answered!

We’re heading into Podcast Movement and, as always, there will (rightly) be a lot of chatter about how this never dull space continues to create better listener experiences and keep podcasting on its amazing growth trajectory. For hosting companies and other platforms to support this growth, they’re embracing a range of innovations (a lot of which are foundational to Podcasting 2.0) to help. That tech of course helps them too – reducing cost and more.

HTTP Live Streaming (HLS) is a key part of this. But there’s a lot to digest and understand before jumping in. 

We created this Q&A to help. Dig in below, and come talk to us about it at the show. I’ll be talking about this and a lot more with Adam Curry at the show on Tuesday the 19th at 9:45am (Industry Expert Talks stage).

FAQ:

How are most podcasts delivered now?

Most podcasts are delivered through a method called progressive download, in which a listener's app or web browser requests a single MP3 file from a server. The file begins to download, and as soon as enough of the file is buffered, playback begins.

Sure, progressive download is a simple and widely-supported method – but it has limitations. 

For example, if you’re listening on a weak or spotty Internet connection, the audio might buffer and stutter because you’re unable to download the file fast enough to keep up with playback.  And for listeners on high-speed connections, quality can suffer too, as the audio or video file might be a lower bitrate (quality) than you are able to reliably receive.  

Another limitation of progressive download is that while some players are more resilient than others, listeners on the go might experience issues as their mobile devices move from cell phone tower to cell phone tower.

How does HLS make it better?

HTTP Live Streaming (HLS) is a more advanced streaming protocol that was developed by Apple and is now an industry standard. Instead of a single large file, HLS breaks up a podcast into many small media chunks, typically 2-10 seconds in length (and can also be created at multiple bitrates, e.g., 128kbps, 96kbps, 64kbps, 32kbps).

A player that supports HLS uses a manifest file (the m3u8 file) to request these chunks. As a listener's network speed changes, the player can also dynamically switch to a higher or lower bitrate version of the chunks without interrupting playback. Adaptive bitrate streaming (ABR) is nascent in podcasting but will help improve delivery even more, offering a seamless and higher-quality listening experience for every user, regardless of their connection speed or device.

Wait, what the heck is a m3u8 manifest file?

The m3u8 manifest file is the core of HLS delivery and foundational to ABR. HLS actually uses two types of manifest files working together:

• The master playlist (or multivariant playlist) is the entry point that lists all available quality options for the content -- for example, different audio bitrates. When a player first requests HLS content, it downloads this master playlist to understand what quality options are available.
• Each quality option then has its own media playlist - a simple text file that acts like a detailed playlist, listing the URLs for all the individual media segments (typically .ts files containing 2-10 seconds of content each) for that specific bitrate. The player uses these media playlists to know exactly which segments to download in sequence.

This two-tier system allows the player to seamlessly switch between different quality levels during playback. When network conditions change, the player can request segments from a different bitrate's media playlist without interrupting the listening experience -- that's the adaptive bitrate streaming (ABR) magic in action.

Does HLS audio delivery cost more than MP3?

HLS audio delivery may seem more expensive at first due to the extra processing required for chunking and creating multiple bitrate versions. But the benefits typically outweigh the initial cost. HLS offers a better listener experience with adaptive bitrate streaming, which reduces buffering and improves reliability on mobile devices. It also provides more detailed analytics and dynamic ad insertion capabilities, which can lead to increased revenue and a more valuable service overall.

Can you be more specific?

Bandwidth usage and price depend on the bitrate and the number of listeners. A simple calculation for a one-hour stream is to multiply the bitrate (in bits per second) by the number of concurrent listeners and the duration of the content. For example, a 96 kbps audio stream for 1,000 listeners over one hour consumes approximately 43.2 gigabytes of data:

(96kbps×1000 listeners×3600 seconds)/(8 bits/byte×10243 bytes/gigabyte) = 43.2GB

This calculation helps estimate the total data transfer – the primary factor in pricing. Most providers (including SoundStack) base costs on total data delivered – a better method than models like “95th percentile” billing, which charges for the highest sustained traffic rate, ignoring the top 5% of usage spikes. This can be especially problematic for podcasts where a new episode's release can cause a massive traffic spike in the first 4-8 hours. These bursts can easily hit and exceed the capped rates, leading to brutal overage charges.

The cost to chunk an MP3 file into HLS is typically included in the overall service fee of a CDN. It involves an encoding process that transcodes the source file into different bitrate segments. While this requires a processing cost on the backend, many managed services include it in the hosting price rather than charging a separate fee for each chunking operation.

Is the computation different for on-demand content?

Bandwidth computation for HLS live and on-demand streaming should be the same. The principle remains constant: it's calculated based on the total data transferred to all listeners. The primary difference is the delivery mechanism. Live streaming uses a continuously updated playlist to deliver new chunks as they are created, generally only providing the player with 30 seconds or so of content at a time.  On-demand, on the other hand, can use a static playlist of pre-existing chunks. The cost is still directly tied to the total amount of data delivered to the end user.

What’s the main benefit of HLS over MP4 for video delivery?

In an acronym, ABR! As HLS breaks the video into small chunks and provides multiple quality options, the player can automatically switch to a lower quality if a user's internet connection slows down, preventing buffering and ensuring a smooth viewing experience. A single MP4 file, by contrast, must be downloaded in its entirety and at a fixed quality, which can cause significant buffering on poor connections. Remember, charges should be based on consumption – if lower quality is needed based on a user’s internet connection, the amount of GB actually used would be lower, lowering your total cost.

What is the bandwidth usage and price for a one-hour HLS streamed video podcast at various bitrates?

For HLS video podcast delivery, bandwidth usage and pricing are directly related to the video bitrate, audio bitrate, and the number of concurrent viewers. Unlike audio-only streams, video requires significantly higher bitrates to maintain a clear picture. For example, a 1080p video stream may have a video bitrate between 3,000 and 6,000 kbps, plus an audio bitrate of around 128 kbps.

The calculation remains the same: multiply the total bitrate (video + audio) by the number of concurrent viewers and the duration of the content. Let's use a 1080p stream as an example: a 4500 kbps total bitrate (4372 kbps video + 128 kbps audio) for 1,000 viewers over one hour:

(4500 kbps×1000 viewers×3600 seconds)/(8 bits/byte×10243 bytes/gigabyte) = 2025 GB

This highlights how much more data video consumes than audio. But again, ABR can help here too, providing  flexibility that makes HLS a more cost-effective and reliable solution than a single, high-bitrate video file. Like audio, most providers base their pricing on total data delivered (which again is much more predictable than the 95th percentile billing model).

How does storage work, and is it charged differently than delivery?

Yes, storage is sometimes billed separately from delivery depending on your hosting provider. HLS content is broken into small, individual segments (chunks) that are stored on a server. The storage cost is typically based on the total duration or volume of the stored media. This is different from the delivery cost, which is based on the total data transferred to listeners. A key benefit of HLS is that its chunks can be efficiently cached on the CDN layer, which optimizes storage and improves playback efficiency.

Does deploying dynamic ad insertion (DAI) make a difference?

DAI is a game-changer for podcast monetization. Hosting companies (including SoundStack) have been providing DAI solutions for years in various types of streaming media.  While the HLS delivery methodology is different from traditional content delivery (especially for podcasting) and presents a different set of challenges, extremely high quality server-side dynamic ad insertion (SSAI/DAI) is still possible and is available today.

How does podcast measurement work using downloads and HLS streaming?

The IAB Podcast Measurement Guidelines and Compliance Program are central to ensuring accurate and consistent measurement within the podcast industry. While these guidelines primarily focus on measuring podcasts delivered via downloads and the subsequent analysis of server logs, the growth of live podcast consumption, video, and HLS as a distribution method for podcasting presents both opportunities and challenges for adhering to these standards.

The good news is that while different, HLS is easily measured.

Similar to progressive download, we can treat each HLS chunk delivered as a byte-range request.  We can glue all of those byte range requests together to get a complete picture of exactly how much content was delivered, and exactly which pieces of the content each individual audience member received.  And, with a little extra effort within sophisticated content delivery networks, this even works perfectly in cases where pieces of the content might be dynamically generated.  This means we can still adhere to the IAB’s standards for counting ad impressions, even in the case of server-side dynamic ad insertion.

In summary, the podcast industry is seeing a dramatic transformation in the way that the audience consumes content.  A shift to more live content, video, streaming, and a future with HLS as a standard delivery protocol, means the IAB’s guidelines will have to evolve to accommodate the trend and keep reporting accurate and consistent.