Video Renditions Explained: CMAF, HLS/DASH & Social Formats
Learn what video renditions are, how CMAF serves HLS and DASH from one encode, and how social-ready MP4 exports reach every screen and every destination.
A video rendition is a specific output of a video—a particular resolution, bitrate, container, or aspect ratio—derived from one master render so the same content fits every destination it will meet. Modern delivery never ships one file: it ships a set of renditions, from an adaptive streaming ladder for embedded playback to ready-to-publish MP4s for social platforms.
Renditions are where our rendering pipeline hands off to the real world. Every video Videospan renders is delivered two ways at once: CMAF-packaged segments served as both HLS and DASH streams for adaptive playback anywhere, and downloadable 1080p 30fps MP4 exports in the aspect ratios each social platform demands.
How video renditions work
Producing renditions is a "render once, package many" discipline built from three parts:
- Start from one master. The render pipeline produces a high-quality master from the composition. Every rendition—streaming or download—derives from this master, so all outputs are guaranteed to show the same edit.
- Build a bitrate ladder for adaptive streaming. The master is encoded at several resolution/bitrate pairs—say 360p through 1080p—so players can step up or down as network conditions change. This is adaptive bitrate streaming, and each rung of the ladder is itself a rendition:
- Package once, serve both protocols. With CMAF, the ladder is segmented into fragmented MP4 chunks that both HLS (
.m3u8playlists) and DASH (MPD manifests) can reference. One set of segments, one CDN cache, two protocols—Apple devices play HLS natively, everything else plays whichever it prefers. - Export platform-native downloads. Social platforms don't want streams; they want files. The master is rendered into ready-to-publish MP4s: H.264 video with AAC audio at 1080p and 30fps, in 16:9 for YouTube and LinkedIn, 9:16 for Reels, TikTok, and Shorts, and 1:1 or 4:5 for feed posts.
The key economy: encoding work happens once per rendition, and CMAF means the adaptive ladder is packaged once rather than twice. One master, many outputs, no redundant encode passes.
How Videospan uses renditions
Renditions are the reason "publish" in our platform is a decision, not a project:
- Aspect-ratio variants come from the composition, not a re-edit. Because the edit is data, rendering a 9:16 cut of a 16:9 recording re-evaluates the same composition with different layout parameters. Repurposing long-form into clips inherits this for free.
- Adaptive delivery by default. Every video we publish ships as CMAF-packaged segments referenced by both HLS and DASH manifests, so a viewer on an iPhone, a Windows laptop, or a conference-room display gets the best rendition their connection supports—see HLS and the streaming protocols overview.
- Social exports that are actually ready. The downloadable MP4s match what platforms expect—1080p, 30fps, H.264 + AAC, correct aspect ratio—so a marketer publishes the file as-is instead of transcoding it in yet another tool.
- Parallel rendering across variants. Renditions render as independent jobs across our cloud GPU infrastructure, so producing five outputs of one edit doesn't take five times as long as producing one.
Multi-rendition delivery vs single export
| Rendition-based delivery | One-size-fits-all export | |
|---|---|---|
| Outputs per edit | A ladder plus platform-specific files | One file |
| Streaming playback | Adaptive—CMAF served as HLS and DASH | Fixed quality; buffers on weak networks |
| Packaging cost | One segment set for both protocols | Separate encodes per protocol, or none |
| Social publishing | Ready-to-publish MP4s per platform | Manual resizing and transcoding |
| Aspect ratios | 16:9, 9:16, 1:1, 4:5 from one edit | One shape; re-edit for others |
| Viewer experience | Best quality their device and network allow | Compromise chosen once by the publisher |
| Render economics | Parallel jobs, one master | Serial re-exports for every new need |
Advantages
- One master, every destination. Streaming ladder and social downloads all derive from the same render, so nothing drifts out of sync between versions of "the same" video.
- CMAF halves the packaging work. One set of fMP4 segments serves both HLS and DASH audiences and caches once on the CDN.
- Adaptive by default. Viewers on poor connections get a lower rung instead of a buffering wheel; viewers on good connections get full quality.
- Social files need no further tooling. Exports match platform specs—codec, resolution, frame rate, aspect ratio—so they're publishable as downloaded.
- Re-rendering is cheap when the edit is data. Need a new aspect ratio next quarter? It's a new rendition of the existing composition, not a new edit.
Limitations
- Storage multiplies. Every rung and every variant is another set of segments or files to store and manage, even when encodes are shared.
- The ladder is a compromise set. Rung choices (resolutions, bitrates) balance quality against bandwidth and cost; no finite ladder is optimal for every viewer.
- Codec reach is a trade-off. H.264 + AAC plays everywhere but isn't the most efficient codec; more efficient codecs would mean additional rendition sets.
- Downloads bypass adaptivity. A social MP4 is a fixed file—viewers on that platform get whatever the platform re-encodes it into, which is outside anyone's control.
When to use multi-rendition delivery
Use rendition-based delivery whenever the same video must live in more than one place—which is nearly always for organizational video. An executive announcement needs adaptive streaming on the intranet, a 16:9 MP4 for LinkedIn, and a 9:16 cut for mobile-first channels; producing those as renditions of one master is the difference between publishing and re-editing. The only case for a single export is a genuinely single destination, and destinations have a way of multiplying.
If you're evaluating a video platform, ask the vendor what "export" actually produces. Do you get an adaptive stream—CMAF segments served as both HLS and DASH—or a single file? Are social exports rendered in the correct aspect ratios and specs, or is that left to you? Can a new aspect ratio be rendered from the existing edit without re-editing? And do multiple variants render in parallel, or does each output queue behind the last? The answers separate a delivery pipeline from a download button.
Glossary
- Rendition
A specific output of a video at a given resolution, bitrate, format, or aspect ratio, derived from a shared master render.
- Bitrate ladder— Adaptive bitrate ladder
The ordered set of resolution/bitrate renditions a player can switch between as network conditions change.
- CMAF— Common Media Application Format
A standardized fMP4 segment format that lets one set of segments be served as both HLS and DASH, sharing one encode and one CDN cache.
- HLS— HTTP Live Streaming
Apple's adaptive streaming protocol using .m3u8 playlists; native on Apple devices and supported everywhere via player libraries.
- DASH— Dynamic Adaptive Streaming over HTTP
The ISO-standard adaptive streaming protocol using XML MPD manifests, dominant on Android, smart TVs, and the open web.
- fMP4— Fragmented MP4
An MP4 variant split into fragments, forming the segment format that makes CMAF sharing between HLS and DASH possible.
- ABR— Adaptive bitrate streaming
Delivery technique where the player continuously picks the best rendition of a stream for current device and network conditions.
- Master— Master render / mezzanine
The high-quality output of the render pipeline from which all delivery renditions are derived.
- Aspect ratio— Delivery aspect ratio
The width-to-height shape of a rendition: 16:9 for YouTube and LinkedIn, 9:16 for Reels/TikTok/Shorts, 1:1 and 4:5 for feeds.
- Transcoding— Transcoding / re-encoding
Converting a master into another codec, bitrate, resolution, or container— the process that produces each rendition.