A podcast is no longer defined by whether its audience presses play with a screen in front of them. The same episode may be watched at a desk, heard on a commute, resumed on a television, and finished with a phone locked in a pocket. Video has become part of podcasting, but listening remains fundamental.
Today we are announcing video podcasts for UFW Podcasts. The goal is not to bolt a large video file onto an audio feed. We are building one release workflow that can prepare a video for adaptive playback, preserve an audio-first experience, and deliver the right form of the episode to each destination.
Video support is in development. This article describes the product direction and the technical foundation we are building toward.
One episode, more than one way to experience it#
Video changes what a podcast can communicate. A conversation gains expression and body language. A technical show can put the diagram, demonstration, or line of code beside the discussion. A documentary can preserve the scene rather than describe around it.
It also changes the production burden. Recording is only the first step. A useful video release needs a dependable upload, audio extraction, multiple video qualities, captions, artwork, distribution-specific metadata, and delivery that can adapt to the viewer’s connection. Treating those as unrelated exports leaves producers repeating work and makes each platform another place for a release to drift out of sync.
UFW Podcasts will treat the episode as the durable object. Its title, description, season, publication time, artwork, source media, and destination state belong together. Audio and video are representations of that episode, not separate editorial records.
That distinction matters when a producer corrects a title five minutes before publication or replaces a master after noticing an audio problem. There should be one place to make the decision and a clear record of what each destination received.
Distribution is not uniform#
“Publish everywhere” sounds simple because it hides the differences between platforms. Video podcast distribution currently follows more than one model.
Apple Podcasts’ current guidance describes an HLS workflow through supported hosting providers. A creator authorizes the host with an Apple Podcasts Connect API key. The host delivers multiple quality variants, while the show’s existing RSS feed continues to control titles, descriptions, and other metadata. On supported Apple Podcasts experiences, audio and video then live on one show page and a listener can move between them without losing position.
Apple also continues to support video delivered through a standard RSS feed, including MOV, MP4, and M4V enclosures. Apple recommends a new or dedicated feed for that older model when an audio version already exists. HLS is the more interesting path for an integrated show because it is designed for streaming rather than asking every device to retrieve one fixed file.
Spotify follows a different route. A video uploaded through Spotify for Creators or Megaphone is streamed natively on Spotify. According to Spotify’s description of video distribution, other listening platforms receive the audio version through RSS. An externally hosted show can add video to an existing Spotify episode, but that video remains available in Spotify’s own applications and web player.
This is why UFW will use destination adapters rather than pretend every directory consumes the same artifact. One release can produce:
- adaptive video for destinations that accept a streaming delivery;
- a destination-native video upload where the platform requires it;
- a conventional audio enclosure for the open podcast feed;
- separate captions and the metadata expected by each destination.
The producer should see one episode and a delivery status for every destination. The differences belong in the system, not in a checklist beside the editor.
From master file to adaptive stream#
A video master is not a stream. It may be too large for a mobile connection, encoded in a format an older device cannot decode, or recorded with a variable frame rate that slowly pushes audio and video out of sync. The first stage of the UFW pipeline is therefore inspection rather than conversion.
We record the source container, duration, dimensions, frame rate, color information, audio layout, and available caption tracks. The resulting inspection record determines the encoding plan and makes a later re-encode reproducible. Unsupported or damaged media should fail at ingest with a useful explanation, not forty minutes into an opaque processing job.
The planner then builds an adaptive bitrate ladder without inventing detail above the source resolution. Its lowest rendition must remain useful on a constrained connection; adjacent renditions must differ enough to justify their storage and encoding cost. Every rendition shares aligned keyframes so a player can change quality at a segment boundary without a visible jump.
The initial compatibility path uses H.264, with modern codecs added where the destination and device support justify the extra encoding work. Audio is processed independently of the video ladder. It can be paired with any video rendition, delivered on its own, and normalized for a consistent listening experience. Caption tracks remain separate so viewers can select a language, restyle the text, and use assistive technology. We will not burn accessibility into the pixels.
Processing is a graph of small, attributable jobs:
inspect → plan → [video renditions ∥ audio ∥ captions] → package → publishIf one rendition fails, the pipeline retries that work without encoding every successful rendition again. Each task is idempotent and records its progress. “Processing failed” is not an operational answer; the system should be able to identify the exact rendition or packaging step that needs attention.
One set of segments, two streaming formats#
Adaptive playback divides each rendition into short media segments. The player reads a small manifest, estimates the available bandwidth and buffer health, then requests the appropriate quality one segment at a time. A viewer on a changing mobile connection gets continuous playback instead of a single high-quality file that repeatedly stalls.
UFW will package compatible renditions as CMAF segments that can be described by both HLS and MPEG-DASH:
video renditions → CMAF segments → HLS manifest
→ MPEG-DASH manifestThe manifests differ, but the large media objects do not need to be duplicated. That means one stored set of immutable segments can serve Apple-oriented HLS playback and DASH-capable players. It reduces storage, simplifies cache behavior, and avoids two packaging pipelines drifting apart.
Publication order is part of correctness. Every segment and child manifest must exist before the master manifest becomes visible. Publishing the master first creates a stream that appears ready but fails as soon as its player asks for a missing segment. UFW will publish the final manifest last, making availability an atomic state rather than an optimistic label.
Immutable segments are also well suited to edge caching. The heavy bytes can keep long cache lifetimes, while the much smaller manifest controls what a player sees. Signed delivery can authorize an asset without placing a database lookup in front of every segment request.
Audio remains first-class#
Adding a camera should not make a podcast worse for listeners. Many people encounter a show while driving, exercising, or using a device with the screen off. Apple notes that followed video shows automatically download audio by default, while viewers may separately opt into video downloads. Spotify similarly lets an audience move between watching and listening.
UFW’s audio output will therefore be a deliberate product of the release, not an accidental track stripped from a video container at the last moment. Producers will be able to review the audio representation, and the open RSS feed will continue to carry a normal audio enclosure for destinations that do not accept the video path.
This also keeps the podcast portable. Platform-native video features can extend a show, but the show’s identity, catalog, and audio feed should not depend on one playback application.
Observability for the release, not only the file#
Video creates more states worth seeing: upload completeness, inspection results, rendition progress, caption availability, packaging, destination acceptance, and playback health. UFW Podcasts will expose those states as part of the episode rather than hide them behind a generic spinner.
After publication, the useful questions change. How long did playback take to start? Where did viewers rebuffer? Which rendition did their players select? Did people switch from video to audio? Did a destination reject an update while the others accepted it?
Platform analytics do not always separate the experience in the same way. Apple says audio and video consumption are grouped into the show’s overall metrics because people can move between the two. UFW’s observability layer will preserve destination-reported facts as they are, while adding delivery and playback measurements from infrastructure we operate. It will not manufacture precision that a platform does not provide.
Built for gradual production#
A video podcast does not require a television studio. Ausha’s practical guidance reaches the sensible conclusion: begin with the equipment available, establish a repeatable visual identity, learn how the audience consumes the show, and improve the production over time.
That is also how we are approaching the product. The first useful version is not the one with the longest codec list. It is the one that reliably accepts a real master, produces compatible audio and adaptive video, explains its work, and sends each destination what it can actually use.
Video Podcasts will join the same UFW Podcasts workspace used for shows, seasons, episodes, feeds, and observability. Producers will keep one release calendar and one source of metadata. The pipeline will handle the many representations underneath it.
The screen is becoming part of podcasting. The feed still matters. We are building for both.