The Transcoder API converts video files into the formats and qualities that viewers’ devices can play.

The problem of too many devices

A video recorded on a camera is usually very large and stored in a format meant for editing, not for watching online. Viewers, meanwhile, use countless devices: a new phone on fast home internet, an old tablet on a weak mobile signal, a smart television, a laptop browser. Each device supports different video formats and different sizes, and each connection can carry a different amount of data per second. Sending the original file to everyone would make videos stall, fail to play or burn through data plans.

What transcoding means

Transcoding is the process of converting video and audio from one digital form to another. It can change the codec, which is the method used to compress the video. It can change the resolution, which is the number of pixels in the picture. It can change the bitrate, which is how much data is used per second of video. It can also change the container, which is the wrapper that holds picture, sound and extra information together. A transcoder produces the right versions for each viewer.

What the service does

The Transcoder API is a managed service that performs transcoding for you in Google Cloud. You upload a video to Cloud Storage, describe the outputs you want, and submit a job. Google runs the heavy computation on its own machines, and puts the finished files back into Cloud Storage. You do not buy servers, install encoding software or manage scaling. It exposes a REST and RPC interface for submitting, monitoring and managing jobs.

A short tour of the words that every video engineer uses.

How one video can play well on a fast fibre line and on a weak mobile signal.

Internet speed changes second by second, especially on phones. If a video were encoded at only one quality, a slow connection would stall while a fast connection would waste its potential. Adaptive bitrate streaming solves this. The video is prepared in several qualities, each cut into short segments. The player watches how quickly segments arrive and switches to a higher or lower quality as conditions change, often without the viewer noticing.

The ladder

The set of qualities, each with its own resolution, bitrate and codec, is called the adaptive bitrate ladder, or ABR ladder. Each rung is a version of the video. Streaming companies tune their ladders based on the cost of delivering data, the types of devices that their viewers use, and typical bandwidth in the regions they serve. A small ladder is cheaper to produce and store, and a rich ladder gives smoother playback for more viewers.

flowchart TD
SRC["Master video file"] --> L1["Rung 1: 240p, low bitrate"]
SRC --> L2["Rung 2: 360p"]
SRC --> L3["Rung 3: 480p"]
SRC --> L4["Rung 4: 720p"]
SRC --> L5["Rung 5: 1080p, high bitrate"]
L1 --> MAN["Manifest lists all rungs"]
L2 --> MAN
L3 --> MAN
L4 --> MAN
L5 --> MAN
MAN --> PL["Player picks and switches rungs"]
        

The three output styles the service can produce, and when each is used.

One job, several outputs

A single transcoding job can produce several outputs at once. For example, it can write an HLS playlist with its segments, a DASH manifest that reuses the same segments, and a standalone MP4 file for downloads. Writing the segments once and referencing them from both manifests saves processing time and storage.

How a job moves from your upload to finished files.

The Transcoder API is built around the job, which is the basic unit of work. When you submit a job, it is processed asynchronously, meaning your application does not wait. The job runs in a chosen region, and you can list and manage all jobs for a region. Inputs and outputs live in Cloud Storage. The lifecycle of a job has three steps: prepare, transcode and package.

flowchart LR
UP["Upload source to Cloud Storage"] --> SUB["Submit job"]
SUB --> PRE["Prepare: download, analyze, validate"]
PRE --> TRA["Transcode: encode streams"]
TRA --> PKG["Package: stitch, multiplex, upload"]
PKG --> OUT["Outputs in Cloud Storage"]
PKG --> NOT["Notification to Pub/Sub"]
        

The pieces you combine to tell the service exactly what to produce.

A job configuration is the full description of the work. It has a few main parts that fit together like building blocks. Understanding these parts makes the whole service easy to reason about, even without seeing any code.

flowchart TD
JC["Job configuration"] --> IN["Inputs: source files in Cloud Storage"]
JC --> ES["Elementary streams: video, audio, text tracks"]
JC --> MS["Mux streams: containers that hold the tracks"]
JC --> MF["Manifests: playlists listing the mux streams"]
JC --> OUT["Output: where files are written"]
JC --> EX["Extras: overlays, ad breaks, sprite sheets, edit list"]
JC --> NT["Notifications: Pub/Sub destination"]
        

Reusable recipes, so you do not describe the same ladder for every video.

A job template is a saved job configuration that can be reused in a region. Instead of listing every stream and manifest each time, you submit a job with the name of a template, plus the input and output locations. This keeps your encoding rules in one place, makes them easy to change and ensures every video is treated the same.

Preset templates

The service provides preset templates for common needs. By default, if you submit a job without a configuration, a preset is applied that produces a standard web-friendly output, including an HLS playlist, DASH-style segments and downloadable files in standard and high definition. Presets are a quick way to start and to learn what a typical job looks like.

Your own templates

For your own ladder, create custom templates. A news site may have a template tuned for short clips, while a film service has another for long, high quality titles with several audio languages. Changing a template changes what future jobs produce, without touching the applications that submit them.

The knobs that trade picture quality against file size and device support.

Choosing a codec and its settings is the heart of encoding. H.264, also called AVC, is supported by almost every device and is the safe default. Newer codecs such as H.265, also called HEVC, and VP9 can deliver similar quality at lower bitrates, saving bandwidth, but support varies by device and they take more effort to encode. The right choice depends on your audience and your delivery costs.

Preprocessing

Before encoding, the service can improve the picture and sound. It can reduce noise and blocky artifacts, crop or pad the frame, convert interlaced video to progressive, and adjust color. For audio it can normalize loudness to a target level, so that viewers do not have to change the volume between videos.

Video is half picture and half sound, and global audiences need more than one voice.

A job can include several audio tracks, for example different languages or a stereo and a surround mix. Each audio track is its own elementary stream, with a codec, bitrate and channel layout. These streams are multiplexed into the output containers and listed in the manifests, so a player can offer a language menu. Audio-only outputs are also possible, for podcasts, radio style content or the lowest rung of a ladder when bandwidth is very poor.

Mixing and remixing

The edit list and audio mapping let you combine inputs. You can take video from one file and audio from another, join several clips into one, or trim the beginning and end. This is useful when audio is recorded separately, or when you assemble a final program from several parts.

Loudness

Different videos are recorded at different volumes. Loudness normalization adjusts audio to a standard level, making a calm documentary and a loud action trailer feel consistent. It improves the experience, especially on mobile devices and for playlists of mixed content.

Extra features that turn plain conversion into a ready-to-publish product.

About ad markers

It is important to understand what the service does and does not do with advertising. The Transcoder API can place ad break markers in the output so that downstream tools know where breaks may go. It does not insert, play or manage the advertisements, and it does not stop playback. The video player or an ad insertion service handles the actual ads.

About encryption

For protected content, the service supports encryption for common streaming and rights systems. Supported combinations depend on the format and container, with examples including HLS with sample-level encryption for FairPlay, and DASH with systems such as Widevine and PlayReady. You provide the key and license information, and the service encrypts the output accordingly. Check the current documentation for the exact combinations.

flowchart LR
V["Source video"] --> TR["Transcoder API"]
LG["Logo image"] --> TR
TR --> ST["Segments with logo overlay"]
TR --> SP["Sprite sheet for scrub previews"]
TR --> MF["Manifest with ad break tags"]
MF --> AD["Ad insertion service decides ads"]
        

Choosing between speed and volume, and knowing the boundaries.

Interactive and batch modes

Jobs run in one of two modes. Interactive mode is the default, and processing starts as soon as possible, which suits user uploads where a viewer is waiting. In this mode a quota controls how many jobs may run at the same time, and when that quota is reached, new jobs are rejected. Batch mode suits large volumes of work where delay is acceptable, such as processing a back catalog. In batch mode jobs wait in a queue in the pending state, ordered first in and first out within the same priority, and you can set a priority for each job. Both modes can be used at once, and neither has priority over the other.

Job limits

Each job has limits. Input and output sizes are capped, with a maximum input of 4096 by 4096 pixels and a maximum output width of 4096 pixels and height of 2160 pixels. There are limits on the total output size, the length of the edit list and the number of streams, manifests and sprite sheets per job. These are generous for ordinary use, but check the current limits table, and plan separate jobs for extremely large or complex work.

How the Transcoder API fits with other Google Cloud services in a real platform.

On its own, the Transcoder API only converts files. A full video platform needs storage, triggers, delivery and monitoring around it. A common design uses Cloud Storage for uploads and outputs, an event to start the job automatically, Pub/Sub to learn when it finishes, and a content delivery network to serve segments to viewers at speed.

flowchart TD
USR["User uploads video"] --> RAW["Cloud Storage: raw uploads"]
RAW --> EVT["Storage event triggers a function or service"]
EVT --> JOB["Submit Transcoder job with template"]
JOB --> OUT["Cloud Storage: transcoded outputs"]
JOB --> PS["Pub/Sub: job finished message"]
PS --> DB["Update video catalog: ready to play"]
OUT --> CDN["Content delivery network"]
CDN --> VW["Viewers on phones, browsers and televisions"]
        

Videos are valuable assets, so protect them from upload to playback.

Access control

The Transcoder API uses identity and access management. Roles decide who may create jobs and templates, view them or administer them. The service itself needs permission to read your input bucket and write to your output bucket, which you grant to the service identity that runs jobs. Keep input and output buckets separate, give the service only the access it needs to each, and restrict who can write to the output bucket that viewers read from.

Protecting the media

Raw masters are often the most valuable files, so store them in private buckets with tight access and retention rules. Outputs delivered to viewers can be protected with signed addresses or signed cookies at the delivery layer, so that only authorized viewers can fetch segments. For premium content, use encryption with rights management support so that copies of segments are useless without a license.

A video that never becomes playable is a silent failure, so watch your jobs.

Every job reports its state, and failures include an error description. The most reliable way to follow jobs is through Pub/Sub notifications. Configure a destination topic in the job or template, and a message arrives when the job ends, so your platform can update the catalog automatically, retry or alert a person. You can also list jobs in a region and check their states, and use logs and metrics in Cloud Monitoring to track volume, failures and processing time.

You pay for minutes of video processed, and the format and quality you ask for decide the rate.

The Transcoder API is priced by the amount of video processed, measured in minutes, with rates that depend on resolution tier and on the codec and features used. Standard definition work with a common codec costs less, and high definition, ultra high definition and newer codecs cost more. A small monthly free allowance has been offered for trying the service. Rates differ by region and can change, so use the official pricing page and calculator for current numbers.

Remember the other costs of a video platform. Cloud Storage holds sources and every rendition, so a rich ladder multiplies storage. Delivering video to viewers is often the largest cost of all, through network egress or a delivery network. Functions, events and notifications add small charges.

Where automatic transcoding quietly makes video work.

These are common patterns rather than named customer stories, because specific designs change over time.

A managed encoder removes heavy work, and asks for design choices in return.

Habits that make video platforms smooth, and habits that cause buffering and bills.

Patterns that work

Strong teams define a small set of templates for their content types. They keep raw masters and outputs in separate buckets with different rules. They trigger jobs from events and track completion with Pub/Sub, rather than polling. They validate uploads before spending processing money. They tune ladders using real viewing data. They test outputs on real devices, and they apply lifecycle rules to storage, so that old or rarely watched renditions do not linger forever.

A checklist to keep your video pipeline fast, reliable and affordable.

Mistakes beginners make most often

The first is publishing only one quality. The second is leaving output buckets public. The third is polling for status instead of using notifications. The fourth is starting jobs on partial uploads. The fifth is forgetting audio loudness and ending up with wildly different volumes. The sixth is testing on only one player. The seventh is keeping every rendition forever.

Several ways exist to process video, and each suits a different job.

flowchart TD
Q1{"Is the video live as it happens?"} -->|Yes| LS["Live Stream API"]
Q1 -->|No| Q2{"Need standard formats with minimal operations?"}
Q2 -->|Yes| TC["Transcoder API"]
Q2 -->|No| Q3{"Need special codecs or fine control?"}
Q3 -->|Yes| SM["Self-managed encoding"]
Q3 -->|No| TC
TC --> Q4{"Need ads inserted per viewer?"}
Q4 -->|Yes| VS["Add Video Stitcher API"]
        

These services are often combined. A platform may use the Transcoder API for its library, the Live Stream API for events, the Video Stitcher API for advertising, and a delivery network to reach viewers.

It is a managed Google Cloud service that converts video files stored in Cloud Storage into streaming and download formats at several qualities, and writes the results back to Cloud Storage.

No. It works on stored files. For live streams, use the Live Stream API, which is built for real-time processing.

MP4 files, HLS and MPEG-DASH streaming outputs, including audio-only versions and multiple bitrates and resolutions from the same job.

A saved job configuration that you reuse by name. Instead of describing every stream each time, you submit a job with a template plus input and output locations.

Interactive mode starts jobs as soon as possible and is the default, and batch mode queues jobs with priorities for work that is not urgent. Each has its own quotas.

No. It can add ad break markers to manifests, but inserting and playing ads is the job of the player or an ad insertion service.

Yes, using image overlays that you position and time. It can also produce sprite sheets for preview thumbnails and normalize audio loudness.

Configure a Pub/Sub destination on the job or template. A message is published when the job ends, so your systems can react without polling.

Yes. The service supports encryption for common streaming formats and rights management systems, and you should also use private buckets and signed delivery.

Yes. There are limits on input and output resolution, total output size, the number of streams and manifests, and the number of concurrent jobs. Check the current limits and quotas for your needs.

By minutes of video processed, with rates that depend on resolution tier, codec and features, and a small free allowance. Storage and delivery are billed separately. Check the official pricing page for current rates.

For serving many viewers, yes. The Transcoder API only prepares the files. A delivery network caches and serves them quickly and cost effectively to viewers around the world.

The Transcoder API is Google Cloud’s managed service for turning source video files into streaming-ready outputs. You upload a master to Cloud Storage, submit a job that describes elementary streams, containers and manifests, and the service prepares, transcodes and packages the result back into Cloud Storage. Adaptive bitrate ladders let every viewer get a quality that suits their device and connection, templates keep encoding consistent, and extras such as overlays, sprite sheets, ad markers and encryption make outputs ready to publish. Success comes from a well-tuned ladder, event driven automation, notification based tracking, protected storage and delivery, and careful control of cost across processing, storage and delivery.