A managed Google Cloud service that converts stored video files into new formats, sizes and streaming packages.

The Short Definition

The Transcoder API is a service you reach through a standard web interface, using either REST or RPC calls, to submit, watch and manage video conversion jobs. You place a source video in Cloud Storage, tell the service what you want, and it writes the converted results back into Cloud Storage. You never create virtual machines, install conversion software or manage queues of work.

Two words matter here. Transcoding means converting video from one digital form to another, for example changing its compression method, its picture size or its container. Managed means Google runs the machines and scales them, so your job is only to describe the result you want.

What It Is Used For

The service is built for file-based video, meaning videos that already exist as files. Typical uses include preparing uploaded videos for a streaming website, creating several quality levels for adaptive playback, producing small preview clips and thumbnail images, adding a logo or caption track, protecting content with encryption, and creating audio-only versions of a recording.

An Important Caution About Timing

Processing is asynchronous. That means you submit a job and come back later for the result; there is no strong promise about how long a job will take. For this reason the service is not suited to situations where a person is staring at a screen waiting for the converted file. It fits best in background workflows where a video is uploaded now and becomes ready to watch after a short while.

The hidden reasons a raw video file almost never plays well straight from the camera.

Devices and Networks Are All Different

A video recorded on a professional camera can be enormous. It may have a very large picture, a very high data rate and a compression method that only editing software understands. Playing it directly on a phone over a mobile network would stutter or fail. Viewers use televisions, tablets, old laptops and new phones, each supporting different compression methods and different connection speeds.

Three Problems One File Cannot Solve

The Do-It-Yourself Burden

Before managed services, teams installed open-source conversion tools on their own machines. That works for a few videos. At scale you must build a queue, scale machines up for busy days and down for quiet ones, handle crashes halfway through long conversions, patch the software and watch costs. Each task is solvable, yet together they become a full-time platform to maintain. A managed transcoding service removes that burden so the team can focus on the product that uses the video.

Ten terms that appear in every Transcoder API conversation, each explained from scratch.

Video technology has a lot of jargon. The good news is that you only need a handful of ideas to understand this service. For each term below, notice three things: what it is, why it exists and where you will meet it.

Container Versus Codec

Beginners often mix these two. A file ending in the MP4 name only tells you the box. Inside, the video might be compressed with H.264 or H.265. Two MP4 files can behave very differently on the same phone. Whenever something fails to play, ask two separate questions: does the device understand the container, and does it understand the codecs inside?

The moving parts between an uploaded video and the finished files.

The Big Picture

The service sits between two Cloud Storage locations. On one side is an input location holding your source video. On the other is an output location where finished files appear. In between is the control plane, which receives job requests, keeps their status and orchestrates the conversion on Google-managed machines.

flowchart LR
    A["Source video in Cloud Storage"] --> B["Job request via REST or RPC"]
    B --> C["Transcoder API control plane"]
    C --> D["Prepare: download, analyze, validate"]
    D --> E["Transcode: encode video and audio"]
    E --> F["Package: mux, manifests, upload"]
    F --> G["Output files in Cloud Storage"]
    C --> H["Job status and errors"]
    C --> I["Optional notifications"]
        

Read the diagram from left to right. Your request describes inputs, streams, containers and manifests. The control plane accepts it and runs three internal stages. First comes preparation, where the file is downloaded, analyzed and validated. Then comes transcoding, where video and audio are encoded. Finally comes packaging, where streams are stitched together, containers and manifests are created and outputs are uploaded.

Key Components Explained

What the service can read, and what it can produce.

One of the most practical questions is simple: will my file work? The service accepts a wide variety of input types and produces a focused set of widely playable outputs. The official documentation page on supported formats is the final authority, since lists can grow over time, but the tables below give a reliable mental map.

What You Can Feed In

What You Can Produce

Why Output Is Narrower Than Input

The service aims to produce formats that nearly every modern player understands. It is easier to accept many strange inputs, because decoding is a one-time conversion, than to promise many outputs, because each output format needs ongoing support and testing. In practice, the three video codecs on the output side cover the vast majority of web and mobile playback needs.

From submitting a request to finding finished files, step by step.

Before You Start

You need a Google Cloud project with the API enabled, a bucket for inputs, a place for outputs and permission to create jobs. When you create your first job, Google creates a service agent for your project. This can take a few minutes, so a brief permission error right after first use is normal and usually clears if you wait and try again.

The Journey

sequenceDiagram
    participant U as Your Application
    participant S as Cloud Storage
    participant T as Transcoder API
    participant A as Service Agent
    U->>S: Upload source video
    U->>T: Create job with input, output, config
    T-->>U: Job accepted, state pending
    T->>A: Use agent identity
    A->>S: Read source video
    T->>T: Prepare, transcode, package
    A->>S: Write outputs and manifests
    U->>T: Get job status
    T-->>U: Succeeded or error details
        

The sequence shows that your application never moves the video bytes itself. It only sends instructions and checks results. The heavy lifting happens between the service agent and Cloud Storage. This is why a missing storage permission is among the most common reasons a job fails.

Reusable recipes that save time and prevent mistakes.

The Default Preset

If you create a job without naming any template, the service uses a built-in preset called preset/web-hd. It expects an input with at least one video track and one audio track. In return it produces two H.264 video renditions, one at 640 by 360 and one at 1280 by 720, an AAC audio stream, and both HLS and DASH playlists. Standalone SD and HD MP4 files are also part of this default result.

This preset is a convenient first step. With one short request you receive a working streaming package. Many teams start here and only later graduate to custom recipes.

Custom Job Templates

A custom template is a configuration saved in a specific region under a name you choose. When you create a job in that region, you refer to the template by its identifier instead of repeating dozens of settings. Templates make results consistent across thousands of jobs and make changes manageable: update the template recipe in one place and future jobs follow it.

Template Versus Ad-hoc Configuration

The five building blocks inside every custom job recipe.

When you do not use a template, you send a configuration object. It may look long, yet it is made of only a few pieces, and they fit together logically. Learn the pieces once and every configuration becomes readable.

flowchart TD
    I["Inputs"] --> V1["Video stream 360p"]
    I --> V2["Video stream 720p"]
    I --> A1["Audio stream AAC"]
    V1 --> M1["Mux stream: segments for 360p"]
    V2 --> M2["Mux stream: segments for 720p"]
    A1 --> M3["Mux stream: audio segments"]
    M1 --> H["HLS manifest"]
    M2 --> H
    M3 --> H
    M1 --> D["DASH manifest"]
    M2 --> D
    M3 --> D
    H --> O["Output location"]
    D --> O
        

How the Pieces Reference Each Other

Each block gives its items a key, and later blocks refer to earlier items by key. A mux stream lists the keys of the elementary streams it packages. A manifest lists the keys of the mux streams it describes. This is exactly like a table of contents that refers to chapter names. If a key is misspelled or missing, the job fails with a clear validation message, so errors are easy to find once you know to look for mismatched names.

One Encoding, Many Packages

A beautiful property of this design is that encoding and packaging are separate. You can encode a video stream once and include it in both an HLS playlist and a DASH playlist. Because those playlists reuse the same encoded streams, you do not pay again for encoding the video twice, and storage stays efficient.

How one video can adjust itself to every viewer’s connection, second by second.

The Idea in Plain Words

When you watch a streaming video on a phone and walk from a strong Wi-Fi area into a weak mobile area, the picture often becomes a bit blurry and then sharp again, without stopping. That is adaptive bitrate streaming. The video exists in several versions, and the player quietly switches between them depending on how fast data is arriving.

The collection of versions is called the ladder, because each rung is a step up in size and quality. Your job when designing a ladder is to pick the rungs, and the Transcoder API’s job is to produce them and list them in a manifest.

Designing Rungs

A ladder usually contains a few resolutions with matching bitrates. The default web preset has two rungs: a small one and a high-definition one. Larger services add more rungs to serve very weak connections and very large screens. More rungs give smoother switching but cost more to produce and store, because each video rendition is billed and stored separately.

Why Aspect Ratio and Size Limits Matter

Each job has maximum input and output dimensions, including an output width of 4096 pixels and an output height of 2160 pixels. A rung also should keep the picture’s original shape, otherwise people look stretched or squashed. The service offers options to preserve aspect ratio, crop or pad with black bars when the target shape differs from the source.

flowchart LR
    SRC["One source video"] --> E1["Encode 360p rung"]
    SRC --> E2["Encode 720p rung"]
    SRC --> E3["Encode 1080p rung"]
    E1 --> MF["Manifest lists all rungs"]
    E2 --> MF
    E3 --> MF
    MF --> PL["Player switches rung by network speed"]
        

How the encoder decides how much data to spend on each moment of video.

Why Rate Control Exists

Video scenes differ. A talking head against a plain wall needs little data to look good, while a football match with fast motion and green grass needs much more. The encoder must decide how to spend data across the whole video, and the strategy it uses is called rate control.

Practical Quality Decisions

Higher bitrate does not always look better to a viewer. Beyond a point, extra data brings little visible improvement while costing more to store and deliver. Test a few settings on representative content, such as a dark movie scene, a sports clip and a screen recording, and compare them side by side on real devices. Decisions made by eye on real samples beat any rule of thumb.

Frame Rate and Other Controls

You can influence frame rate, which is how many pictures appear each second, including exact output frame rate settings. Matching the source frame rate generally avoids jerky motion. Other controls include codec profile choices, keyframe spacing that affects how quickly viewers can jump around a video, and options such as deinterlacing, which cleans up older footage that was recorded in an interlaced style.

Shaping the picture and the timeline without opening a video editor.

Edit Lists: A Timeline Recipe

An edit list describes how pieces of input files are placed on an output timeline. With it you can trim a clip, take only the middle part of a long recording, or join pieces from several inputs into one finished video. Because the outcome is described by instructions, the original files remain untouched. The total duration of an edit list is limited to twenty-four hours.

Concatenation

Joining several videos into one is a common need, such as adding an intro and an outro to every upload. By listing multiple inputs and placing them in sequence on the edit list, the service produces a single continuous output. Plan to use matching shapes and frame rates where possible so transitions look natural.

Overlays

Overlays place an image on top of the video. A typical use is a logo in a corner. Image overlays support transparent backgrounds with PNG files, and can be shown for a chosen period or animated in simple ways. Overlays are rendered into the picture permanently in that output, so every viewer sees them and they cannot be turned off.

Cropping, Padding and Aspect Ratio

Deinterlacing and Gaps

Older broadcast footage is sometimes interlaced, a technique that draws alternate lines in each pass. Modern screens look better with progressive pictures, so deinterlacing options clean this up. For videos with many missing frames, a content-gap filling option can help produce smoother results.

Sound deserves as much care as the picture, and viewers notice bad audio faster.

Audio Streams

Audio is produced as its own elementary stream, with its own codec, bitrate, channel layout and sample rate. The service supports popular output codecs such as AAC variants, AC3, E-AC3, MP3 and Vorbis. A stereo AAC track is the most widely playable choice for general web use.

Loudness Normalization

Different videos are recorded at different volumes. Without correction, a viewer moving between two clips may jump to adjust the volume every time. Loudness normalization adjusts audio toward a consistent perceived level, so a whole library feels uniform. This is especially valuable for platforms built from many different uploaders.

Audio-Only Outputs

Not every use needs a picture. The service can produce audio-only outputs, including standalone MP3 and OGG Vorbis files. This is useful for podcast versions of video content, voice-only previews and accessibility products. Audio-only output is billed at its own, lower per-minute rate.

Languages and Labels

Streams can carry language codes and display names. This lets a player show choices such as different spoken languages, and helps a manifest describe which audio track belongs to which language. Correct labeling is small work that makes a large difference for international audiences.

Making video understandable to people who cannot hear it, or who speak another language.

Why Captions Matter

Captions help viewers who are deaf or hard of hearing, people watching in noisy places, and people watching with the sound off, which is very common on phones. Subtitles help viewers who do not speak the video’s language. Together they widen your audience and, in many places, support legal accessibility requirements.

What the Service Accepts and Produces

Caption and subtitle files in common text formats such as SRT, VTT and SCC can be supplied as inputs and mapped into the output. Output can include embedded caption formats suited to broadcast-style players, and WebVTT for web players. Standalone VTT outputs are also available when you want caption files separate from the video.

Automatically Generated Subtitles

The service can generate subtitles automatically from speech, which is a major time saver for large libraries. Generated subtitles are billed per minute for each subtitle track, so decide which languages truly add value. As with any automatic transcript, review important content for accuracy, especially names, technical terms and sensitive material.

The small extras that make a video player feel professional.

Thumbnails and Posters

A thumbnail is a small still image that represents a video in a list, and a poster is the image shown before playback starts. The service can extract single images or tiles of images as JPG files from moments you choose. Good thumbnails strongly influence whether people click, so many teams generate several candidates and pick the best one.

Sprite Sheets

When you drag the progress bar of a player and see tiny preview pictures, those previews usually come from a sprite sheet. A sprite sheet is one large image made of many small frames taken at regular intervals. The player cuts out the right small frame as you drag. Sprite sheets support aspect-ratio preservation and quality settings, and one job can create several of them, up to a documented limit.

Ad Break Keyframes

Platforms that show advertisements need to start ads at exact moments, and that is only clean when a keyframe sits at that moment. The service can insert keyframes at chosen times so that ad insertion systems can splice cleanly without visible glitches. It also supports signaling used in broadcast workflows. Marking ad break positions during transcoding keeps later ad insertion simple and reliable.

Keeping paid or private video from being freely copied.

The Problem

Premium movies, paid courses and private corporate videos should not be downloadable and shareable by anyone who finds a link. Encryption scrambles the video so that only players holding the right key can unscramble and show it.

What the Service Supports

The service supports content encryption for streaming outputs, including common approaches used by major digital rights management systems and standard encryption schemes for both transport-stream and fragmented MP4 packaging. These let you integrate with widely used playback ecosystems on phones, browsers and televisions.

Two Halves of the Solution

Compatibility Planning

Different devices favor different protection systems. A broad audience often needs more than one scheme packaged together. Test on every target device family, because a protected stream that plays on a laptop might refuse to start on a particular television.

Two ways to run jobs, designed for two different business needs.

Interactive Mode

Interactive is the default. Jobs start as soon as capacity allows, which suits situations where results are wanted soon after upload. A limit applies to how many interactive jobs can run at once in a region, and requests beyond that limit are rejected rather than queued.

Batch Mode

Batch mode is for large volumes where speed matters less than steady throughput, such as converting an entire back catalog. Jobs wait in a pending queue and are processed in first-in, first-out order within the same priority. You can assign priorities so important jobs move ahead. Separate limits apply to how many batch jobs can run at once and how many can wait in the queue.

flowchart TD
    N["New video upload"] --> I["Interactive job: start as soon as possible"]
    L["Large back catalog"] --> Q["Batch jobs wait in pending queue"]
    Q --> P["Higher priority first, then first-in first-out"]
    I --> R["Results in Cloud Storage"]
    P --> R
        

Where jobs run, and why the place of your files matters.

Jobs Belong to a Region

Every job runs in a specific Google Cloud region that you choose when you create it. You list and manage jobs within that region, and job templates are also stored per region. The service is offered in around twenty regions across the Americas, Europe and Asia, and the official list is the place to confirm the current set.

Keep Data and Compute Close

Video files are large, and moving large files across long distances takes time and may cost money. A sensible habit is to keep the source bucket, the output bucket and the job region in the same geographic area. This usually gives faster processing, lower network charges and a simpler story when you must prove where data lives.

Output Folders and Naming

The output folder does not need to exist beforehand. The service creates object names that include the folder you specify. Establish a naming convention early, such as one folder per video identifier, so that finding, serving and deleting outputs for any video is straightforward.

flowchart LR
    SB["Source bucket"] --> J["Job in chosen region"]
    J --> OB["Output bucket"]
    OB --> CDN["Delivery network"]
    CDN --> V["Viewers"]
    LC["Lifecycle rules"] --> OB
        

Who can submit jobs, and which identity actually touches your video files.

Two Layers of Permission

Security around this service has two separate layers, and confusing them is the most common beginner mistake. The first layer decides who may create, view or delete jobs and templates. The second layer decides which storage the service itself may read from and write to while it works.

The Default Agent Access and Least Privilege

By default, the service agent can read and write files in all the storage buckets of the project and publish to all of its messaging topics. That is convenient for a first test but broader than many organizations want. To tighten this, remove the broad default role and grant the agent access only to the specific buckets it needs, plus publish access only on the specific topics used for notifications.

Protecting Source and Output Files

Treat source uploads as private. Original masters are valuable and often contain unreleased content. Keep source buckets closed to the public, let only trusted applications write to them, and deliver outputs to viewers through a controlled delivery layer rather than by making whole buckets public. Combine this with encryption for premium content.

Letting the rest of your system know the moment a video is ready.

Polling Versus Being Told

One way to learn that a job has finished is to ask repeatedly, “Are you done yet?” That wastes effort and adds delay. A better way is to be told. The service can publish job updates to a Pub/Sub topic, a messaging service where one part of a system posts messages and other parts receive them. Your application subscribes and reacts the moment a job finishes or fails.

A Typical Event-Driven Flow

sequenceDiagram
    participant C as Creator
    participant B as Source Bucket
    participant F as Trigger Function
    participant T as Transcoder API
    participant P as Pub/Sub Topic
    participant D as Video Database
    C->>B: Upload video
    B->>F: Object created event
    F->>T: Create job
    T->>T: Process video
    T->>P: Publish job finished
    P->>D: Subscriber marks video ready
        

Designing for Failure

Messages can arrive more than once, and jobs can fail. Make your subscriber idempotent, which means handling the same message twice without causing harm, for example by checking whether a video is already marked ready. Route failure messages to a place where a person or an automated retry step will see them. Never assume every upload leads to a successful output.

What you pay for, what you cannot exceed, and how to plan around both.

The Billing Idea

You are billed for each minute of output produced, not for each minute of input. If you feed in a thirty-minute recording but ask for a two-minute clip, you are billed for two minutes. Each video stream you produce is priced according to its resolution category, which are standard definition, high definition and ultra high definition, and higher categories cost more per minute. The cost of a job is the output duration multiplied by the combined rate of all the video streams you requested.

Costs Outside the Service

Quotas You Should Know

Limits protect the service and your budget. Request rates are limited per minute per region, with much higher allowance for reading job information than for creating or deleting jobs. Interactive mode limits how many jobs run at once in a region. Batch mode has its own concurrency limit and a much larger allowance for pending jobs waiting in the queue. All quotas apply to the whole project and are shared by every application using it. If you need more, you can request an adjustment through the console.

Limits Inside a Single Job

Knowing quickly when a job fails, and working out why.

What to Watch

A video that never becomes ready is a customer-facing failure, so observe the pipeline at several points: job state changes, error details on failed jobs, the arrival of expected output files, and the time between upload and readiness. A simple dashboard of how many jobs succeeded and failed each day reveals trends long before users complain.

Common Failure Causes

An honest look at where the service shines and where another tool fits better.

Neighboring Options

Habits that keep a video pipeline calm, and habits that make it brittle.

Patterns That Work

Anti-Patterns To Avoid

A practical checklist you can apply to your very next job.

Before Your First Job

After the First Job

Mistakes Seen Again and Again

Putting every idea from this guide into one coherent video platform design.

Let us combine everything into one design for a company that lets customers upload training videos and wants them to play smoothly on any device within minutes. The goals are simple: private uploads, automatic conversion, protected delivery, quick status feedback and predictable cost.

Layer One: Ingest

Customers upload through a controlled path into a private source bucket. A small trigger reacts to each new file by checking its type and size, then records the video as “processing” in a database. Nothing is public at this stage.

Layer Two: Transcode

The trigger creates a job in the chosen region using a named template. Standard videos use a ladder suited to typical viewers, and premium videos use a template with encryption. Outputs go to a separate output bucket under a folder named after the video identifier. Interactive mode handles new uploads, while batch mode handles occasional re-encoding of older videos.

Layer Three: Publish

When the job finishes, a notification reaches a subscriber. The subscriber verifies that the manifest and thumbnails exist, updates the database to “ready” and informs the uploader. Only then does the player page expose the video.

Layer Four: Deliver and Observe

A delivery network serves the outputs to viewers, so the output bucket itself is never opened broadly. Dashboards track upload-to-ready time, job failures, quota usage and monthly cost per video. A runbook explains what to do for each alert.

flowchart TD
    U["Customer upload"] --> SB["Private source bucket"]
    SB --> TR["Trigger: validate and record processing"]
    TR --> TA["Transcoder API job using named template"]
    TA --> OB["Output bucket: renditions, manifests, thumbnails"]
    TA --> PS["Job status notification"]
    PS --> SUB["Subscriber verifies outputs"]
    SUB --> DB["Database marks video ready"]
    OB --> CDN["Delivery network"]
    CDN --> PL["Viewer player"]
    TA --> MON["Dashboards and alerts"]
    SUB --> MON
        

Five realistic situations showing how the pieces fit together.

Capacity Planning for Busy Days

Video traffic is rarely smooth. A product launch, a news event or the end of a school term can send thousands of uploads within hours. Plan for these peaks before they happen. Estimate how many jobs you may create at the busiest hour, compare that number with the interactive concurrency limit in each region, and decide in advance which work can wait in batch mode. If you still expect to exceed the limits, request a quota adjustment early, because approvals are not instant, or spread work across several regions where your data rules allow.

Pair capacity planning with graceful behavior in your application. When a creation request is rejected for being over the limit, wait briefly and try again with increasing delays, instead of hammering the service. Show users an honest “your video is in the queue” message. People accept a short wait far more easily than an unexplained error.

Lessons Teams Report

Every important term from this guide, defined in one or two simple sentences.

Common Misunderstandings Cleared Up

A Simple Testing Strategy

Video problems are easiest to fix before launch. Build a small library of test files that represent your real uploads: a short clip from a phone held vertically, a long landscape recording, a file with no audio track, a very dark scene, a fast sports scene and a screen recording. Run every new template against this library and review the results on at least one phone, one laptop browser and one television or streaming device. Keep notes about what each test taught you, so that future changes can be judged against the same yardstick.

Also test failure on purpose. Upload a corrupted file, remove a permission and request an unsupported setting. Watching how the pipeline reports each failure shows whether your alerts and your user messages are clear enough, and it turns surprises in production into familiar events.

A Short Pre-Launch Checklist

One-Page Decision Guide

No. It converts files that already exist in storage. Live broadcasts need a service built for real-time live streaming.

It depends on the video length, the number and size of outputs and current load. There is no strong timing guarantee, so design your workflow to be asynchronous.

In Cloud Storage. Both are named by their storage addresses, and the output folder is created for you when needed.

Two H.264 renditions at 640 by 360 and 1280 by 720, an AAC audio stream, HLS and DASH playlists, and standalone SD and HD MP4 files. Its input needs at least one video and one audio track.

Yes. Both playlists can reference the same encoded streams, so you do not encode the video twice.

Per minute of output, with each video stream priced by its resolution category. Audio inside a video job adds no separate charge, audio-only outputs have their own lower rate, and automatic subtitles are billed per minute for each track. Check the official pricing page for current rates.

Interactive mode starts jobs as soon as capacity allows but rejects jobs beyond the concurrency limit. Batch mode queues jobs, supports priorities and suits large volumes where waiting is acceptable. Both can be used together.

People and applications need roles to create, view or delete jobs and templates. Separately, the service agent needs access to the source and output buckets. By default it has broad access, which can be narrowed to specific buckets.

Yes, through overlays that support image files such as PNG with transparency. Remember that the logo becomes part of the picture in that output.

You can encrypt streaming outputs using supported content protection schemes, and combine that with a controlled key service and private storage.

Completed jobs are deleted after a default of thirty days, and you can change the period with a setting on the job.

Usually because of codec, container or content protection differences. Test on real devices and make sure the output formats match what each target device supports.

The Transcoder API turns the heavy, specialized work of preparing video into a managed service. You store a source file in Cloud Storage, describe the outputs you want through a preset, a template or a custom configuration, and receive streaming playlists, standalone files, thumbnails and more in return. Around that core sit practical features such as captions, overlays, edit lists, encryption, batch processing and notifications. Success depends less on clever settings and more on steady habits: test on real devices, keep storage private, tighten the service agent’s access, choose the right mode for each workload, and watch both failures and cost.