Condensing gigabytes of surveillance into 'only the moments where the picture moves' is the cheapest satisfying video shrink. I ran every ffmpeg static-cutting route on this box: freezedetect precise-trim, mpdecimate stream drop, select keep+resample, plus AV1/H.264 hardware encode. This is the roadmap and the battle scars.

Env: Core Ultra 5 235H / Arc 140T (QSV encode) / ffmpeg 9.0.1 (gyan essentials) / 1080p 10fps surveillance, 3×60s per dir. Tested 2026-09-11~12.

Where each route sits

Route 1: freezedetect + precise-trim (best AV sync)

Most straightforward: freezedetect finds windows frozen ≥ threshold, invert to activity intervals (merge gaps <5s), then cut video and audio with the same atrim bounds and stitch. Naturally in sync, because both streams share one timeline.

:: 每段：视频音频同边界 -ss/-to，天然同步
ffmpeg -f concat -i list.txt -ss S -to E -c:v libx264 ultrafast -c:a aac seg.mp4

:: 合并后 AV1 硬编（Arc 140T av1_qsv preset7 gq27）
ffmpeg -i joined -filter:a atempo=5 -vf setpts=0.2*PTS -c:v av1_qsv -preset 7 -global_quality 27 out.mp4

Measured (real A dir): 7.6s, 3.4× compression, V=30.93/A=30.91s locked sync, full audio. The only correct answer when the audio matters — those family voices in the footage can't vanish.

The n-threshold sweep: noise vs stillness

The core flag is freezedetect=n=-50dB:d=.... n is the change-sensitivity that decides whether noisy night footage counts as 'still':

-48dB sits at the valley of this curve (26%); both -60dB and -45dB read higher — around noisy-sensitivity n isn't monotonic, it jumps. Practical split: -48dB for empty nights, -50dB for busy days (daytime differences are large enough not to falsely cut people — see hardware-encode tests).

Route 2: mpdecimate single-pass (fastest, minus audio)

mpdecimate is a streaming dedupe filter — it drops near-identical frames while decoding, no pre-detection pass. One command does drop + resample + speed + hardware encode:

ffmpeg -f concat -safe 0 -i list.txt ^
  -vf "mpdecimate=lo=768:hi=1536:frac=0.33,setpts=N/FRAME_RATE/TB,setpts=0.2*PTS" ^
  -an -c:v av1_qsv -preset 7 -global_quality 27 out.mp4

Measured: A (empty night) 2.6s, B (busy day) 3.4s, ~3× compression — the fastest of all three. But audio must be dropped (-an): dropped frames shorten the video timeline while audio keeps running; they can never reconcile. Only for footage whose audio is pure noise.

Route 3: select keep-frame (the AV deadlock)

select keeps 'active frames' then resamples, but video drops per-frame (sparse) while audio stays per-interval (continuous) — the granularities never match. Measured: A dir V=13.65s vs A=30.85s, off by more than half. Verdict: select drops frames but not time; duration won't shrink; AV can't sync; unusable.

Frequent traps: trim/atrim mixing & VFR drift

Trap A: video needs trim, audio needs atrim — mixing throws Error linking filters. atrim is a general AV filter; chaining it with video-only filters (setpts/fps) fails negotiation. Split: trim for video, atrim for audio, in one filter_complex.

Trap B: sample to CFR with fps before select, or VFR frame-count drift desyncs the AV. Similarly 'per-file VFR direct-read detection' misjudges noise (A floor 73% vs concat 12%) — concat unifies to CFR, which is the correct detection.

The final delivered form

Constant 700k (≈ source bitrate) is the key: the source sits at ~600k, so same-bitrate re-encode loses no quality, and cutting stills does the compressing. For human viewing I shipped 'cut-still + 5× + single stream + H264' — A 1.4MB, B 1.9MB, C 2.3MB, sync 0.06s. But remember: cut-still assumes 'nobody/nothing moves'; the semantic 'is there a person' needs a detector (see YOLO person-cut).