Use case · Streaming & media
Video transcoding
Video transcoding converts video into different formats, resolutions, and bitrates — the compute-intensive step behind adaptive streaming. It is far faster and more efficient on GPUs than CPUs, and can run in batch for on-demand content or in real time for live. Dedicated GPU-accelerated infrastructure handles transcoding at scale; EU hosting keeps the content sovereign.
Key points
- Video transcoding converts video into different formats, resolutions, and bitrates.
- It's compute-intensive, decoding and re-encoding video.
- GPUs transcode far faster and more efficiently than CPUs, and handle many streams.
- It runs in batch for on-demand libraries or in real time for live streaming.
- Dedicated GPU-accelerated infrastructure in the EU handles transcoding at scale, sovereignly.
What is video transcoding, and why does it matter?
Video transcoding is the process of converting video from one encoding to another — changing its format, codec, resolution, or bitrate — and it is the compute-intensive step that makes adaptive streaming possible. Streaming video to viewers on different devices and connections requires the video in various formats and qualities, and transcoding produces these from a source video, converting it into the versions streaming needs. Whether preparing an on-demand library or processing a live stream, transcoding is what turns source video into the formats and qualities that will be delivered to viewers, so it underlies video streaming of all kinds.
Transcoding matters because it is both necessary and demanding: necessary because streaming needs video in multiple formats and qualities, and demanding because converting video takes substantial compute. The quality, efficiency, and speed of transcoding affect the streaming that depends on it — how the video looks, how much bandwidth it needs, and how quickly it can be prepared or kept up with live. This page focuses on transcoding as a workload and its infrastructure; the streaming that uses it is covered on the video, live, and on-demand streaming pages, while what follows attends to what transcoding is and what it needs to run well.
Why transcoding is compute-intensive
Transcoding is computationally heavy because it involves decoding the source video and re-encoding it into the target format, both of which are demanding, especially the encoding. Decoding turns the compressed source video into raw frames, and encoding compresses those frames into the target format, and encoding in particular is intensive, since compressing video well involves substantial computation to analyse and represent the frames efficiently. Doing this for the many frames of a video, and often into multiple output versions, adds up to significant compute, which is why transcoding is one of the more demanding media workloads.
The compute needed grows with the resolution, the number of output versions, and the codec used, so transcoding high-resolution video into many qualities with an efficient codec is especially heavy. Higher resolutions have more data to process; producing multiple qualities multiplies the work; and more efficient codecs, which compress better, take more compute to encode. This is why transcoding at scale — a large library, or many live streams — needs serious compute, and why the choice of how to provide that compute, particularly using GPUs, matters so much, as the next section describes. The demands of transcoding make the infrastructure for it a real consideration.
CPU versus GPU transcoding
Transcoding can be done on CPUs or accelerated by GPUs, and GPUs transcode video far faster and more efficiently, which makes them central to transcoding at scale. Modern GPUs include dedicated hardware for encoding and decoding video, which processes video much faster than doing the same work on a CPU, and lets many video streams be transcoded on a single GPU. This makes GPU-accelerated transcoding dramatically more efficient for the work, so that transcoding large volumes — a big library, or many concurrent live streams — is far more practical and economical on GPUs than on CPUs alone.
For transcoding at any scale, GPU acceleration is usually the right approach, given how much more it does per unit of hardware. CPU transcoding can produce high quality and suits smaller volumes or particular needs, but for the throughput transcoding at scale requires, GPUs' dedicated video hardware is far more efficient, handling many streams where CPUs would need far more hardware. We provide GPU-accelerated infrastructure for video transcoding — GPUs with the hardware encoding and decoding transcoding uses — so that transcoding runs efficiently and at scale, whether preparing a large library or keeping up with many live streams, which is where the efficiency of GPU transcoding makes the most difference.
Codecs and formats
Transcoding produces video in particular codecs — the standards for encoding video — and the choice of codec involves a trade-off between compression efficiency, compute cost, and compatibility. Widely-compatible codecs are supported almost everywhere but compress less efficiently; newer codecs compress better, reducing the bandwidth video needs, but take more compute to encode and may be less universally supported. So transcoding often targets more than one codec, balancing reaching all devices against the bandwidth savings better codecs give, and the codec choice affects both the compute transcoding needs and the bandwidth the resulting video uses.
The more efficient codecs, which save bandwidth, are more demanding to encode, which ties back to the compute transcoding needs. A codec that compresses video better reduces delivery bandwidth — valuable given that bandwidth is streaming's main cost — but takes more transcoding compute to produce, so there is a trade-off between transcoding cost and delivery cost. GPU acceleration helps make encoding the more efficient codecs practical at scale. We provide the compute transcoding to various codecs needs, including GPU acceleration for the more demanding ones, so that a streaming service can transcode into the codecs that balance compatibility and bandwidth for its needs, with the infrastructure to encode them efficiently.
The adaptive bitrate ladder
A central task of transcoding for streaming is producing the adaptive bitrate ladder — the set of quality levels a video is offered in, from which the viewer's player picks based on their connection. Adaptive streaming relies on each video being available in several bitrates and resolutions, so that viewers on fast connections get high quality and those on slow connections get lower quality without buffering; transcoding produces these several versions from the source. Creating this ladder means transcoding each source into multiple outputs, which multiplies the transcoding work compared to producing a single version.
Producing the ladder is much of why transcoding is heavy, since each source becomes several outputs, each needing encoding. A video offered in several quality levels requires transcoding the source into each, so the transcoding compute for one video is several times that of a single encode, and for a library or many live streams this multiplies further. The ladder's design — how many levels, at what qualities — affects both the transcoding work and the viewer experience. We provide the compute to produce the adaptive bitrate ladders streaming uses, transcoding each source into its multiple qualities, so that a streaming service has the versions adaptive delivery needs, with infrastructure sized for the multiplied work producing the ladder involves.
Batch versus real-time transcoding
Transcoding runs in two modes — batch and real-time — which place different demands on the infrastructure, matching the on-demand and live streaming they serve. Batch transcoding processes stored video ahead of time, preparing an on-demand library into its qualities without time pressure, so it can be scheduled and run when convenient, needing throughput to get through the volume. Real-time transcoding processes a live stream as it flows, and must keep pace with real time, since falling behind would delay or break the live stream, so it needs enough capacity to keep up continuously. The mode follows the streaming: batch for on-demand, real-time for live.
The infrastructure implications differ: batch transcoding can use capacity as available and be scheduled, favouring throughput; real-time transcoding must have the capacity to keep up with each live stream at all times, favouring guaranteed, responsive capacity. A service doing both needs to provide for each. We provide infrastructure for both batch and real-time transcoding — throughput for preparing on-demand libraries, and the guaranteed, GPU-accelerated capacity real-time live transcoding needs to keep pace — so that a streaming service's transcoding is served whether it is preparing content ahead of time or processing live streams as they happen, each with the infrastructure its mode requires.
Scaling transcoding, sovereignty, and where we fit
Transcoding at scale — a large library or many live streams — is done across multiple GPUs or servers, effectively a transcoding farm, sized to the volume of work. As the transcoding volume grows, more GPU capacity is added to handle it, so large-scale transcoding runs across many GPUs, together processing the library or the concurrent live streams. The infrastructure scales by adding GPU capacity to match the transcoding volume, whether that is a growing on-demand library to prepare or a rising number of live streams to keep up with. Sizing this to the real transcoding volume is how transcoding is provided economically at scale.
The content transcoded may be valuable or licensed, so sovereignty applies. VV Internet Hosting is incorporated in the Netherlands, within the EU, so transcoding infrastructure hosted with us runs under European jurisdiction and outside the direct reach of the US CLOUD Act, keeping the content under European law. We host GPU-accelerated dedicated infrastructure for video transcoding — the GPUs whose hardware encoding and decoding transcoding uses, scaled to the volume, for batch or real-time work — in EU datacenters under European jurisdiction. This suits streaming services and media operations that want efficient, scalable, sovereign transcoding they control. We are clear about our limits: we provide the transcoding infrastructure, not a managed transcoding service. We are the dedicated, sovereign, GPU-accelerated infrastructure for video transcoding — and if that fits your needs, we can host it well.
Related use cases
See also
Questions
Video transcoding, answered plainly
Common questions about hosting for Video transcoding.
What is video transcoding?
Converting video from one encoding to another — changing its format, codec, resolution, or bitrate. It's the compute-intensive step that makes adaptive streaming possible, producing the various formats and qualities streaming needs from a source video. Whether preparing an on-demand library or processing a live stream, transcoding turns source video into the versions delivered to viewers.
Why use GPUs for transcoding instead of CPUs?
Modern GPUs include dedicated hardware for encoding and decoding video, which processes video far faster than a CPU and lets many streams be transcoded on a single GPU. This makes GPU-accelerated transcoding dramatically more efficient, so transcoding large volumes — a big library or many live streams — is far more practical and economical on GPUs than on CPUs alone.
What's the difference between batch and real-time transcoding?
Batch transcoding processes stored video ahead of time — preparing an on-demand library into its qualities without time pressure, so it can be scheduled. Real-time transcoding processes a live stream as it flows and must keep pace with real time, since falling behind would break the stream. Batch favours throughput; real-time needs guaranteed, responsive capacity.
Planning Video transcoding infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.