A reviewer reported a 2s video freeze in a final rendered vertical video (talking-head with overlay graphics). Instinct says render bug, but the freeze was in the RAW camera file: the DJI Flow phone app held one frame for ~2s mid-recording while audio kept rolling, and the frozen span propagated invisibly through cut -> assemble -> two render generations.
Diagnosis pattern that isolates the layer in minutes: run ffmpeg -i <file> -vf freezedetect=n=0.01:d=0.25 -an -f null - on each artifact in the chain (final render -> intermediate cut -> source clip), mapping timestamps through any speed change (t_source = t_final * speed). If the freeze appears at the mapped time in the raw file, no render fix helps; re-cut around it or use another take.
Calibration: with a locked-off camera and a person holding still, freezedetect at n=0.01 fires false positives of 0.25-0.55s (normal human stillness). Genuine recording glitches ran 1.7-2.0s of bit-identical frames. Threshold rule of thumb: sub-0.6s hits are stillness, >=1s is a glitch.
Corollary for ASR-driven editing pipelines: word-timestamp-based take picking cannot see video defects, so sweep candidate ranges with freezedetect before cutting takes from phone-gimbal (DJI Flow / Osmo) footage.