Batch video conversion is the difference between a creator who ships and one who is permanently three episodes behind. A single 4K source can spawn a dozen deliverables: a YouTube master, a Shorts vertical crop, an Instagram Reel, a podcast network MP4, a low-bitrate preview for clients, an archival ProRes copy, plus localized variants with burned-in subtitles. Doing that one file at a time is not a workflow, it is a hostage situation. The skill is not knowing one tool well, it is composing a pipeline so the machine does the boring part overnight while you sleep, and the outputs are bit-for-bit reproducible the next time a brand asks for the same spec.
This guide assumes you are already comfortable with at least one nonlinear editor and want to push the rest of the chain into automation. We will work primarily with ffmpeg because every meaningful tool in the video stack either wraps it or reimplements a subset of it, and because the command line is the only interface that survives a software update without breaking your batch script.
Why batch conversion is fundamentally a queue problem
A naive batch loop runs files sequentially: one file finishes, the next starts. On modern hardware this is wasteful for two reasons. First, x264 and x265 saturate the CPU but barely touch the disk, so I/O sits idle while encoding runs. Second, GPU encoders such as NVENC and QuickSync are massively underutilized at one stream at a time and can typically run four to eight encodes in parallel without quality loss.
The right mental model is a job queue with a configurable concurrency limit. You feed it a list of input files plus an output recipe, and it dispatches workers up to a parallelism budget, retrying failures and logging each job's exit status. This is the same pattern used by render farms, CI runners, and database workers, and the tools are mature.
"Controlling complexity is the essence of computer programming." Brian Kernighan, Software Tools
The complexity in batch video is not the encoding, it is the bookkeeping: which files have been processed, which failed, what settings produced which output, how to resume after a power cut. Every hour you invest in the queue layer pays back tenfold the first time a 200-file batch crashes at item 147.
A minimum viable pipeline with ffmpeg and GNU parallel
The simplest batch that still respects parallelism uses GNU parallel to feed ffmpeg jobs from a file list. This works on Linux, macOS, and WSL, and the syntax is identical.
# Build a list of source files
find ./masters -name "*.mov" > queue.txt
# Run four concurrent encodes, log each job's stderr separately
parallel -j 4 --joblog encode.log \
'ffmpeg -hide_banner -y -i {} \
-c:v libx264 -preset medium -crf 20 \
-c:a aac -b:a 192k -ac 2 \
-movflags +faststart \
./out/{/.}.mp4' :::: queue.txt
A few details that separate this from a toy script. The -hide_banner keeps the log readable, -y prevents the encoder from blocking on a y/n prompt when an output already exists, +faststart moves the moov atom to the front of the file so web players can start streaming before the download completes, and --joblog gives you a tab-separated record of every job for retry tooling.
For Windows-native batches without WSL, the equivalent is PowerShell with ForEach-Object -Parallel:
Get-ChildItem -Path .\masters -Filter *.mov | ForEach-Object -Parallel {
ffmpeg -hide_banner -y -i $_.FullName `
-c:v libx264 -preset medium -crf 20 `
-c:a aac -b:a 192k -ac 2 `
-movflags +faststart `
".\out\$($_.BaseName).mp4"
} -ThrottleLimit 4
The PowerShell variant lacks the joblog feature, but for runs under a few hundred files it is sufficient.
Choosing a codec by the deliverable, not by habit
The single most expensive mistake creators make is using one codec for everything. A YouTube master, a client review proxy, and a long-term archive have nothing in common in terms of priorities, and forcing them into the same encoding profile either wastes disk or burns quality.
| Use case | Container | Video codec | Audio codec | Typical CRF or bitrate | Why |
|---|---|---|---|---|---|
| YouTube or Vimeo upload | MP4 | H.264 high profile | AAC-LC 192 kbps | CRF 18 | Platforms re-encode; clean source minimizes banding |
| TikTok or Reels vertical | MP4 | H.264 main profile | AAC-LC 128 kbps | CRF 21 | Mobile decoders prefer main profile |
| Client review proxy | MP4 | H.264 baseline | AAC-LC 96 kbps | CRF 28 | Tiny files, plays anywhere, throwaway quality |
| Long-term archival master | MOV or MKV | ProRes 422 HQ or FFV1 | PCM 24-bit | Lossless or near-lossless | Survives format wars |
| Web background loop | WebM | AV1 or VP9 | Opus 96 kbps | CRF 32 | Smallest size for muted autoplay |
| Broadcast delivery | MXF | XDCAM HD422 or DNxHD | PCM 24-bit | 50 Mbps CBR | Required by station ingest |
Hardware acceleration: when it helps and when it lies to you
NVIDIA's NVENC, Intel QuickSync, AMD AMF, and Apple's VideoToolbox all expose hardware H.264 and H.265 encoders to ffmpeg. They are five to twenty times faster than libx264 at the same nominal preset. The catch is that hardware encoders are tuned for live streaming, not archival quality. At equivalent file sizes, hardware NVENC at preset p7 produces visibly worse video than CPU libx264 at preset medium, particularly in dark scenes and slow pans.
The pragmatic rule: use hardware for proxies, previews, and bulk re-encodes where the source is already lossy. Use CPU for masters and any output that will be the basis for further encoding.
# NVENC for a fast proxy pass
ffmpeg -hwaccel cuda -i input.mov \
-c:v h264_nvenc -preset p5 -tune hq -rc vbr -cq 23 \
-c:a aac -b:a 128k \
proxy.mp4
# CPU x264 for the master
ffmpeg -i input.mov \
-c:v libx264 -preset slow -crf 18 -profile:v high -level 4.1 \
-pix_fmt yuv420p -movflags +faststart \
-c:a aac -b:a 192k \
master.mp4
"Premature optimization is the root of all evil." Donald Knuth, Structured Programming with go to Statements
The same applies to hardware encoding. Reach for it when measurement shows you need it, not because the GPU is sitting there.
Probing inputs so the batch handles edge cases
A robust batch never assumes the inputs are uniform. Phone footage, screen recordings, drone clips, and DSLR exports all sit in the masters folder, and they have wildly different frame rates, color spaces, and audio sample rates. Use ffprobe to inspect each file and let the script decide.
ffprobe -v error -select_streams v:0 \
-show_entries stream=width,height,r_frame_rate,pix_fmt,color_space \
-of json input.mov
Pipe that into jq and a small dispatch function and the batch can route VFR phone footage through -vsync cfr -r 30, leave already-CFR clips alone, and force yuv420p only when the source pixel format is incompatible with the target.
Audio: the failure mode nobody catches in QC
Audio drift is the single most common defect that escapes a creator's QC pass because it accumulates slowly. A clip that is in sync at second one is a quarter-second off at minute fifteen. The cause is almost always a variable-frame-rate source mixed with a constant-frame-rate output without resampling the audio clock to match.
The fix is one filter:
ffmpeg -i vfr_source.mp4 \
-c:v libx264 -crf 20 -vsync cfr -r 30 \
-af "aresample=async=1000" \
-c:a aac -b:a 192k \
output.mp4
aresample=async=1000 allows up to one second of compensation per audio frame, which is enough for any sane source. For interview-style footage with multiple speakers cut together, also normalize loudness with loudnorm to the platform target (YouTube targets -14 LUFS, Spotify -14, broadcast -23).
Subtitles, chapters, and metadata that survive the batch
Creators who localize lose hours when batch outputs strip embedded subtitles or chapter markers. Two flags fix the common cases.
ffmpeg -i source.mkv \
-map 0 -c:v copy -c:a copy -c:s mov_text \
-map_metadata 0 -movflags use_metadata_tags \
output.mp4
-map 0 carries every stream, -c:s mov_text converts SRT or ASS subtitles to MP4-compatible timed text, and the metadata flags preserve title, artist, comment, and chapter markers. If you produce podcast video, chapters are critical for YouTube's chapter sidebar and Apple Podcasts video parity.
For multi-language outputs, drive the language tag explicitly:
ffmpeg -i source.mp4 -i en.srt -i de.srt -i fr.srt \
-map 0:v -map 0:a -map 1 -map 2 -map 3 \
-c:v copy -c:a copy -c:s mov_text \
-metadata:s:s:0 language=eng \
-metadata:s:s:1 language=deu \
-metadata:s:s:2 language=fra \
multilingual.mp4
Resumable batches and the case for a manifest
Once a batch grows past a few dozen files, ad-hoc shell scripts become a liability. The investment that pays back is a manifest: a JSON or CSV file that lists each input, the recipe to apply, the expected output path, and a status field. The runner reads the manifest, skips rows already marked done, processes pending rows, and writes back the result with timing and exit code.
This pattern is identical to how task runners coordinate work in larger systems. Creators building production pipelines often borrow ideas from the same workflow engines used in content distribution at scale, where a failed step never restarts the whole job.
Quality control without watching every frame
A 200-file batch is unwatchable. The compromise is automated sampling. For each output, extract three frames at 25, 50, and 75 percent of duration and a 10-second audio clip, then run perceptual checks: SSIM against the source, audio loudness via ebur128, and a black-frame detector for accidental fade-throughs.
# SSIM comparison to the source, written to a CSV-friendly log
ffmpeg -i source.mp4 -i output.mp4 \
-lavfi "[0:v][1:v]ssim=stats_file=ssim.log" -f null -
A mean SSIM above 0.97 indicates near-transparent quality at the chosen CRF. Below 0.93 the encoder is starving and the CRF should be lowered or the preset slowed.
| Metric | Tool | Acceptable range | Failure threshold |
|---|---|---|---|
| Mean SSIM (master vs source) | ffmpeg ssim filter | 0.97 to 1.00 | Below 0.93 |
| Integrated loudness | ffmpeg ebur128 | -16 to -13 LUFS for YouTube | Outside -20 to -10 |
| True peak | ffmpeg ebur128 | At or below -1.0 dBTP | Above 0.0 dBTP |
| Black frames detected | ffmpeg blackdetect | 0 unintended | Any unexplained black |
| Container errors | ffmpeg -v error -i out -f null - | Empty stderr | Any error line |
"The price of reliability is the pursuit of the utmost simplicity." C.A.R. Hoare, The Emperor's Old Clothes
A QC step that flags too many false positives gets ignored. Tune the thresholds to your actual content type before trusting the alarms.
Color management for batches that mix sources
Color is where well-meaning batches silently destroy work. A clip shot in Rec. 2020 HLG that gets converted to MP4 without color tags becomes a washed-out Rec. 709 file on every consumer player. The container forgets, and downstream players guess wrong.
ffmpeg -i hlg_source.mov \
-c:v libx264 -crf 18 -pix_fmt yuv420p \
-color_primaries bt2020 -color_trc arib-std-b67 \
-colorspace bt2020nc \
-movflags +faststart \
output.mp4
For SDR Rec. 709 sources, the analogous tags are bt709, bt709, bt709. If you mix HDR and SDR in the same batch, the manifest should record the source's tags and the dispatcher should select the right preset. Tools like the same color-aware pipelines that drive video format conversion documentation on the wider FCF site walk through the tag matrix in detail.
Distribution: the often-forgotten last mile
A batch that produces 200 perfectly encoded files but writes them to a slow USB drive defeats its own purpose. Plan the destination before the encode starts. NVMe scratch for in-flight work, then move completed outputs to the slower archival pool. For cloud delivery, write directly to a presigned S3-compatible URL using ffmpeg's -method PUT over HTTP.
For creators who localize content to multiple audiences, batch outputs frequently feed CDN origins serving viewers in regions as different as those covered by English-language IQ assessments and music-theory drills at When Notes Fly. The encoding pipeline is identical, the deliverable list differs.
A reference Makefile for reproducible batches
For creators who want a single entry point, a Makefile turns the whole pipeline into make all, with implicit rules that only re-encode files newer than their outputs.
SOURCES := $(wildcard masters/*.mov)
TARGETS := $(patsubst masters/%.mov,out/%.mp4,$(SOURCES))
CRF := 20
PRESET := medium
THREADS := 4
all: $(TARGETS)
out/%.mp4: masters/%.mov
@mkdir -p out
ffmpeg -hide_banner -y -i $< \
-c:v libx264 -preset $(PRESET) -crf $(CRF) -pix_fmt yuv420p \
-c:a aac -b:a 192k -ac 2 \
-map_metadata 0 -movflags +faststart \
$@
clean:
rm -rf out
Run make -j 4 all and the build system handles parallelism, dependency tracking, and incremental rebuilds. This is the same toolchain that compiles operating systems; it is more than enough for a video pipeline.
Common mistakes that survive years of practice
Three errors recur across creators of every experience level.
The first is encoding the master as the deliverable. A creator records, edits, and exports straight to YouTube-spec MP4 without ever generating a high-bitrate intermediate. Six months later, a brand asks for a 4K cut for a billboard, and the only surviving copy is 1080p H.264 at 12 Mbps. Always export a master; deliverables are derived from it.
The second is trusting the GUI's "default settings." Most consumer batch tools default to constant bitrate H.264 at 8 Mbps regardless of input, which is wasteful for static talking heads and starves fast-action footage. CRF mode is almost always the right answer for unattended batches.
The third is forgetting that platforms change. TikTok's recommended specs in 2024 are not the specs in 2026. Build the recipe as a single configuration block at the top of your script, not scattered across twelve invocations, so updates are a one-line change.
References
- ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services." International Telecommunication Union, 2021. Available: https://www.itu.int/rec/T-REC-H.264
- ITU-T Recommendation H.265, "High efficiency video coding." International Telecommunication Union, 2023.
- ISO/IEC 14496-14:2020, "Information technology - Coding of audio-visual objects - Part 14: MP4 file format." International Organization for Standardization.
- ITU-R BS.1770-4, "Algorithms to measure audio programme loudness and true-peak audio level." International Telecommunication Union, 2015.
- Wang, Z., Bovik, A. C., Sheikh, H. R., and Simoncelli, E. P., "Image quality assessment: from error visibility to structural similarity." IEEE Transactions on Image Processing, vol. 13, no. 4, pp. 600-612, 2004. doi:10.1109/TIP.2003.819861
- Bellard, F., and Niedermayer, M., "FFmpeg multimedia framework documentation." FFmpeg Project. Available: https://ffmpeg.org/documentation.html
- ITU-R BT.2020-2, "Parameter values for ultra-high definition television systems for production and international programme exchange." International Telecommunication Union, 2015.
- RFC 7164, "RTP and Leap Seconds." Internet Engineering Task Force, 2014. doi:10.17487/RFC7164
Frequently Asked Questions
Why batch conversion is fundamentally a queue problem?
A naive batch loop runs files sequentially: one file finishes, the next starts. On modern hardware this is wasteful for two reasons. First, x264 and x265 saturate the CPU but barely touch the disk, so I/O sits idle while encoding runs. Second, GPU encoders such as NVENC and QuickSync are massively underutilized at one stream at a time and can typically run four to eight encodes in parallel without quality loss.
Related Articles
Ready to Convert Your Files?
Use our free online file converter supporting 240+ formats. No signup required, fast processing, and secure handling of your files.
Convert Files