HLS video podcast hosting support in RSS

The Podcast Standards Project has published a current list of hosting platforms and listening apps that support HLS video in podcast RSS. Its August 11 update says the path uses the podcast:alternateEnclosure tag: the normal audio enclosure remains available, while a compatible app can offer an HLS video version from the same feed.
For a video podcaster, that is a meaningful distribution change. You can publish episode media through one RSS feed rather than maintain a separate manual upload path for every supported podcast app. It is not a reason to merge every video and audio metric into one dashboard number.
What support exists now
The Podcast Standards Project lists Transistor, RSS.com, Fountain, True Fans, Captivate, Flightcast, Podigee, Beamly, Podbean, and Omny Studio as hosts publishing HLS video through podcast:alternateEnclosure as of August 2026. It lists Blubrry, Buzzsprout, and Spreaker as committed to ship support.
The current app list includes Pocket Casts, Amazon Music with limited support, iHeart with limited support, Fountain, True Fans, Podcast Guru, and Podcast Addict. The post also says Apple Podcasts uses HLS for video in its own app but does not consume HLS video from RSS, instead requiring its proprietary API for submitted HLS video episodes.
These lists can change, so check the Podcast Standards Project's update before choosing a host or promising an audience where the video will appear.
What alternateEnclosure changes
HLS, or HTTP Live Streaming, uses a manifest that points a player to media segments instead of one large video file. The Podcast Standards Project describes podcast:alternateEnclosure as a podcast namespace tag for offering additional media versions alongside the standard enclosure.
That lets an audio-only app continue using the audio version while a compatible app can choose video. The open-feed benefit is real: RSS remains the source of publishing metadata and episode availability instead of becoming an afterthought beside a platform-specific upload.
Keep the measurement boundary clear
A streamed video play inside an app is not necessarily the same event as an RSS media-file request. The provider, app, playback method, and reporting definition all matter. Do not add video app plays to RSS downloads and call the result a single audience total unless you can explain the unit and deduplication method.
The IAB Tech Lab's Podcast Measurement Technical Guidelines remain the primary reference for filtered podcast download measurement. Start with separate columns for RSS delivery and each video platform's native playback reporting, then describe each number by its source.
What counts as a podcast download covers the delivery side of that distinction. For the broader reporting workflow, see podcast analytics guide. Podcast listener retention helps keep platform playback behavior separate from cross-app delivery.
One important implementation boundary for Podder users: this HLS support list is not a Podder prefix-support list. Do not infer analytics-prefix compatibility from a host appearing in the standards update. Confirm your host's prefix options separately before changing a feed.
Questions to ask before enabling video
Ask the host whether it creates the HLS rendition, how it exposes the alternate enclosure in the feed, and which apps it has tested. Ask whether existing audio-only subscribers receive the normal enclosure without an unexpected change. Then publish one test episode and inspect the feed and the supported apps you care about before making a season-wide promise.
Also establish where each report comes from. Hosting delivery, app video playback, retention, and audience estimates may live in different systems. Keep the export dates and definitions with your report so a later comparison does not turn a format change into a false growth story.
One feed reduces publishing work. It does not eliminate platform differences, distribution checks, or the need to explain what each measurement actually represents.
The practical next step
If video is part of your publishing plan, start with one episode that works as audio on its own. Confirm the normal enclosure remains usable, then check the HLS version in each supported app that matters to your listeners. Document what appears, how quickly it appears, and where each app exposes its reports.
Do not redesign the show's reporting around a host capability alone. The useful test is whether your actual audience can receive the format and whether you can explain the resulting metrics to a sponsor or collaborator. If either answer is unclear, keep the current workflow while the support path matures.
See who's actually listening.
Podder gives you audience demographics, per-episode analytics, and chart tracking. The Chartable alternative that goes deeper.
Start free