What Is Video on Demand (VOD) and How It Actually Works

This series has already covered every individual piece of how video-on-demand actually works, bitrate ladders, adaptive switching, M3U8 manifests, transcoding, without ever stopping to define what "VOD" actually means as a category or explain the one thing none of those pieces addressed: how scrubbing to a random point in a two-hour video works at all. This ties the pieces together and fills that gap.

TL;DR:

• VOD's defining trait isn't "not live," it's that the content gets fully processed once and served to potentially millions of separate playback sessions afterward, the opposite of live's real-time, one-shot constraint.
• The full VOD pipeline, encode into a bitrate ladder, package into segments and an M3U8 manifest, let ABR pick a rung per segment, has already been covered piece by piece elsewhere in this series; this article is the synthesis, not a re-derivation.
• Seeking to an arbitrary point in a VOD file only works cleanly at keyframes, self-contained frames a decoder can start from without any prior frame, a real technical constraint with a real tradeoff behind it.
• VOD's static, unchanging nature is what makes it cache and P2P-distribute so efficiently, the exact same bytes get requested repeatedly by different viewers, unlike live segments that exist for one narrow window.
• AIOZ Stream's own documentation describes its V1 release as covering "video-on-demand across both short-form and long-form formats," VOD specifically, not a live-streaming feature.

What actually makes something VOD

The useful definition of video-on-demand isn't "recorded instead of live," it's about when the processing work happens relative to when it gets watched. A VOD asset gets encoded, packaged into a bitrate ladder, and made available exactly once, and from that point forward, every viewer who requests it, whether that's ten people or ten million, pulls from that same already-finished output. Live content has the opposite shape: encoding happens in real time, under a hard latency constraint, for viewers who are all watching roughly the same moment simultaneously. That one distinction, process-once-play-many versus process-continuously-for-simultaneous-viewers, is what actually separates the two categories technically, not simply whether a red "LIVE" badge appears on the player.

The pipeline this series has already covered

Rather than re-derive it, here's the shape: a source file gets encoded into multiple resolution-and-bitrate combinations following a bitrate ladder, each rendition gets packaged into short segments described by an M3U8 manifest, and a player's ABR logic picks which rung to request per segment based on current conditions. That entire chain is what "VOD" means mechanically, and every step of it was covered in depth elsewhere in this series specifically because none of it is unique to VOD, live streaming uses the same ladder-and-manifest structure, just built and updated continuously instead of once.

How seeking and scrubbing actually work

This is the part none of the earlier pipeline articles addressed, and it's a real technical constraint, not an implementation detail. Video compression works by encoding most frames as predictions built from nearby frames rather than complete images, which is efficient for playback but makes most frames impossible to decode in isolation. Only certain frames, keyframes, also called I-frames, are self-contained: per AWS's own engineering writeup, "all of the information required to decode this type of frame comes from within itself," functioning essentially like a standalone JPEG. Keyframes are the only points a player can jump to cleanly, since starting playback mid-stream at any other frame would reference prior frames that were never requested. That's the actual mechanism behind a scrub bar snapping to a nearby point rather than the exact pixel a viewer dragged to, the player is finding the nearest keyframe, not being imprecise for no reason. The interval between keyframes, called a GOP (Group of Pictures), is a real tradeoff: AWS's own comparison found a 4-frame GOP producing visibly blockier, blurrier output than a 90-frame GOP at the identical bitrate, better compression efficiency, but at the direct cost of having far fewer clean seek points available in the same stream.

There's a second, easy-to-miss constraint tied to GOP structure that connects directly back to the ABR article: GOPs come in "open" and "closed" varieties, and streaming specifically requires the closed kind. An open GOP lets a handful of frames at its start reference the tail end of the previous GOP, a small compression win, while a closed GOP is fully self-contained with no cross-boundary references at all. Adaptive streaming can't tolerate the open version: when a player switches renditions at a segment boundary, exactly the mechanism the ABR article covered, a segment beginning with frames that reference content from a different rendition's previous segment produces visible corruption, since the player never actually received those referenced frames. That's why every modern ABR workflow encodes with closed GOPs aligned to segment boundaries as a hard requirement, not a preference, open GOPs are reserved for archival masters and single-file VOD where nothing ever needs to switch mid-stream.

Why VOD caches, and P2P-distributes, so efficiently

A live segment is relevant for one narrow window and then it's gone, nobody requests last minute's live segment again once it has aged off the sliding-window manifest. A VOD segment is the opposite: the exact same bytes, at the exact same URL, might get requested thousands or millions of times over the file's lifetime, since nothing about it ever changes once it's published. That's precisely the property that makes both traditional CDN caching and peer-assisted delivery work so well for VOD specifically, a cache or a peer that already has a given segment can keep serving it indefinitely with zero re-processing, and the more popular a piece of VOD content is, the more efficient that reuse gets. This is also the direct link back to how AIOZ's own DePIN delivery network functions economically, a P2P mesh only offloads meaningful bandwidth away from origin servers when the same content gets requested by enough different viewers to make peer-to-peer sharing worthwhile, exactly the access pattern VOD's static nature produces and live's real-time nature doesn't. A popular VOD title effectively gets more efficient to deliver the more it's watched, since a growing pool of viewers who already hold a given segment locally can serve it to the next request instead of that request going all the way back to origin storage, a dynamic with no equivalent on the live side, where there's no backlog of already-delivered content for a new viewer to draw from.

What AIOZ Stream actually means by VOD

AIOZ's own launch materials are specific about this: the platform's V1 release is described as covering "video-on-demand across both short-form and long-form formats," VOD as its own defined scope, separate from live streaming, which the same materials describe as a later addition. That's consistent with everything covered in this series so far, the bitrate ladder, ABR, and manifest mechanics already documented all describe a platform built around the process-once-play-many model this article opened with, not the continuous real-time pipeline live streaming needs.

That framing also clarifies a distinction worth being precise about: "VOD" describes a distribution model, not a content genre. A recorded lecture, a two-hour film, a five-minute product demo, and a rebroadcast of yesterday's live event are all VOD the moment they're sitting as a finished, seekable file waiting for on-demand requests, regardless of how different they are as content. What makes something VOD is entirely the process-once-play-many relationship covered above, not its length, its subject matter, or whether it was originally captured live before being turned into an on-demand asset afterward.

Frequently Asked Questions

What's the actual technical difference between VOD and live streaming?
VOD content is fully processed once and served to unlimited playback sessions afterward. Live content is encoded continuously in real time for viewers watching roughly the same moment, under a hard latency constraint VOD doesn't have.

Why can't I seek to the exact frame I want in a video?
Because most frames are encoded as predictions from nearby frames and can't be decoded standalone. A player can only start playback cleanly at a keyframe, so scrubbing snaps to the nearest one rather than the exact point dragged to.

What is a GOP, and why does its length matter?
A Group of Pictures is the span between keyframes. Shorter GOPs give more seek points and better error recovery at the cost of compression efficiency; longer GOPs compress better but leave fewer clean points to seek to.

Why does VOD work so well with CDNs and P2P delivery specifically?
Because VOD segments never change once published, the same bytes get requested repeatedly by different viewers, letting a cache or peer serve them indefinitely without re-processing. Live segments exist for one narrow window and don't get reused the same way.

Does AIOZ Stream's V1 release include live streaming?
No. AIOZ's own materials describe V1 as covering video-on-demand specifically, with live streaming positioned as a separate, later addition.

Is the ABR and manifest mechanics different for VOD vs. live?
Not structurally, both use the same bitrate-ladder-and-manifest approach. The difference is that a VOD manifest is built once and stays static, while a live manifest is a sliding window that continuously updates.

What's the difference between an open and closed GOP?
An open GOP lets its first few frames reference the end of the previous GOP for a small compression gain. A closed GOP has no such cross-boundary references, which adaptive streaming requires, since switching renditions at a segment boundary would otherwise reference frames the player never received.

Related Reading

• TVOD vs SVOD vs AVOD vs W2E: Monetization Models Compared: how VOD content actually gets monetized once it's delivered
• Decentralized Storage vs Centralized Cloud Storage for Video: where VOD's always-on catalog of files actually lives between requests
• How to Build a Video Bitrate Ladder: A Practical Guide: the encoding step VOD content goes through exactly once
• How Video Segmentation and M3U8 Manifests Actually Work: the static, complete manifest structure specific to VOD
• What Is AIOZ DePIN and How It Powers Video Delivery: the P2P delivery economics this article's caching section builds on

References

• AWS: Back to Basics, GOPs Explained: the I-frame/keyframe mechanics and GOP-length tradeoff cited above
• Fora Soft: GOP Structure, I/P/B-Frames: the open-vs-closed GOP distinction and its ABR-switching requirement cited above