How to Batch Compress Videos on a Mac

Every row below used HEVC at 10-bit, CRF or RF 28, the medium preset and 192 kbps AAC, except the hardware row, which has no CRF and was set to its quality scale instead.

For a one-off folder, use the ffmpeg loop below. It is free, it is fast to write, and it is the reference the other rows are measured against. Use HandBrake if you want a window with a queue you can watch. Use the hardware encoder for drafts and previews, not for the copy you keep.

Install ffmpeg with Homebrew (brew install ffmpeg), open Terminal in the folder, and run:

mkdir -p small
find . -maxdepth 1 -type f \( -iname '*.mov' -o -iname '*.mp4' \) -print0 |
  xargs -0 -I{} sh -c 'ffmpeg -nostdin -n -i "$1" -c:v libx265 -preset medium -crf 28 \
    -pix_fmt yuv420p10le -tag:v hvc1 -c:a aac -b:a 192k \
    -movflags +faststart "small/$(basename "${1%.*}").mp4"' _ {}

Three details in there are doing more work than they look.

-tag:v hvc1 is not optional on a Mac. ffmpeg labels HEVC in MP4 as hev1 by default. We checked both labels with AVFoundation, the framework Apple’s own apps play video through: the hev1 file came back isPlayable = false, and the identical encode tagged hvc1 came back true. Leave the tag off and you get a folder of perfectly good videos that QuickTime refuses to open.

-n makes the batch resumable. It tells ffmpeg never to overwrite, so if the run dies at clip 340 of 500, running the same command again skips the finished ones and carries on. We confirmed it: the second pass printed “already exists. Exiting.” for every completed file.

Writing into small/ keeps outputs out of the search, because -maxdepth 1 only looks in the top folder, so a second run never tries to compress its own results.

For nested folders, swap the loop for find, which handles spaces in paths:

find . -iname '*.mov' -not -path './small/*' -print0 |
  xargs -0 -I{} sh -c 'ffmpeg -n -i "$1" -c:v libx265 -preset medium -crf 28 \
    -pix_fmt yuv420p10le -tag:v hvc1 -c:a aac -b:a 192k "${1%.*}-hevc.mp4"' _ {}

CRF 28 is a sensible default for footage you will watch rather than edit. If you are unsure what number to pick, our guide to what CRF actually trades covers it, and the single-video guide covers the QuickTime and HandBrake routes for one file.

We tried to measure this and could not get a number we are willing to publish, which is itself worth knowing. The test Mac was running other work at the same time, and the same four-clip x265 batch took anywhere from 34.8 to 99.3 seconds across repeats. Runs with two encodes at once finished first in both paired comparisons, but when a machine is busy, two processes also simply claim a bigger share of it. That flatters parallelism in a way an idle Mac would not.

What stayed stable was CPU time: 79 to 82 CPU-seconds per 20 seconds of 1080p footage in five of six runs. On an M2 Pro that works out to roughly 4 CPU-seconds per second of video at x265 medium. Use that to estimate a big job, then time -P 2 against a plain loop on ten of your own files before committing to five hundred.

find . -maxdepth 1 -type f \( -iname '*.mov' -o -iname '*.mp4' \) -print0 |
  xargs -0 -P 2 -I{} sh -c 'ffmpeg -nostdin -n -i "$1" -c:v libx265 -preset medium \
  -crf 28 -pix_fmt yuv420p10le -tag:v hvc1 -c:a aac -b:a 192k "small/$(basename "${1%.*}").mp4"' _ {}

Parallel runs do not change the output. The ffmpeg batch produced 14,005,491 bytes whether it ran one, two or three encodes at a time.

Close, but not identical, even with matching numbers. We ran HandBrakeCLI 1.11.2 with the 10-bit x265 encoder at RF 28 and the medium preset, the same settings as the ffmpeg loop. It produced 15.1% fewer video bytes and scored slightly lower on VMAF (99.56 against 99.85 on clip 1, and 99.71 against 99.83 on clip 7). HandBrake passes its own defaults to x265, so RF 28 in HandBrake and CRF 28 in ffmpeg are neighbors rather than twins.

HandBrakeCLI -i in.mov -o out.mp4 -f av_mp4 -e x265_10bit \
  --encoder-preset medium -q 28 --crop-mode none -E av_aac -B 192 -6 stereo

Two defaults caught us out. HandBrake crops what it detects as black bars unless you pass --crop-mode none, which changes the frame size of anything letterboxed. And on our synthetic tone track, its AAC came out at about 28 kbps even with -B 192 set, so check the audio on a real clip before trusting a queue of two hundred.

In the Mac app, HandBrake’s own documentation describes the route: the Add to Queue toolbar button for one source, File → Add Titles to Queue… for several, then Start Queue. The argument for it is that you can watch the queue and stop a bad job without killing the rest. The argument against it is the number of tabs you have to check before the first job. Our HandBrake comparison goes through which ones matter.

Only when time matters more than size. Apple Silicon has a dedicated media engine, and ffmpeg reaches it through hevc_videotoolbox. On our twelve clips it finished in 15.9 seconds against 124.9 for the x265 loop, and it was at least five times faster in every run we did, however busy the machine was.

The bill arrives in bytes. At -q:v 60 the hardware encoder wrote 3.08 times as much video as x265 and still scored lower: 97.43 against 99.85 on clip 1. It also wrote 8-bit Main profile rather than 10-bit. For a folder of dailies you will watch once and delete, that is a great trade. For an archive you will keep for ten years, it is a bad one.

One more thing if you are choosing hardware. Apple says the M2 Max has two video encode engines and up to twice the video encoding speed of the M2 Pro, so a machine with two engines has more room for running hardware encodes side by side. The trade-off at 4K is worse again, and our 4K guide measures it.

Not a better encoder, and we can prove that. With CRF 28 and the medium preset pinned, Smol’s output was bit-identical to the ffmpeg loop above: the video and audio streams of clips 1, 7 and 12 had matching MD5 hashes, and each file differed by 14 bytes of container metadata. Under the hood it is FFmpeg’s libx265, and it encodes files one after another, like the loop.

What changes is everything around the encode. You drop a folder instead of writing a loop, hvc1 tagging is already done (all twelve outputs carried it), and the same drop handles the photos and PDFs from the same shoot. A Finder Quick Action means no Terminal, and a watched folder compresses whatever lands in it. Point a watched folder at originals, never at files that are already compressed.

If an AI coding agent is already part of your workflow, Smol ships an MCP server that Claude Code, Codex and Google Antigravity can drive directly. Every Smol run in this article was started that way: the agent passed the file list, pinned CRF 28 and the medium preset, and read the per-file results back without anyone touching the app.

If you are comfortable in Terminal, the ffmpeg loop gives you the same files. Not similar ones. The same bits. There is nothing in a video batch that Smol encodes better, so paying for it only makes sense if the convenience is worth $29 to you.

If you need speed above all, Smol does not expose the hardware encoder. Its video path is software x264 and x265. For a pile of dailies due in an hour, hevc_videotoolbox in the same ffmpeg loop, or HandBrake’s H.265 (VideoToolbox) encoder, will finish several times sooner.

If you need per-file control, HandBrake has more of it. Chapters, subtitle burn-in, per-title crop, filters, custom presets and a queue you can inspect job by job. For a folder of mixed sources that each need something different, that depth is the point.

Smol earns its price when batches are routine and mixed: every week, a folder that holds video and photos and PDFs, run by someone who does not want to write or maintain a script. If what you need is a size cap rather than a quality target, our email guide covers the arithmetic, and the format reference lists every container Smol reads and writes. It writes MP4, MOV, WebM and MKV.