VFR — Variable Frame Rate — means the gap between frames isn't constant. Some frames are spaced 1/30 of a second apart, others 1/60, others somewhere in between, depending on how the source recorded each one. The opposite is cfr, Constant Frame Rate, where every frame is spaced exactly the same — the assumption every streaming tool and player makes by default.
VFR shows up in a handful of specific places. Phone screen recordings and screen capture tools like OBS, QuickTime, Loom and many gaming captures produce VFR because the underlying system only generates a new frame when something on screen actually changes. Some live encoder pipelines drop frames under load and produce VFR output as a survival mechanism. Certain mobile camera apps produce VFR when light conditions force the shutter to vary.
For the recording itself, VFR is fine — it saves disk space by not recording redundant identical frames. The problems start downstream. Streaming pipelines assume CFR for rate control, segment timing and adaptive bitrate logic; VFR confuses them. Players can lose audio-video sync over long durations because their timing assumes regular frame spacing. Editing tools display wrong durations and produce strange jumps. Captions can drift relative to dialogue. The pragmatic answer for any streaming product: detect VFR on ingest (FFmpeg's ffprobe reports it) and convert to CFR as the first transcoding step, usually to 30 or 60 fps depending on content type. It costs essentially nothing in quality and eliminates an entire category of bugs that's hard to diagnose later.
