BitrateCraft · Home · bitratecraft.org
HandBrake Transcoding Reference
HandBrake is an open-source transcoding tool that rewrites an existing video file into a new container, codec and bitrate. This reference explains what the program does, which axes an operator really controls, and how it compares with scripted alternatives for the same job.
The material here treats a transcode as a chain of explicit engineering decisions rather than a single button. Every guide assumes one operator, one workstation, and a source file that already sits on local storage. Nothing on this site covers acquiring material, and no page points at a binary of any kind.
What HandBrake is
At its core HandBrake is a front end over a demuxer, a decode stage, an optional filter chain, one or more encoders and a muxer. The program opens a source, inspects the streams inside it, and presents what it found as a small number of named panels. The operator then decides how each stream should be re-encoded and what the finished file should be called.
Because the front end is opinionated, the same engine can be driven in two very different ways. A hurried operator accepts a preset and lets the tool choose bitrate, filters and container. A careful operator opens every panel, overrides each value, and treats the interface as a thin control surface over the encoder. This site is written for the second operator, though the first will still find the checklists useful.
HandBrake is a transcoder, not an editor. It has no timeline, no colour grading, no keyframed compositing and no mixing desk. Anything that must be arranged in time belongs in an editing application; the transcoder's work starts once the material is locked and ends when a compliant delivery file exists on disk.
The six pipeline axes
Almost every decision a transcode requires sits on one of six axes. Read them as a checklist: if a value on one of these axes is left unexamined, the output is only as predictable as the default hiding behind it.
Container
The wrapper that holds the finished streams. It decides which codecs are legal inside, whether chapter markers survive, and what the receiving player will accept without complaint.
Video encoder
The choice between software encoders, which spend bits for quality, and hardware encoders, which spend speed for time. Encoder choice fixes the entire quality conversation.
Rate control
Constant quality, average bitrate, or a two-pass target. This axis decides how the bit budget is spent across quiet and busy scenes.
Audio
Per-stream codec, channel mixing, and a fallback track for players that cannot decode the primary one. Audio is inexpensive to get right and easy to neglect.
Filters
Scaling, cropping, deinterlacing and denoise. Filters run before the encoder and change what the encoder is allowed to see.
Subtitles
Burned-in text, soft tracks, and forced captions. This axis decides whether text survives as data or becomes part of the picture itself.
The axes apply in a fixed order. Nothing downstream can repair a decision made upstream, which is why the panel tour later on this site walks the interface from left to right.
Filters run before the encoder
The distinction matters more than it first appears. A scale or crop operation applied in the filter chain changes the frame the encoder receives, so the bitrate target that follows is spent on fewer or differently shaped pixels. A deinterlace pass removes comb artefacts that would otherwise become expensive high-frequency detail. Placing the same correction after the encode is impossible; the transcoder has already committed.
Queue behaviour and repeatability
A single file is a warm-up. The useful unit of work is a queue, and a queue is only repeatable if its settings are recorded. Two habits pay for themselves quickly. First, keep a written record of the preset name and the values that were overridden, because a queue that produced a good result last month should produce the same result today. Second, process representative clips end to end before committing a long batch, since a setting that looks harmless on a ten-second sample is exactly the setting that ruins a two-hour delivery.
Disk layout belongs to the same conversation. Decode and encode both want scratch space, and a queue that fills a drive halfway through leaves a partial file that must be found and removed by hand. Estimating the output size before a long run is cheaper than discovering the limit after it.
How HandBrake compares
HandBrake occupies one point in a small field. The same transcode can be produced by a command-line tool or by a batch-oriented encoder interface, and each option trades operator attention against control. The table below is a compact orientation, not a ranking.
| Property | HandBrake | FFmpeg | Shutter Encoder |
|---|---|---|---|
| Interface model | Graphical panels over a fixed pipeline | Command line, scripted flags | Graphical front end with a scripting layer |
| Encoder access | Curated software and hardware encoders | Every encoder the build exposes | Broad hardware and software coverage |
| Automation depth | Presets, queue, batch folder | Total, embedded in any script or service | Presets plus a documented command interface |
| Typical use | Repeatable one-off conversions | Pipelines, servers, mass conversion | Mixed desks needing both modes |
Rule of thumb: choose the tool whose failure mode you can debug. A graphical front end hides a wrong value behind a checkbox; a command line exposes it, but only to an operator who reads the log.
Frequently asked questions
Does a smaller file always look worse?
No. The relationship between size and perceived quality is governed by the rate-control axis, not by the file size alone. A modern software encoder at a sensible constant-quality value can produce a smaller file than an older one at a higher average bitrate while looking cleaner.
Should hardware encoding replace software encoding?
They solve different problems. Hardware encoders finish a long queue in far less wall-clock time, while software encoders usually spend a given bit budget more efficiently. A delivery with a hard deadline and a generous bit budget is a good fit for hardware; an archival master is usually not.
Why does the same setting give different results?
Because the source changed. Different noise, film grain or interlacing in the input changes how the encoder spends its bits. When a preset is reused across unrelated material, expect the output size to move even when every visible control is identical.
Is the tool useful without an editor?
Yes. Once material leaves an editing application as a finished master, the remaining work is transfer: changing container, trimming dead air, adding a subtitle track, or producing a smaller copy for review. That is exactly the class of job a transcoder is built for.
What belongs in a transcode log?
Source path, source duration, chosen encoder, rate-control mode and value, filter list, audio tracks kept, and the output name pattern. With those six facts recorded, a result can be reproduced or deliberately changed later.
Continue with the panel-by-panel interface tour, or with the guide to source selection, range modes and output naming.