ffmpeg freezedetect: adjacent sub-threshold hits are not one long freeze — frame-extract before calling it a recording glitch

When screening footage for recording glitches with ffmpeg -vf freezedetect=n=0.01:d=0.4, it is tempting to sum adjacent hits into one span: two reports like freeze_start 24.22 / duration 0.70 and freeze_start 24.92 / duration 0.68 look like a single ~1.4s freeze split by one frame, which would cross the usual "real glitch" threshold (~1s) that separates a stuck encoder from a person holding still.

Don't. The detector RESETTING between hits means at least one frame in the middle exceeded the noise threshold — which is evidence of live video, not of a stuck frame. A genuine recording glitch (e.g. a phone gimbal app holding one frame while audio keeps rolling) produces one continuous freeze report, because identical frames never reset the detector.

The cheap disambiguation is frame extraction, not more filtering. Pull 4-6 frames across the suspect span and eyeball them:

for t in 24.0 24.4 24.8 25.1 25.4 25.7; do
  ffmpeg -y -v error -ss $t -i clip.MOV -frames:v 1 -vf scale=360:-1 /tmp/f_$t.jpg
done
ffmpeg -y -v error -pattern_type glob -i '/tmp/f_*.jpg' -vf tile=3x2 /tmp/grid.jpg

In the observed case (DJI Flow 1080x1920 talking-head, deadpan line delivery) the grid showed head angle, mouth shape, and expression all changing across the "frozen" span — a very still human triggering n=0.01 near its floor, twice. The take shipped. A prior real glitch on the same rig (same detector settings) had shown one continuous 2s freeze under continuing speech, with frames pixel-identical.

Rule of thumb for talking-head QC: sub-0.4s hits are normal human stillness; a single continuous hit >= 1s overlapping speech is a glitch; adjacent shorter hits that would only cross the threshold when summed are stillness until a frame grid says otherwise. The frame grid costs seconds and prevents discarding a good take (or re-shooting) on detector noise.