A streamer broadcasts at 1080p60 on a 6Mbps upload. A viewer on a mobile phone with a weak signal can’t play 6Mbps video. A viewer on a 4K TV would love more. The platform needs to serve the same stream at multiple quality levels simultaneously. That’s what transcoding at ingest does.

The Ladder#

A “bitrate ladder” is the set of quality levels a stream is available in. A typical ladder:

1080p60: 6Mbps
720p60:  3.5Mbps
480p30:  1.5Mbps
360p30:  0.8Mbps
160p30:  0.3Mbps

Each quality level is a separate encoded stream. The platform transcodes the incoming high-quality stream into each rung of the ladder in parallel. Viewers’ players then use adaptive bitrate streaming to switch between rungs based on their bandwidth.

Where Transcoding Happens#

For video-on-demand, transcoding pipelines can process at any speed: you have hours or days to produce all quality levels before anyone watches. For live streams, you need each quality level available within seconds of the streamer sending it. Latency compounds: if transcoding takes 10 seconds, your stream is already 10 seconds behind before it even reaches the CDN.

Live transcoding happens at the origin ingest layer, immediately after receiving each segment. The raw high-quality segment is fed to N parallel transcoders, one per quality level. As each transcoder finishes its rung, the segment is made available for CDN distribution.

graph TD A[Raw Segment: 1080p60] --> B[Transcoder Pool] B --> C[1080p60 Encoder] B --> D[720p60 Encoder] B --> E[480p30 Encoder] B --> F[360p30 Encoder] C --> G[Manifest Updated: new segments available] D --> G E --> G F --> G G --> H[CDN pulls new segments] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style H fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

GPU vs CPU Transcoding#

Software transcoding on CPUs is flexible but slow and expensive at scale. Hardware transcoding using GPUs or dedicated silicon (like AWS MediaLive or NVIDIA NVENC) is 10-20x faster per unit of cost. A platform running thousands of concurrent live streams can’t afford CPU-only transcoding.

The trade-off: GPU transcoding produces slightly lower quality per bitrate than the best CPU encoders, because GPU encoders use faster but less optimal compression algorithms. For live streams viewed on phone screens, the difference is imperceptible. For archival quality, CPU encoding is still preferred.

Streamer-Side Encoding#

Some platforms offload encoding to the broadcaster: the streamer’s software (OBS, Streamlabs) encodes locally to multiple quality levels before sending. This saves server-side transcoding costs but requires the streamer to have enough upload bandwidth to send multiple streams simultaneously. A streamer with 10Mbps upload can send multiple quality levels; one with 4Mbps upload cannot.

At Salesforce#

We processed report data through parallel transformation stages, not unlike a transcoding pipeline. Each stage produced an output in a different format: CSV for downloads, JSON for the API, pre-aggregated data for dashboard display. Initially we did this sequentially: full processing, then three format conversions. Switching to parallel conversion after a common ingestion stage cut total time from 45 seconds to 18 seconds. Same principle as parallel transcoding rungs from a single decoded source.

What I’m Learning#

The latency budget for live transcoding is tight. Every second of processing delay becomes a second of viewer latency. GPU acceleration isn’t optional at scale; it’s the only way the economics work.

Have you worked with real-time processing pipelines where GPU or hardware acceleration changed what was feasible?