2026-07-25

Picking a good timestamp for a video still frame (and why the seek is more accurate than you’d guess)

NearVid can pull a single still frame out of any video and save it as a JPG or PNG — no re-encoding of the video itself, just demux, decode, and save one image. It sounds like it should be simple: type a timestamp, get a picture. Mostly it is. But pick the wrong second and you get a smear of motion blur or a half-formed transition frame instead of the clean thumbnail you wanted. Here's what's actually happening when you extract a frame, and how to pick a timestamp that doesn't waste a re-run.

Why typing a timestamp usually just works

NearVid's frame extraction runs one ffmpeg command: -ss <seconds> -i input -frames:v 1. Putting -ss before -i looks like it should only seek to the nearest keyframe, and for stream-copy operations (like NearVid's lossless trim) that's exactly what happens — cutting at a keyframe boundary is the whole point there, since no re-encoding happens. Frame extraction is different: it isn't a stream copy. Without -c copy, ffmpeg jumps to the nearest keyframe at or before your timestamp as a fast starting point, then decodes forward from there until it reaches the exact frame you asked for. You get the accurate frame, at roughly the seek speed of a keyframe jump rather than the cost of decoding from the start of the file. That's why asking for frame 47.3 actually gets you frame 47.3, not whatever keyframe happened to be nearby.

What actually makes a still look bad

Given an accurate frame, two separate things can still make it look worse than the video did while playing. The first is real motion blur baked into the source at capture time — a fast pan or a moving subject smears across a single exposure, and pausing on that exact frame just makes the blur obvious instead of hiding it in 24-30 frames a second of motion. The second is compression: encoders typically spend more of their bit budget on keyframes, since every frame in between is predicted from them. A single frame decoded from deep inside a fast-motion sequence can carry more blockiness or noise than a frame that happens to land near a keyframe or a static shot. Neither problem is a NearVid bug — they're properties of the source video and how it was compressed. A different second of the same clip, especially one without fast motion, can look meaningfully cleaner.

Picking a timestamp without a live preview

NearVid's frame tool doesn't have a scrubber — you type a number of seconds and get one image back. (It does clamp your input to just under the real, measured duration, so asking for the very last moment of the file doesn't come back empty — but that's a safety net, not a preview.) With no way to see the frame before committing, a little guessing strategy saves re-runs: avoid exactly 0:00, which is often a black frame or a fade-in; avoid the last second or two, for the same reason in reverse; and if the clip has a scene cut or big camera move you remember, pick a timestamp a beat away from it rather than on it. For anything that matters — a thumbnail you'll actually publish — extracting two or three nearby seconds and keeping the best one costs a few extra clicks, not real time, since each extraction only decodes forward from one keyframe rather than the whole file.

JPG or PNG: a separate decision from the timestamp

NearVid defaults frame exports to JPG, encoded at ffmpeg's -q:v 2 — near the top of that scale's quality range, so the compression is light. For an ordinary video frame — natural color gradients, no sharp text or line art — that's normally the right call: a small file with compression loss that's hard to see at that setting. PNG is lossless and available as the other option, which matters if the frame itself has sharp edges the compression would visibly degrade — a paused frame with on-screen text or graphics, a slide from a recorded screen share, a frame you're going to crop or edit further where you don't want compression artifacts compounding on each save. It's a real tradeoff, and it's independent of which second you picked: a good timestamp saved as a heavily-artifacted JPG can still look worse than a slightly-less-perfect frame saved as PNG.

The short version

The seek itself is accurate, not just close — you get the frame you asked for, not the nearest keyframe. What determines whether it looks good is the second you chose and, for frames with fine detail, the format you exported it in. Both are choices worth a moment's thought before you hit process, since there's no preview to check your guess against first.