What Is Video Transcoding and Adaptive Bitrate Streaming?

Video transcoding is the step that converts an uploaded video into several smaller, standardized versions that every device can play. Adaptive bitrate streaming is what happens next: the player picks among those versions as it plays, moving up when the connection is fast and down when it slows.

Both are invisible to viewers when they work and obvious when they do not. If you are planning a white-label YouTube clone or any other video site, this guide explains the pipeline in business terms, so you can make sensible choices about quality, cost and speed.

What happens after a creator hits upload

Treat the pipeline as a sequence. Each step hands a file to the next.

1. Upload. The creator sends the original file, called the source or mezzanine file, to your storage. It can be huge, shot on a phone or camera in a format chosen for editing, not for the web.
2. Inspect. The system reads the file to learn its length, resolution, frame rate, codecs and audio tracks, and rejects anything outside your rules.
3. Transcode. The system decodes the source and re-encodes it into the renditions you defined, for example a small, a medium and a large version.
4. Package. Each rendition is cut into short segments, and a manifest file lists them. This is where HLS or DASH comes in.
5. Extras. The system produces thumbnails, preview frames and, if you offer them, captions.
6. Store. Segments and manifests go to storage that a delivery network can read.
7. Deliver and play. A viewer's player downloads the manifest, picks a rendition, fetches segments and switches as conditions change.

The source file is usually kept as an archive but is not what viewers watch. We come back to that in the mistakes section.

Transcoding in plain words

To transcode is to decode a video and encode it again with different settings. Three ideas explain almost everything about it: codecs, containers and renditions.

Codecs: how video is compressed

Raw video is far too large to send over the internet. Mozilla's web video codec guide puts a minute of uncompressed HD video at roughly 15 GB, which is why every real service compresses it. A codec is the method of compression. Most are lossy, which means the decoded video is not identical to the original, and a stronger squeeze gives a smaller file with more visible damage, such as blockiness or banding.

This table follows MDN's codec guide, which also says AV1 can compress considerably better than H.264. Support changes, so check a current compatibility table before you commit. A common plan is H.264 for everyone, with a second codec added later for the devices that can use it.

Containers: the wrapper

A container is the file format that holds compressed video and audio streams plus metadata. MDN describes the container as the box and the codec as what is inside. MP4 and WebM are common containers. In streaming, the streams are held in small segment files, often in fragmented MP4 or MPEG-2 transport stream form, which is the reason people talk about "an HLS stream in fMP4." When you ask a vendor what format it supports, ask for the codec, the container and the streaming protocol separately.

Renditions: the same video at several sizes

A rendition is one encoded version at a specific resolution and bitrate. Bitrate is the amount of data per second of video, and it largely sets how much bandwidth the viewer needs. A phone on weak signal cannot fetch a large high-resolution stream quickly enough, so it needs a smaller one. A television on fiber wants the opposite.

The set of renditions you publish is the ladder. A simple example, with invented figures:

These numbers are an illustration of the idea, not a recommendation. Your ladder depends on the content (a talking head compresses far better than a sports match), the codec and your audience's devices.

Adaptive bitrate, HLS and DASH

Adaptive bitrate streaming lets the player change quality while the video plays. It works because the video is broken into small segments, each available at every quality in the ladder. After each segment, the player decides which rung to ask for next, based on how quickly the last one arrived and how full its buffer is.

How HLS works

HTTP Live Streaming, or HLS, was created by Apple and is documented in IETF RFC 8216. It uses plain text playlist files. A master playlist lists the available variant streams, each one an encoding of the same content at a given bitrate and resolution. Each variant has a media playlist that lists the segments in order. The RFC says clients should switch between variant streams to adapt to network conditions. Segments can be MPEG-2 transport streams or fragmented MP4. Apple's streaming page describes HLS as delivery through ordinary web servers and content delivery networks, and Apple also publishes an authoring specification and a stream validator tool for checking your output.

How DASH works

MPEG-DASH, short for Dynamic Adaptive Streaming over HTTP, solves the same problem with a different manifest, called an MPD file, and a vendor-neutral standard (ISO/IEC 23009-1). The DASH Industry Forum publishes interoperability guidelines so that players and encoders from different vendors work together. In browsers, DASH playback usually relies on JavaScript libraries and Media Source Extensions, as MDN explains.

Many services publish both from the same segments using a common packaging approach, but a small platform can start with HLS and add DASH later if a device demands it.

HLS versus a plain MP4 file

A plain MP4 is one file at one quality. It can start playing before it has fully downloaded, so it works for short clips on stable connections. It cannot change quality mid-playback. If the connection drops, the viewer waits. For that reason, anything longer than a short clip, or served on mobile networks, benefits from HLS. The cost of HLS is more files to store and a packaging step.

Thumbnails, captions and metadata

The same pipeline usually produces more than video.

• Thumbnails. A frame grabbed from the video, often several candidates so the creator can pick one. Thumbnails drive clicks, and they are small images, which makes them cheap to serve.
• Preview strips. A grid of tiny frames used when a viewer drags the progress bar. It needs one extra processing step.
• Captions and subtitles. HLS supports WebVTT subtitle files. Captions can be uploaded by the creator or generated by a speech-to-text service, and generated ones need a review option because accuracy varies by language and audio quality.
• Audio tracks. Multiple languages can be separate tracks listed in the manifest.
• Metadata. Duration, resolution, file size, upload date and a checksum let your system search, filter and recover from failures.

Decide which of these you offer at launch and which are later, because each adds processing time and storage. Captions in particular raise accessibility and reach, and they are easier to include in the pipeline from the start than to add after thousands of videos exist.

Where processing runs

You can run transcoding in three ways.

The trade is between engineering effort and the unit price per minute of video. A queue of your own workers is cheapest per minute once you have steady volume and someone to run it. A managed service avoids that work and charges for it. Many operators start managed, learn their real volume, and then decide whether to bring processing in house.

As an example from our own range, the short-video product described on the TikTok clone features page uses FFmpeg to convert uploads into several renditions and thumbnails before delivery. For the video-sharing build, the scope of the video pipeline is something we settle with you during setup, so read the YouTube clone features list and confirm the scope with us for your build.

Settings that shape quality

Encoders expose dozens of options. A founder needs to know only the few that change what viewers see or what you pay.

• Constant or variable bitrate. A constant bitrate sends the same data every second, which is easy to plan for but wastes bits on still scenes. A variable bitrate spends more on busy scenes and less on calm ones, so it looks better at the same average size. Most adaptive setups use a capped variable bitrate, so a burst of action cannot exceed what the connection can carry.
• Keyframe interval. A keyframe is a complete picture, and the frames between them store only changes. Players can switch rungs only at a segment start, and a segment normally begins on a keyframe. Frequent keyframes make switching quicker and make files slightly larger.
• Frame rate. Keep the source frame rate unless there is a reason. Doubling it costs far more bits than dropping a rung of resolution.
• Audio. Audio is small next to video, so one or two audio quality levels are usually enough, and spoken content needs far less than music.
• Two-pass or slower presets. Slower encoder settings find more savings in each file. They cost more compute per upload, so use them where a video will be watched many times and the saving repeats.

A small worked example

These are invented round numbers for a ladder. Say a ten-minute upload becomes three renditions averaging 0.8, 2 and 5 megabits per second. Ten minutes is 600 seconds. At 0.8 Mbps that is 480 megabits, or 60 megabytes. At 2 Mbps it is 150 megabytes, and at 5 Mbps it is 375 megabytes. Storing all three takes about 585 megabytes, against roughly 375 for the top rung alone. So the full ladder adds roughly half again to the storage of the best version, plus the source file you keep.

Now compare what a viewer on a weak connection receives. Without the low rung, a person with a 1 Mbps connection cannot sustain even the middle version, so the player stalls. With it, they get a watchable picture in under 60 megabytes. The extra storage is the price of serving that person at all, and the formulas in the cost guide let you decide where a given rung stops paying for itself.

How to test your ladder

Do not trust your office connection. Play the same video on a throttled network that mimics a weak mobile signal, then on a connection that drops out and recovers. Watch three things: how long playback takes to start, whether the picture steps down smoothly instead of freezing, and how quickly it steps back up. Repeat on an older, low-cost phone, because decoding power limits what a device can play as much as bandwidth does. Keep the test files and rerun them whenever you change codec, segment length or the ladder, so you notice a regression before viewers do.

What it means for cost and speed

Every choice above moves one of three things: how long a creator waits, how much you store, and how much you pay to process and deliver.

• More rungs improve the fit between a viewer's connection and the video, but each rung adds storage and processing time for every upload.
• A stronger codec shrinks the files you deliver, which lowers delivery volume, but takes longer and costs more to encode, and some devices cannot play it.
• Short segments let players switch quality faster and start sooner, at the price of more files and more requests.
• Keeping the source file lets you re-encode later when you add a codec, at the price of storing a large original.

The cost model has simple drivers: minutes uploaded times renditions drives processing and storage, and minutes watched times average bitrate drives delivery. The separate guide to video hosting cost for a video sharing site turns those drivers into formulas you can fill with your own quotes, and scaling video delivery covers the architecture and caching decisions. For the full set of monthly bills, see hidden running costs of a creator platform. The one-time price of the software is separate from all of this, as explained under YouTube clone development cost.

Common mistakes

1. Serving the original file. The source is large and in an editing-friendly format, so viewers on mobile data wait, buffer or fail. Always serve a renditions set, and keep the source only as an archive.
2. No low fallback rung. If the smallest rendition is still too heavy for a weak connection, adaptive streaming has nothing to adapt to. Include one small rendition that plays on a poor signal.
3. No upload limits. Without a cap on file size, length and resolution, a single large upload can occupy your processing queue and your storage budget. Set limits, and show creators the rules before they upload.
4. Misaligned renditions. If the renditions do not start new segments at matching points, quality switches can glitch. Use a single packaging tool that produces aligned segments, and test switching with a throttled connection.
5. Choosing a codec only your own phone plays. Test on an older low-cost phone and on an older browser, not only on the newest device.
6. Treating processing as instant. Videos are not playable until processing finishes, so decide what the creator sees meanwhile. A clear status, and ideally a low rendition that is ready first, avoids support tickets.
7. Skipping thumbnails and captions in the plan. They are part of the same pipeline, and adding them to thousands of existing videos later is a batch job you could have avoided.

Glossary

• Bitrate: data per second of video or audio, usually in megabits per second.
• Codec: the compression method for video or audio.
• Container: the file wrapper holding compressed streams and metadata.
• Ladder: the set of renditions you publish for each video.
• Manifest: the text file that lists renditions and segments, an M3U8 playlist in HLS or an MPD file in DASH.
• Mezzanine file: a high-quality source file kept for later re-encoding.
• Rendition: one encoded version of a video at a set resolution and bitrate.
• Segment: a few seconds of video, downloaded and played as a unit.

What to decide next

You need five decisions before you build or buy the video side of a platform.

1. Which protocol you will publish, with HLS as the default and DASH only if a target device needs it.
2. Which codec you will start with, almost always H.264 for reach, and whether to add a second later.
3. How many rungs your ladder has, and the smallest bitrate that still plays on your worst expected connection.
4. Where processing runs: your own queue, a managed service or a video platform API.
5. What limits you set on file size, length and resolution, and what the creator sees while processing runs.

Write the answers down, then price them with quotes from the providers you shortlist. If you want to see how a ready-made video platform handles these decisions, look at our YouTube clone script or ask us what the video pipeline in your build covers.