VLC Video Pixelated When Skipping or Seeking

You click on the timeline to skip ahead. For a moment, or for several seconds, the picture turns to gray blocks, a smeared ghost of the previous scene, or a mosaic that slowly heals. Then it looks normal again. It is a different problem from a file that is pixelated all the time, and it points to how video is built.

Understanding it takes two minutes and tells you where to look.

How video is stored, in one paragraph

Storing every frame as a full picture would make files enormous. Instead, most video is stored as a sequence: a keyframe (a complete picture), followed by many frames that only describe the changes from earlier frames. These are called predicted frames. A player that wants to show frame number 5,000 has to find the nearest keyframe before it and decode forward from there, applying each change in order.

When you play normally, this is invisible. When you skip, the player jumps to a new place. If it lands on a keyframe, everything is clean. If it lands in the middle of a run of predicted frames, it must either back up to the previous keyframe (a delay) or show what it can decode without the missing reference (a mess). That mess is the blocky, gray or smeared look. It clears at the next keyframe.

The interval between keyframes

The distance between keyframes is called the GOP length. A long interval makes smaller files, since keyframes are expensive, and slower, rougher seeking. A short interval gives faster seeking and bigger files.

I measured it on a 10 second 1080p, 60 fps clip, encoded with x264 at CRF 23 with the very fast preset and a fixed keyframe interval:

Keyframe interval (frames)	Keyframes in clip	File size	Time to seek to 9.9 s
600 (10 s)	1	4,495 kB	about 509 ms
250 (4.2 s)	3	4,877 kB	about 205 ms
60 (1 s)	10	6,480 kB	about 167 ms
1 (every frame)	600	52,229 kB	about 132 ms

The seek times are the average of five runs of FFmpeg decoding a single frame at 9.9 seconds, so they include the program’s start-up time of roughly 100 ms, and they will be different on your machine. The trend is clear. With one keyframe in the whole clip, reaching the end meant decoding the entire clip. With a keyframe every second, it was about three times quicker. The cost: the file with a keyframe every second was 44 percent larger than the one with a single keyframe, and an all-keyframe file was more than eleven times as large.

That is the trade, and the reason most files land around one keyframe every two to five seconds. Streaming services tend to use short intervals so that the player can switch quality and seek quickly. Screen recorders and phone cameras may use long ones for efficiency.

Why the picture looks wrong, not just slow

A careful player waits and decodes from the keyframe, showing nothing wrong. Many players try to be fast: they show frames as soon as they are decoded, even if the references are incomplete. That is where the blocks come from. A related cause is file damage: if a keyframe is missing or corrupted, every frame that depends on it is wrong until the next good keyframe, and that can last many seconds.

So the question is whether your file has an unusually long interval, a damaged section, or whether the player is cutting corners.

Step one: figure out whose fault it is

Test the file in a second player. If the glitch happens in every player, the file is the cause. If only VLC shows it, look at VLC’s settings. Then test a different file in VLC, ideally one from a different source. If every file glitches in VLC, the settings or the graphics driver are the cause.

You can also look at the file’s structure with ffprobe. This lists keyframes with their timestamps:

ffprobe -v error -select_streams v:0 -skip_frame nokey \
  -show_entries frame=pts_time -of csv=p=0 video.mp4

If the gaps are very long (more than 10 seconds), the file will seek poorly. If the list shows keyframes at odd places or ends early, the file may be damaged.

Step two: VLC settings to try

Open VLC’s preferences and show all settings, then look under Input and Codecs. Menu names differ a little between versions and platforms.

Hardware-accelerated decoding. Use the graphics card to decode video. It is fast, and bugs in drivers can create artifacts, especially when seeking. Switch it to Disable, restart the video and test. If the glitches vanish, update your graphics driver, or leave it off.

Skip the loop filter for H.264 decoding. This is a speed hack that skips the deblocking step, which makes video blockier. It should be set to None (the normal setting). If somebody switched it to All to help a slow computer, the picture will show blocks everywhere, particularly after a seek.

Fast seek. If your version has an option to seek quickly to the nearest keyframe, turn it off if you want accuracy. When it is on, seeking is faster but less precise.

Video output module. Changing the output (for example from Direct3D11 to OpenGL or DirectX) can fix display glitches on some systems.

Caching. For files on a network or an external drive, a larger file caching value can reduce stutter when seeking. It does not change the picture quality, but it avoids the pause that looks like a glitch.

For Windows specifics, see the guide on fixing pixelated video in VLC on Windows.

Step three: fix the file

If the file is the problem, you have a few options.

Remux it. Copy the streams into a new container without re-encoding. This can repair a broken index, and it is lossless:

ffmpeg -i video.mp4 -c copy -movflags +faststart fixed.mp4

Re-encode with regular keyframes. If the interval is long, a re-encode at a high quality with a keyframe every two seconds gives smooth seeking:

ffmpeg -i video.mp4 -c:v libx264 -crf 18 -preset slow \
  -g 60 -keyint_min 60 -c:a copy regular_keyframes.mp4

Here, -g 60 gives a keyframe every 60 frames, so every two seconds at 30 fps. Adjust to twice your frame rate. A re-encode loses a little quality, which is why a high quality value is used.

Repair damage. If the glitches are tied to a damaged section, try remuxing with error tolerance, or the repair ladder in my corrupted file test. In that test, a file with 20 KB of randomized data in the middle still gave all 600 frames, and a remux with -err_detect ignore_err also gave all 600 frames, though the damaged section looked wrong. A truncated file with the index at the end could not be opened at all.

Step four: check the source of the video

Some kinds of files are more likely to seek badly.

Screen and game recordings. Recorders favor efficiency and may use long keyframe intervals. Setting a 2 second keyframe interval in the recorder avoids it. OBS recordings are an example: the setting is in the output options.

Downloaded streams. A stream saved from a site in segments may have been joined imperfectly. Glitches at regular intervals, such as every few seconds, suggest segment boundaries.

Cut or trimmed files. Cutting a video without re-encoding, using a stream copy, can only cut on keyframes. Tools that cut exactly may leave frames at the start that depend on a missing keyframe, and players show garbage until the next keyframe. Re-encoding the cut section or cutting at a keyframe fixes it.

Old or odd formats. Some formats do not have a reliable index. AVI files in particular may seek badly if the index is missing or damaged, and a remux into MP4 or MKV can fix them.

Interlaced content. Combing artifacts and blocks after a seek can be confused. Check whether the picture has horizontal lines in motion, and enable deinterlacing in the video menu if so.

Step five: the player

If your tests show it is VLC in particular, try updating to the latest version, or compare with another player such as mpv. If a different player is clean, VLC’s settings or version are at fault, and you can reset VLC’s preferences to defaults to rule out a stray option. Resetting is under Preferences, in the lower left corner.

A closer look at what the player does when you click

It helps to picture the sequence, because each step is a place where things can go wrong.

First, you click on the timeline. The player converts the pixel position into a time, and the time into a byte position in the file, using the index. In an MP4 file the index lives in a structure that lists where each frame sits. If the index is missing or wrong, the player guesses, and the guess can land in the middle of a frame.

Second, the player moves to the closest keyframe at or before that time. This is the cheapest correct choice. Decoding from there forward to the exact frame you asked for takes time, which is the delay in my table. A player that prioritises speed will skip that work and show the keyframe itself, or start displaying right away from the closest point it can decode.

Third, the decoder starts working. Predicted frames refer to earlier frames. If the earlier frames are the ones the player jumped over, the decoder uses whatever is in its buffer, which holds the picture from before the jump. That is the ghost of the old scene. The new changes are painted over the old picture, so you see a blend of two scenes, with blocks where the changes were large.

Fourth, the next keyframe arrives, and the decoder gets a full picture again. The artifacts disappear. That explains why the glitch vanishes by itself after a second or two, and why it lasts longer on files with long intervals.

Seen this way, there are four independent places to intervene: the index (remux), the keyframe spacing (re-encode), the decoder’s behavior (settings, hardware decoding) and the player’s shortcuts (fast seek, frame skipping).

Constant and variable frame rate

Variable frame rate files, which phones and screen recorders often make, can add confusion. A video with variable frame rate has frames at irregular times. The index is still correct, but players and editors that assume a steady rate may calculate positions slightly wrong, and a seek lands a few frames away from what you expected. That is not blocks as such, but it feels like a related glitch, and it often appears at the same time.

Converting to a constant frame rate with a re-encode solves it:

ffmpeg -i input.mp4 -vf fps=30 -c:v libx264 -crf 18 -c:a copy cfr.mp4

Use your video’s real rate in place of 30. If the footage is a phone recording of 29.97 or 30 fps, the difference is small. Screen recordings made at an uneven rate benefit the most.

B-frames and why seeking is harder than it looks

Many encoders use a third type of frame, the B-frame, which is predicted from frames both before and after it. That compresses even better, but it means that decoding order differs from display order. A player seeking into the middle of a group has to decode a few frames ahead of what it shows. If the stream was cut at the wrong place, the first B-frames after a cut have no references to the earlier frames and cannot be decoded cleanly. Players usually drop them. Some show them as a smear. This is exactly the “open GOP” problem seen in files that were cut without re-encoding.

You can avoid it with a closed GOP when you encode, which is the default for most settings, and by cutting with a re-encode when an exact start matters. For the quick cut that needs no re-encode, cut at a keyframe. FFmpeg’s stream copy snaps to the nearest earlier keyframe when you place the start time before the input, so the output starts cleanly, though not at the exact moment you named.

Disk and network problems that look like seek glitches

Not every glitch after seeking is about the video. Some come from slow storage.

• A slow USB drive or SD card. Reading a large file from a worn card can take long enough that the player runs out of data and drops frames. Copy the file to your internal disk and test it there. If the glitch is gone, the drive is the problem.
• A network share. Seeking on a file served over Wi-Fi from another computer causes a new request, and any delay shows up as stutter. A wired connection or a local copy fixes it.
• A cloud-synced folder. If the file is in a folder that syncs online and is not fully downloaded, seeking to a part not yet downloaded makes the player wait. Mark the file as available offline.
• Antivirus scanning. On some computers, real-time scanning slows file reads. It is rare, but if you see it only with large files, try copying the file somewhere that is excluded from scanning.

A quick way to tell is to play the same file from two different locations. If the artifacts differ, the storage is involved.

The graphics driver

Hardware decoding relies on the graphics driver. Drivers sometimes have bugs in the way they handle a seek in the middle of a stream, and the result is a green or pink frame, a block pattern or a smear. If turning off hardware decoding fixes the problem, you have found a driver or decoder issue. Updating the driver is a good first step. If you do not want to update, leaving hardware decoding off is a legitimate fix for desktop computers, since software decoding of ordinary H.264 is fast on a modern processor. On a laptop, hardware decoding saves battery, so there is a real tradeoff.

Green frames in particular tend to mean the decoder gave up on a frame and showed an empty buffer. Pink or purple tints mean the color planes are mismatched. Both are common in driver bugs and in damaged streams.

Testing with a known good file

To separate your setup from the files, make a test clip with regular keyframes and see how it behaves:

ffmpeg -f lavfi -i testsrc2=size=1280x720:rate=30 -t 20 \
  -c:v libx264 -g 60 -keyint_min 60 -pix_fmt yuv420p test_good.mp4

This generates a synthetic pattern with a keyframe every two seconds. Open it in VLC and skip around. If it seeks cleanly, VLC and your computer are fine, and the earlier file is the issue. If even this one glitches, the player or the driver is at fault. Then repeat the test with a longer interval, with -g 600, to see how the same player handles a sparse file. A difference between the two is the effect described above, seen on your own computer.

Fixing files in bulk

If you have a whole folder of recordings with the same problem, such as screen captures from one program, a batch re-encode is worth it. A simple loop on Linux or macOS:

for f in *.mp4; do
  ffmpeg -i "$f" -c:v libx264 -crf 20 -g 60 -keyint_min 60 \
    -c:a copy "fixed_$f"
done

On Windows, a similar loop works in PowerShell. Keep the originals until you have checked a few of the new files. A re-encode always costs a little quality, so use a reasonably low CRF value and avoid encoding the same file repeatedly.

What not to do

Do not run a heavy “repair” tool on every file that glitches once. Many glitches are only a seek and the file is fine. Do not delete the original. Do not set the loop filter to skip everything to make a slow computer keep up unless you accept blocks everywhere. And do not assume that blocks always mean low quality. A file that plays perfectly from the start and glitches only after a seek is usually in good shape, and the fix is on the playback side.

If the blocks are everywhere, not only after seeking

A video that is pixelated all the time is a different problem: low bitrate, heavy compression or low resolution. See why is my video pixelated for the general causes, and streaming problems for videos that are streamed. A cleanup can reduce the blocks in such a file. Try it on a short sample with the free preview if you want to see what is possible.

Quick answers

It only happens when I skip. Look at keyframes and hardware decoding.

It happens at the same place each time. Likely damage in the file.

It happens in one player only. Settings or the player’s version.

It happens in every player. The file, and the fix is a remux or a re-encode.

It heals after a second or two. Normal behavior with a long keyframe interval.

Summary

Blocks after skipping are the visible edge of how video is built: complete frames now and then, with changes in between. Long intervals and damaged data make seeking messy, and aggressive player settings make it worse. Test another player, turn off hardware decoding, make sure the loop filter is not skipped, and remux or re-encode the file with a keyframe every two seconds if needed.