Definition
Video transcoding is the process of converting an uploaded video into multiple playback-ready versions.
A creator may upload one large source file. Viewers do not all receive that original file. Phones, TVs, browsers, slow networks, and fast networks need different encodings, resolutions, bitrates, and segment sizes.
Transcoding turns:
source_upload.mov
into something closer to:
1080p / 6 Mbps / codec A / segments
720p / 3 Mbps / codec A / segments
480p / 1 Mbps / codec A / segments
audio / 128 Kbps / segments
manifest files
The uploaded file is the source of truth. The transcoded renditions are derived artifacts.
The Pain That Forces This Concept
A naive video service stores the uploaded file and serves it directly.
That breaks quickly:
- a mobile viewer on weak network cannot stream a huge source file smoothly
- an old browser may not support the uploaded codec
- a TV may want high resolution while a phone needs lower bitrate
- one corrupt upload can waste worker time
- one popular video needs globally cacheable segments
- processing a long video can take minutes or hours
The product promise is not "we stored your video." The product promise is "many viewers can start watching quickly and keep watching as their network changes."
That promise requires derived playback artifacts.
Mental Model
Transcoding is a background manufacturing line.
source video -> inspect -> split work -> encode renditions -> package segments -> publish playback assets
The user-facing upload path should not synchronously do all of this. Upload acceptance should record durable source media and enqueue processing work. Workers then produce playback assets asynchronously.
How It Works
A typical flow:
1. Source file is uploaded and verified.
2. Media service records metadata: duration, size, codec, owner.
3. A transcoding job is created.
4. Workers inspect the source file.
5. Workers generate the encoding ladder.
6. Renditions are encoded and split into segments.
7. Manifests are generated.
8. Playback assets are published to storage and CDN paths.
9. Video state changes from processing to playable.
The encoding ladder is the set of renditions the platform chooses to generate. It is a product and cost decision. More renditions improve playback flexibility but increase compute, storage, and cache footprint.
Tradeoffs
| Choice | Benefit | Cost |
|---|---|---|
| Many renditions | Better playback adaptation | More compute and storage |
| Fewer renditions | Lower cost | Worse experience on edge networks |
| High-quality codecs | Better compression | More CPU and compatibility risk |
| Fast processing | Creator sees video sooner | More worker capacity needed |
| Batch processing | Efficient workers | Higher time-to-playable |
Transcoding also introduces failure states. A video can be uploaded but not playable yet. Some renditions can succeed while others fail. The system must decide whether partial availability is acceptable.
Operational Reality
Operators watch:
- queue depth by video duration and priority
- time from upload to playable
- transcode failure rate
- worker CPU and GPU utilization
- retry volume
- dead-lettered jobs
- segment generation errors
- storage growth from derived renditions
- per-codec cost and compatibility
Failure modes:
- a bad source file repeatedly crashes workers
- one long video monopolizes worker capacity
- retries amplify queue pressure
- generated segments do not match the manifest
- audio and video tracks drift
- publishing succeeds for some renditions but not others