Why this matters
If you are a founder, product manager, or first-time streaming CTO, you will hear these five words used interchangeably by vendors, decks, and even engineers — and they are not interchangeable. Calling a scheduled free channel "VOD" or a delivery method "a content type" will send your team down the wrong technical path, mis-price your CDN bill, and confuse your content-licensing conversations. This article fixes the vocabulary so you can scope the right pipeline, ask vendors precise questions, and read a contract without guessing. It is the second stop in the course after the end-to-end platform map, and every later block assumes you can tell these terms apart.
The trick: two questions, not five words
The fastest way to untangle these terms is to stop treating them as a single list of competitors. They answer different questions.
The first question is how the video gets to the viewer — the delivery method. That is what OTT describes. The second question is who controls the clock — whether the viewer chooses when to watch, or a schedule does. That is what VOD, live, and linear describe. FAST is a fourth kind of answer: it is a business model (free, ad-supported) that happens to ride on a linear schedule. And CTV, a term you will hear in the same breath, answers a third question entirely — what screen the video plays on.
Hold that frame as you read: delivery, timing, money, screen. Almost every "OTT versus VOD" argument you will encounter is really two of those four questions getting tangled together.
Figure 1. The vocabulary map. OTT is the pipe; VOD, live, and linear are timing modes that flow through it; FAST is a money model on a linear schedule; CTV is the screen.
OTT — the delivery method
OTT stands for over-the-top, and the "top" it goes over is the traditional pay-TV system — the cable box, the satellite dish, the telecom's managed network. An OTT service delivers video "over the top" of the ordinary public internet, straight to an app on a phone, a browser, or a TV, with no cable subscription in between. Netflix, YouTube, a sports app, and a corporate training portal are all OTT, because they all reach you through the open internet rather than a broadcaster's private cable plant.
The key thing to internalise is that OTT is not a kind of content — it is a route. It tells you nothing about whether you are watching a movie on demand or a live football match. It only tells you the video crossed the public internet to reach your app. Almost everything in this course is about building OTT services, so when someone asks "is this OTT or VOD?", the honest answer is usually "it is OTT, and the VOD part is the question you actually mean."
The useful contrast is IPTV — internet-protocol television delivered over a telecom's managed, quality-controlled network (your ISP's own set-top box service), not the open internet. IPTV and OTT can carry the same shows; the difference is whose pipe they travel through. OTT uses the public internet, which is cheaper and reaches everyone, but gives you no guaranteed bandwidth — which is exactly why adaptive bitrate streaming, covered in our end-to-end map, exists.
VOD — the on-demand mode
VOD stands for video on demand: content sitting in a library that the viewer starts whenever they choose. The viewer controls the clock. They press play, pause, rewind, and come back tomorrow to finish. A Netflix film, a YouTube upload, and a course lesson are all VOD because the moment of watching is the viewer's decision, not a schedule's.
Technically, VOD is the simplest timing mode to build. The video is encoded once, stored, and served on request — there is no real-time deadline. In the delivery format, this shows up concretely: an HLS playlist for an on-demand title is tagged #EXT-X-PLAYLIST-TYPE:VOD (IETF RFC 8216, the HLS specification), meaning the full list of segments is known up front and never changes. The player can see the whole timeline, so scrubbing and offline download are easy.
VOD is a timing mode, not a business model. People often say "VOD" when they mean "subscription" (Netflix) — but a VOD library can be paid by subscription (SVOD), supported by ads (AVOD), or rented per title (TVOD). Those business models get their own article: SVOD, AVOD, TVOD, and hybrid. For now, keep VOD meaning one thing: the viewer picks the moment.
Live — the real-time mode
Live content is happening right now and is broadcast in near real time: a sports match, a concert, a breaking-news feed, a product launch. The schedule controls the clock, and so does reality — there is no re-running a dropped frame, because the event is occurring as you encode it. Everyone watching is roughly synchronised, give or take the few seconds of delay that streaming adds.
Live is the hardest timing mode to build, for one reason: there is no second chance. A VOD encode that fails can be re-run overnight; a live encode that fails has lost the moment. Live pipelines therefore add real-time encoding, tight latency budgets measured in seconds (or under a second for low-latency variants), and aggressive failover. In the HLS specification, a live stream uses a sliding window playlist — the manifest lists only the most recent segments and is refreshed continuously, so the player chases the live edge rather than seeing a fixed timeline. The deep mechanics of low-latency delivery live in our Video Streaming section; here, the product fact is that live trades simplicity for immediacy.
A note on numbers, because live is where cost spikes. Live concurrency is brutal: with a VOD title, viewers arrive spread across days, but a live final pulls everyone into the same minute. Suppose 50,000 viewers watch a live event at a 5 Mbps bitrate. The sustained outbound rate is:
50,000 viewers × 5 Mbps = 250,000 Mbps = 250 Gbps sustained
Over a single one-hour broadcast, that delivers:
250 Gbps × 3,600 s = 900,000 Gigabits = 112,500 Gigabytes ≈ 112.5 TB in one hour
The same 50,000 views of a VOD title spread over a week barely register as a spike. Same audience, same bitrate — but the timing mode changes the egress bill and the CDN architecture entirely. That is why the words matter to your budget, not just your glossary.
Linear — the scheduled mode (and "simulated live")
Linear is the channel model from traditional television, recreated on streaming: a continuous, pre-arranged stream of programs and ads that plays on a schedule, the same content for everyone tuned in at that moment. You do not press play on a specific title; you "tune in" and watch whatever is on. The clock belongs to the schedule, not the viewer and not a live event.
Most linear streaming is simulated live (also called "as-live"): the programs are pre-recorded VOD files, but a playout scheduler stitches them into a never-ending stream and plays them out on a timetable, as if they were live. Nothing is actually happening in real time — but to the viewer it behaves like a TV channel, complete with an on-screen program guide (an EPG, electronic program guide). The technology that assembles these channels is now standardised: SCTE 301, "Next Generation Linear Channel Assembly," specifically addresses scaling linear and FAST channels built from VOD assets.
Linear sits between VOD and live in difficulty. It reuses VOD's pre-encoded files (no real-time encoder needed), but it adds the scheduler, the program guide, and — crucially — ad signaling, because a channel without ad breaks earns nothing. The standard that marks where an ad can go is SCTE-35 (ANSI/SCTE 35), which inserts frame-accurate cue messages — splice_insert and time_signal — into the stream so downstream systems know exactly when to swap in an ad. SCTE-35 even specifies timing discipline: a splice_insert message must arrive at least four seconds before the splice point (SCTE-35 §9.2). Ad insertion gets its own article in the monetization block; the takeaway here is that a linear channel is VOD files plus a schedule plus ad markers.
FAST — free ad-supported streaming TV
FAST stands for Free Ad-Supported Streaming Television. It is not a new timing mode — it is a business model built on the linear mode. A FAST service offers linear, channel-style streams that are free to watch, paid for entirely by the ads inserted into the schedule. Pluto TV, Tubi, The Roku Channel, Samsung TV Plus, and Xumo are the well-known examples: you open the app, browse a grid of channels, and watch whatever is playing, with ad breaks, at no charge.
FAST matters because it is the fastest-growing corner of streaming. The global FAST market is projected at roughly $14.9–15.2 billion in 2026, up from about $12.3 billion in 2025, growing above a 17% annual rate by most estimates (The Business Research Company; Coherent Market Insights, 2026). In the US, the leaders are large: The Roku Channel reaches about 97 million monthly US viewers, Tubi about 92 million, and Pluto TV about 69 million, with roughly 46% of US internet households using a FAST service regularly (Parks Associates, 2026). For a media company sitting on a back catalog, FAST turns a dormant library into an ad-earning channel without asking anyone to subscribe.
Architecturally, FAST is linear with the ad stack turned all the way up. You need the playout scheduler, the program guide, SCTE-35 ad markers, and server-side ad insertion to stitch ads cleanly into the stream. The monetization model is pure AVOD economics applied to a channel, which is why FAST decisions belong with your business-model choice.
The one term that is on a different axis: CTV
CTV stands for connected TV — an internet-connected television device: a smart TV, a streaming stick like a Roku or Fire TV, or a game console used for streaming. Notice it answers none of the questions above. CTV is not a delivery method and not a timing mode — it is the screen. Nielsen frames it cleanly: OTT is the delivery across any device, and CTV is the subset of that watched specifically on the television (Nielsen, 2024).
The practical relationship: CTV is a subset of OTT defined by device. Streaming a match on your phone is OTT but not CTV. Streaming the same match on a smart TV is both. Advertisers care intensely about the distinction because TV-screen inventory sells at a premium, but for building a platform, CTV simply tells you which client apps you must ship — covered in the client matrix. Keep it filed under "screen," not "delivery."
The five words in one table
| Term | Which question it answers | Who controls the clock | Typical money model | Delivery format | Build difficulty |
|---|---|---|---|---|---|
| OTT | How it is delivered | n/a (it is the route) | any | HLS / DASH over open internet | — (it is the pipe) |
| VOD | When you watch | The viewer | SVOD / AVOD / TVOD | HLS/DASH, fixed playlist | Lowest |
| Live | When you watch | The event | subscription, ads, PPV | HLS/DASH, sliding window | Highest |
| Linear | When you watch | The schedule | ads, subscription | HLS/DASH from a playout scheduler | Medium |
| FAST | How it is funded | The schedule (linear) | Ads only (free to viewer) | Linear + SCTE-35 + SSAI | Medium-high |
| CTV | Which screen | n/a (it is the device) | any | any OTT app on a TV device | — (it is the screen) |
All five delivery cases use the same HLS (RFC 8216) and DASH (ISO/IEC 23009-1) formats — the manifest behaves differently (fixed vs sliding window), but you do not invent a new protocol per mode.
A common mistake: pricing a channel like a library
The most expensive vocabulary error is treating linear or live like VOD when sizing infrastructure. A planner who hears "we have 500 hours of content" pictures a VOD library — viewers trickling in, egress spread thin, caches warm. But if that content runs as a FAST channel or a live event, the audience collapses into the same moment, and the egress math above (112.5 TB in one hour at 50,000 concurrent viewers) hits all at once. The fix is to say the precise word early: "this is a linear FAST channel, peak concurrency unknown, plan for a spike," not "we have some VOD." The word changes the CDN commit, the origin design, and the ad stack. Get the noun right and the architecture follows.
Where Fora Soft fits in
The reason these distinctions are second nature to us is that we have built across all of them. Since 2005, Fora Soft has shipped 625+ video projects for 400+ clients spanning video streaming, OTT/Internet TV, live conferencing, surveillance, e-learning, and telemedicine — products that run VOD libraries, real-time live pipelines, and scheduled linear channels, often inside one platform. When a media company comes to us with "we want an OTT service," our first job is the one this article does: separate the delivery method from the timing mode from the money model, so the build targets the right pipeline and the right scale from day one.
What to read next
- What is an OTT platform, end to end — the pipeline these words flow through.
- SVOD, AVOD, TVOD, and hybrid — the money models VOD and FAST plug into.
- Live vs VOD: two pipelines, one platform — why timing mode splits the build.
Call to action
- Talk to a streaming engineer — book a 30-minute scoping call to talk through your video on demand platform plan.
- See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
- Download the OTT Vocabulary Cheat Sheet — One-page reference mapping OTT, VOD, live, linear, FAST, and CTV to delivery method, who controls the clock, money model, and delivery format.
References
- IETF RFC 8216 — HTTP Live Streaming (HLS) (IETF, August 2017). Tier 1.
#EXT-X-PLAYLIST-TYPE(VOD/EVENT) and the sliding-window live playlist that distinguish on-demand, event, and live manifests. https://www.rfc-editor.org/rfc/rfc8216 - ISO/IEC 23009-1 — Dynamic Adaptive Streaming over HTTP (MPEG-DASH) (ISO/IEC). Tier 1. The DASH
.mpdmanifest and its static (VOD) vs dynamic (live/linear) presentation types. https://www.iso.org/standard/83314.html - ANSI/SCTE 35 — Digital Program Insertion Cueing Message (SCTE). Tier 1.
splice_insertandtime_signalad-cue messages; the four-second pre-roll timing rule (§9.2) for linear and live ad insertion. https://account.scte.org/standards/library/catalog/scte-35-1-digital-program-insertion-cueing-message-part-1-legacy-splice-based-and-time-based-signaling/ - ANSI/SCTE 301 — Next Generation Linear Channel Assembly: Scaling FAST and Other Use Cases (SCTE). Tier 1. Standardised assembly of linear and FAST channels from VOD assets with dynamic ad insertion. https://account.scte.org/standards/library/catalog/scte-301-next-generation-linear-channel-assembly-scaling-fast-and-other-use-cases/
- W3C Media Source Extensions (MSE) (W3C Recommendation). Tier 1. The browser API that lets a web player consume VOD, live, and linear HLS/DASH alike. https://www.w3.org/TR/media-source/
- "What's the difference between OTT, CTV and streaming?" (Nielsen, 2024). Tier 5. CTV as the TV-screen subset of OTT; the device-vs-delivery distinction. https://www.nielsen.com/insights/2024/whats-the-difference-ott-vs-ctv/
- Top Ten US FAST Services (Parks Associates, 2026). Tier 5. Tubi, The Roku Channel, and Pluto TV as the leading US FAST services; ~46% of US internet households use FAST. https://www.parksassociates.com/blogs/entertainment-content-pr/parks-associates-releases-top-ten-us-fast-services-with-tubi-the-roku-channel-and-pluto-tv-leading
- FAST market outlook 2026 (The Business Research Company; Coherent Market Insights, 2026). Tier 5. FAST market ≈ $14.9–15.2B in 2026, up from ≈ $12.3B in 2025; CAGR ~17–21%. https://www.researchandmarkets.com/reports/6226730/free-advertisement-ad-supported-streaming
- "FAQ on FAST: how free streaming TV is reshaping the ad market in 2026" (eMarketer, 2026). Tier 5. FAST viewership share and ad-market context. https://www.emarketer.com/content/faq-on-fast--how-free-streaming-tv-reshaping-ad-market-2026


