A video you cannot skip forward in or scrub through on a Mac

The video plays from the beginning without trouble, but the moment you drag the playhead, nothing happens. Or it snaps back to where it was, or the picture freezes for several seconds before catching up, or the arrow keys do nothing at all. Sometimes the time display shows no duration.

This is nearly always a structural problem, not damage to the picture. Players jump around a video by looking up where a given moment lives in the file, then decoding from the nearest complete frame. If the lookup table is missing, or complete frames are few and far between, seeking falls apart while ordinary playback carries on. Both are fixable without re-recording anything.

How seeking works, in one paragraph

Compressed video stores a complete picture, called a keyframe, every so often, and records the frames in between as changes from it. To jump to 12:40, a player consults the file’s index to find the nearest keyframe before 12:40, reads from there, and decodes forward until it reaches the moment you asked for. That needs two things: an index that says where everything is, and keyframes frequent enough that the decode forward is short. Take away either one, and the playhead stops cooperating.

Cause 1: the file has no usable index

Some recordings are written as a stream, with the index saved for the very end. If the recording stopped cleanly, the index gets written and all is well. If it did not, or if the tool that made the file never writes one, you get a file that plays from the start and cannot be navigated.

Common sources:

• Recordings made in a web browser. Many web-based recorders and meeting tools save WebM files as a live stream, without a duration or a seek index. They play from the start and refuse to jump. What is a WEBM file covers the format itself.
• Transport stream files (.ts, .mts, .m2ts). These were designed for broadcast, where there is no index at all. Players estimate positions from the bitrate, so seeking is slow and lands roughly in the right place rather than exactly.
• Interrupted recordings. A camera that lost power, or a screen recording that ended in a crash, may have written all of the frames and none of the index. These often show a duration of zero, or no duration at all.

The telltale sign: Get Info (select the file and press Command-I) shows no duration, or one that is obviously wrong, while the video still plays from the start.

Cause 2: keyframes are too far apart

Sometimes the index is fine but seeking is still sluggish. The picture freezes, jumps forward in big steps, or shows smeared blocks for a moment after you let go of the playhead. That points to sparse keyframes.

Screen recordings, security camera exports and live stream captures often place a keyframe only every several seconds, or much less often, to save space when little on screen changes. Every jump then has to decode a long run of frames before it can show you anything. On a fast Mac with a short clip you barely notice. On a long recording, or an older Mac, scrubbing becomes painfully slow.

Cause 3: the file is not really on your Mac yet

Worth ruling out before you change anything. A video in iCloud Drive that has not fully downloaded, or one opened directly from a network drive or a slow external disk, can play from the start because playback reads ahead, while jumping forward means waiting for data that is not local yet. A file that will not open because iCloud kept a placeholder explains the iCloud side.

The quick test: copy the file to your Desktop and try again. If seeking is suddenly instant, the file was fine all along and the storage was the bottleneck.

Fixing a missing index: rewrite the file

When the index is the problem, the fix is to write a new copy of the file so that a fresh index is built from the frames that are there. For video already in a codec your Mac plays, such as H.264 or HEVC in an MP4 or MOV, this can be done without touching the picture: the frames are copied across as they are, and only the structure around them is rebuilt. Remux versus re-encode explains why that costs no quality.

For WebM from a browser, or anything in a codec the Mac does not decode natively, the conversion to MP4 has to re-encode the picture. It takes longer, but in one pass you get a file the Mac plays natively, with a proper index.

Manatee does this in its Convert mode. Drop the file on the menu bar icon or into the window, choose MP4 or MOV, and a new file appears next to the original, which is left exactly as it was. It accepts WebM, TS, MTS, M2TS, MKV and the other formats that tend to cause this, and it all runs on your Mac with nothing uploaded.

If the file is an interrupted recording that shows no duration, a conversion may fail outright, because there is no structure to read. That is a repair job. Manatee’s Repair mode scans the frames that reached the disk, rebuilds the file around them, and reports the result as Fixed, Partial or Not fixable. Video file is 0 bytes or shows the wrong length goes through that diagnosis in detail.

Fixing sparse keyframes: one careful re-encode

If the index is fine and the keyframes are the problem, rewriting the file with the frames copied as they are will not help, because the keyframes stay exactly where they were. You need a re-encode, which writes a new video stream with its own keyframe pattern. Standard encoders place keyframes at regular, short intervals by default, so the result scrubs normally.

In Manatee, Shrink is the mode for this. To reach the size you name, it encodes the video afresh, which lays down a new keyframe pattern. Name a size modestly below the current one and the picture stays close to the original; name a much smaller one if you want to save space at the same time.

A re-encode is lossy, so do it once, from the original, and do any size reduction in the same pass rather than converting first and compressing afterward. Why compressing a video twice makes it look worse explains what goes wrong when you stack them.

Questions

Why does the video play fine from the start if something is wrong with it? Ordinary playback does not need the index; it reads frames in order. Only jumping needs to know where things are, which is why the fault stays hidden until you touch the playhead.

Will the rewritten file look worse? Not if the frames are copied rather than re-encoded, which is the case when only the index was missing and the codec is one the Mac plays. A re-encode costs a little quality, which is why it is worth doing once, from the original.

Is there a setting in QuickTime Player that fixes this? No. QuickTime Player relies on the file’s own index and keyframes. The fix has to happen to the file.