How online video works

Press play on a lesson and it starts in about a second. In that second, a file bigger than a hundred copies of the textbook was turned into several versions, cut into hundreds of small pieces, copied to servers on several continents, and reassembled on whatever phone or laptop the learner is holding, on whatever network they are on. That machinery is what "add video" actually means, and to a team that has shipped text and quizzes it is almost entirely invisible.

This guide makes it visible. Read it and you will be able to scope the work, cost it, and hold your own in the meeting before anyone tries to sell you anything.

We will follow one file the whole way: a 48-minute recorded lecture from one of your instructors. By the end you will know each thing that has to happen to it, why you cannot skip that thing, and what it means specifically for a learning product. There are six stages.

One example, any product. We use an online course as the running example because it makes the stakes concrete, but the pipeline is identical for any product adding video: a marketplace, a fitness app, a media service, internal training. Where this guide says learner, read user or viewer.

Stage 1. Ingest: the file is bigger than you think

Ingest just means getting the recording into your system. The surprise is the size. Your instructor's 48-minute lecture, recorded at 1080p, is roughly 1 to 3 GB if it came out of a normal camera or screen recorder, and can be 20 GB or more if it was captured in a high-quality format like ProRes. That single fact breaks the naive plan of "let them upload it to our server." A 3 GB upload over hotel wifi will fail halfway and start again from zero, and your instructors are not on office fibre. This is why real systems use resumable uploads, which break the file into pieces and retry only the piece that failed, so a dropped connection at 80 percent does not mean starting over.

What this means for your users: the people who upload never lose a big file to a flaky connection, so content actually makes it into your product.

If you take one thing from this stage: the upload step alone is a small engineering problem, and it is the first place a video feature quietly breaks. FastPix has a plain-language guide to video ingest if you want the deeper version.

What is a codec, and how is it different from a format like MP4?

This is the confusion that trips up almost every newcomer, so it is worth slowing down. A codec is the method used to compress video so it is small enough to travel over the internet: the common ones are H.264 (old, plays literally everywhere), H.265 also called HEVC (about 40 percent smaller at the same quality, but patent-encumbered), and AV1 (smaller again, royalty-free, newer, not on every old device yet). A container, on the other hand, is the box the compressed video and audio are shipped in, and that is what a file extension like MP4 or WebM usually refers to. The mistake is thinking "MP4" describes the quality or the compression. It does not. An MP4 is a box; H.264 is what is inside it.

You care about this because the codec decides your storage and bandwidth bill and which devices can play the video, and the container decides compatibility with players. A good primer keeps a running glossary, because these words come up in every vendor conversation.

Stage 2. Encode: why one file becomes a ladder of many

Here is the heart of it. You cannot serve that one lecture file to everyone, because your learners are on wildly different screens and connections, and one file can only be one size. So the video is transcoded, which means re-encoded into several versions at different resolutions and bitrates. Bitrate is simply how much data per second a version spends: more bitrate looks better and needs a faster connection. The set of versions is called the encoding ladder, and a typical one for your lecture looks like this:

A weak-signal phone pulls the 480p rung and keeps playing; the office laptop pulls 1080p and it looks crisp. Two things a PM should know about the ladder. First, it is not free: every rung is a separate encode, so it costs processing time and storage, and it is why video pricing is usually per minute. Second, a smart ladder is content-aware. A talking-head lecture with static slides can use far less bitrate than a chemistry demo full of motion, and encoding each title to its own ideal ladder, called per-title encoding, saves roughly a third of storage and bandwidth at the same quality, and sometimes more depending on the content. The number of rungs and how far apart they sit is a real design choice too, and the audio is encoded once and shared across them. You do not tune this by hand for every video; a good encoder does it for you, but you should know it is happening, because it is a real line on the bill.

What this means for your users: a user on a cheap phone and weak signal still gets a version that plays instead of a spinner, which is the difference between finishing and bouncing.

Stage 3. Package: chunks and the manifest that lists them

Now each rung of the ladder is chopped into short segments, usually 2 to 6 seconds each, and a small text file called a manifest is written that lists every rung and where its segments live. The dominant recipe for this is HLS, HTTP Live Streaming, the format Apple created that nearly every device understands; the other is DASH, Dynamic Adaptive Streaming over HTTP, which does the same job and is common on Android and smart TVs, so mature systems usually produce both. The manifest is the clever part, and it is worth seeing one, stripped down:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480
480p/index.m3u8

That is the whole trick behind streaming. The player reads this list, sees the rungs and their bitrates, and can switch between them on the fly. And because the video is already chopped into segments, the player fetches the first few seconds and begins playing while the rest is still arriving. Streaming, in one line, is watching the start of something while the rest is still on its way.

Two details a PM will hear about. Apple devices do not play DASH natively, which is the practical reason mature systems ship both HLS and DASH. And segment length is a quiet tradeoff: short 2-second segments let the player switch quality faster and get closer to real time, while longer 6-second segments are more efficient but slower to react. Packaging is a separate step from encoding, and cheap to get wrong: a mislabeled manifest is a common reason a video plays on Chrome and stalls on an old Android.

What this means for your users: there is no download to sit through. A viewer who tapped on impulse is watching before the impulse fades.

Stage 4. Deliver: why you cannot serve video from one server

Video is heavy and distance adds delay, so if every learner pulls segments from a single server in your data centre, the ones far away will buffer. A CDN, content delivery network, is a fleet of servers spread across the world that keep cached copies of your segments close to wherever people are, so each learner streams from a nearby edge instead of your origin. It is the difference between one shop and a chain with a branch in every city.

For a PM the CDN matters for two reasons: it is what makes video feel instant for a global class, and it is usually the largest line on a video bill, because you pay for every gigabyte delivered, called egress. This is why "we will just host it ourselves" gets expensive fast: you would be paying to move every gigabyte to every learner, on top of building the rest. A CDN is not optional past a handful of local viewers.

What this means for your users: distance stops deciding quality. A user in another country sees the same smooth playback as one down the road from your office.

Stage 5. Play: the player and adaptive bitrate

The player is the actual video component inside your app, and it does more than show a play button. It reads the manifest, watches the network second by second, and picks the best rung the connection can carry right now. It does this by watching how fast segments are arriving and how much video it has buffered ahead: when the buffer starts draining, it drops to 480p and keeps playing instead of freezing; when wifi returns and the buffer refills, it steps back up.

That automatic switching is adaptive bitrate, ABR, and it is the single biggest reason a video feels smooth. The reason a good player is real software, not a weekend job, is everything around that: it has to handle captions, remember playback position, respect your branding, do the encrypted handshake for protected video, and behave identically on Safari, Chrome, an old Android, and a smart TV, each of which supports different codecs. Teams either adopt a mature player or spend months rediscovering these edge cases one device at a time.

What this means for your users: video keeps playing when the signal dips instead of freezing, and a frozen video is one of the fastest ways to lose a viewer mid-video.

What actually happens in the seconds after someone hits upload?

This is the mental model most PMs are missing, and it changes how you design the feature. Encoding a 48-minute lecture into a full ladder is not instant; it is a job that takes somewhere between half and twice the length of the video, depending on the ladder and the encoder. So the flow is not "upload and it is ready." It is asynchronous: the file uploads, the system queues a transcode job, and some minutes later it fires a webhook, a small automated message to your backend, that says "this video is ready." Your app should never make the instructor sit and watch a spinner; it uploads, shows "processing," and lights up the lesson when the ready webhook arrives.

If you design your video feature as if upload is instant, you will build the wrong UI and your first demo will hang on a spinner. Design for the webhook. FastPix documents the ready webhooks if you want to see the exact events.

Captions are an obligation, not a feature

For a learning product this deserves its own stage, because it is not optional the way it might be for a marketing clip. Accessibility law in most markets effectively requires that educational video carry accurate captions: in the United States the legal hooks are the ADA and Section 508, with the WCAG guidelines, Web Content Accessibility Guidelines, as the standard they point to, and other regions have their equivalents. Institutions will ask about it in procurement. Beyond compliance, captions lift completion, because a large share of people watch with sound off or are not native speakers of the language. The good news is that captions are now produced automatically: automatic speech recognition transcribes the audio and can generate a caption file and a full transcript, which also becomes the raw material for search and quiz generation later. Treat captions as a requirement in your first version, not a fast-follow, and know that modern in-video AI generates them on upload rather than costing you $50 to $150 per video to a captioning agency.

What this means for your users: users who are deaf or hard of hearing, who are not native speakers, or who are simply watching with sound off can all follow along, which widens who your product actually works for.

The bits people forget: thumbnails, storage, and protecting paid video

Three smaller things that always come up late. Thumbnails and preview images: every video list and scrubber needs poster frames and a strip of images for hover-preview, and these are generated from the video, not drawn by hand. Storage: every rung of every video sits in storage and accrues cost for as long as you keep it, so a growing library is a growing bill, and most of a large video bill is storage and delivery, not the fancy parts. And protection: if learners pay for the video, you need to stop a shared link from working forever and stop easy downloading. Two tools do this: signed URLs, which are temporary expiring links, and DRM, digital rights management, which encrypts the video so only an authorised player can decrypt it, using Widevine on Chrome and Android, FairPlay on Apple, and PlayReady on Microsoft and many TVs. That three-way split is exactly why DRM is a pain to build and a reason teams buy it.

A public YouTube link, worth saying now, has none of this.

Rough cost intuition, so you can build a back-of-envelope model. These are order-of-magnitude industry ballparks and every vendor differs, but for scoping: encoding a video runs on the order of a few cents per minute; delivery through a CDN is often in the range of five to fifteen cents per gigabyte and falls with volume, where one gigabyte is roughly ten minutes of HD; and storage is a few cents per gigabyte per month, paid for as long as you keep every rung. Delivery usually dominates once you have an audience, so a growing, well-watched library is mostly a delivery bill. On a build-it-yourself stack that bill also spreads across a dozen separate services, which is how an AWS video setup adds up at month-end.

Live is a different, harder problem

Everything above describes on-demand video, a file processed once and played many times. Live classes are a separate discipline, because there is no second take and the whole pipeline has to happen in seconds while it is being watched. Live adds real-time ingest, usually over a protocol called RTMP, Real-Time Messaging Protocol, from the streaming software, encoding on the fly, and a constant tension between low latency, how close to real time the viewer is, and stability. It helps to know the tiers: standard HLS runs roughly 10 to 30 seconds behind real time, low-latency HLS gets that to about 2 to 6 seconds, and WebRTC, Web Real-Time Communication, reaches under a second when you need true back-and-forth interactivity.

If live classes are on your roadmap, treat live as its own project with its own analytics, not a checkbox on the on-demand feature. The saving grace is that a recorded live class can become an on-demand video automatically, so the archive builds itself.

Stage 6. Measure: how do you know any of it worked?

Once video is live, leadership asks "is it working?", and a play count cannot answer that. There are really two kinds of video data, and you want both, so it helps to know the actual metrics. Quality-of-experience data is about the plumbing, and three numbers carry most of it: startup time, how long from pressing play to the first frame, where under about two seconds is good; rebuffer ratio, the share of watch time spent frozen and buffering, where under roughly one percent is good and a few percent starts losing people; and the playback failure rate, the share of plays that never start at all. Read together they tell you whether a drop-off is your content or your delivery. Engagement data is about learning: the retention curve, which is the share of viewers still watching at each point of a video, plus completion rate, the exact minute where attention falls off, and which parts get replayed. None of it exists unless something captures it from the player, and it is first-party data about your own learners that you own, which is precisely the thing you cannot get out of YouTube.

What this means for your users: because you can see where a video loses people, you can fix the weak parts, so the next set of users gets a better version instead of the same drop-off.

If you want to see what teams do with these numbers once they have them, the same two families of data, quality and engagement, are the raw material behind second-by-second retention graphs, to put a per-creator analytics page inside their product, to watch the QoE metrics that predict churn, and, in education specifically, to build a learner readiness dashboard that flags at-risk learners, a content-effectiveness view that finds the videos losing people, and a program outcome and ROI dashboard. You do not need to build these on day one. You need to make sure, on day one, that the data is being captured, because you cannot backfill it later.

What all six stages add up to

Step back and look at what "add video" actually contained: resumable ingest, a content-aware encoding ladder, HLS and DASH packaging, a global CDN, a player that does ABR on every device, asynchronous processing with webhooks, automatic captions for compliance, thumbnails, storage management, signed URLs and three flavours of DRM, an optional live pipeline, and a data layer for both quality and engagement. None of it is impossible. All of it is real, and none of it goes away once built: the pipeline keeps running, and someone keeps it running. Build it yourself and that someone is your team, quarter after quarter, which is where a surprising share of engineering velocity quietly goes. The work does not disappear when you call an API. It stops being yours to run. That is the honest weight of the thing your roadmap called "add video."

The question is not whether you need these stages, you do, the moment you have a real audience. The question is who builds and runs them: you, a free host like YouTube, or a video API that hands you all six as a service. That is the decision, and it is what Part 2 is about.