Responsive Video

The question started simple: why can’t a video rotate with my phone?

Every other layer of the modern web is responsive. Text reflows. Images swap sources. Layouts recompose themselves for whatever screen they land on. Video, the most expensive and most engaging asset on any page, is the one thing still shipped as a take-it-or-leave-it rectangle. You get 9:16 or you get 16:9. Rotate your phone and the player just letterboxes the mistake.

That’s not a technical inevitability. It’s an inherited assumption.

01Why video is stuck

A video file is a baked artifact. Every decision gets made once at render time and sealed forever: framing, aspect ratio, pacing, what’s in the safe zone. For a hundred years that was the only option, because rendering was expensive and playback devices were dumb.

Neither of those things is true anymore. Phones carry serious GPUs. Rendering pipelines are programmatic. The bakedness of video is now a choice we keep making out of habit.

02The concept

Responsive video doesn’t require re-rendering anything on the fly. It requires two renders and one honest player.

The render side. One composition, exported twice in a single pass, 9:16 and 16:9, with hard guarantees between the pair:

1. Identical duration and scene boundaries in both files
2. The same audio stream, bit for bit
3. Matching frame rate and keyframe intervals, so a seek lands cleanly in either file
4. Consistent color and encode settings

Alongside the two files, a small JSON manifest: durations, resolutions, file paths. That manifest is the contract.

The player side. A lightweight web player loads the manifest, listens for orientation change, swaps the video source, and seeks to the previous currentTime. With the sync guarantees above, the swap doesn’t read as “loading a different video.” It reads as the video morphing between aspects, because to the viewer it’s the same moment of the same piece, reframed.

Vertical for the feed. Widescreen for the embed. One production. The viewer’s device decides.

03Where the layout logic lives

The interesting design problem isn’t the player. It’s how a composition defines itself for two frames at once. Two workable answers:

• Explicit dual layout: the composition declares element positions per aspect ratio, the way a responsive website declares breakpoints.
• Focal-point hints: each scene carries a safe-zone or subject marker, and the renderer auto-reframes around it.

The first gives control, the second gives speed. A real pipeline probably wants both: hints as the default, explicit overrides where the auto-reframe gets it wrong. (Toggle the safe zone in the illustration above to see the region a focal hint would protect.)

04The pitch

I proposed this to the HyperFrames team as a feature: dual-aspect export as a first-class render mode. Their architecture is a natural fit. AI-heavy rendered footage is exactly the material that can’t be handled by client-side re-rendering approaches, which fall apart the moment the composition is real video instead of code-drawn layers. Baked, frame-synced pairs deliver the responsive experience with zero runtime cost on the viewer’s device.

They were interested. The spec above is essentially the ticket.

05The bigger picture

Dual-aspect export is deliberately the smallest version of a much larger idea: stop shipping decisions, start shipping options.

Once a video is “files plus a manifest plus a player” instead of one sealed file, the aspect ratio is just the first thing that gets unlocked. The same architecture carries live data layers, per-viewer content, updates over time. The file stops being the product. The manifest becomes the product.

That thread continues in LOG 014, Data-Bound Video, where the manifest starts binding regions of the video to live APIs.

Status: spec proposed upstream. Player prototype next on the bench.