The Frame That Can't Keep Up
You're watching a goalkeeper dive full-stretch across the frame. The slow build-up looked practically cinematic. Then the camera snaps to follow him, and the picture turns into a mosaic of muddy squares, like someone laid a bathroom tile grid over the broadcast. Half a second later it's sharp again. You didn't lose your connection. Your internet speed didn't drop.
Something else entirely just happened.
That something is temporal prediction: the engine that makes modern video streaming possible and the exact reason it falls apart on fast movement.
The Trick Every Codec Uses
Video compression would be laughably impractical without one key insight: most of a video frame is nearly identical to the frame before it. A talking head against a wall doesn't change much between frame 1 and frame 2. So instead of storing every pixel of every frame, codecs like H.264 and H.265 store a full reference frame (called an I-frame) and then, for the next several frames, store only what changed. Those change-only frames are called P-frames and B-frames.
Here's the mechanic in plain terms. The encoder looks at a 16x16 pixel block in the new frame, searches for where that block came from in the previous frame, and records a motion vector: essentially an instruction that says "take that block, move it 8 pixels right and 3 pixels down, and that's your new image." The actual pixel data for that block doesn't need to be stored. Just the instruction.
That's the compression. That's why a two-hour film fits on a streaming server at a watchable bitrate.
The whole system is elegant, almost suspiciously so. Until something in frame moves faster than the encoder expected.
When the Motion Vector Has Nowhere to Go
Back to that goalkeeper. In one-thirtieth of a second, his body has moved 200 pixels horizontally. The encoder searches its reference frame for a matching block and finds nothing useful: he was somewhere completely different, the background behind him has changed, and the pixels the encoder needs simply don't exist in a convenient, reusable form.
So it falls back on encoding actual pixel data for that region. But the bitrate budget for that moment is already set. Streaming services allocate bits across a scene based on predicted complexity, and a sudden burst of high-motion content demands far more data than the system planned for.
The encoder has two choices. Spend more bits than budgeted, which causes a buffer stall you'd notice as a freeze, or reduce the quality of those residual pixels to hit the target bitrate anyway. It almost always chooses the second. The quality reduction shows up as blocking artifacts: those chunky 8x8 or 16x16 pixel squares. Block boundaries become visible because neighboring blocks were encoded independently, at low quality, with no attempt to smooth the seams.
That's the mechanism. Not your router, not the server. The math ran out of budget mid-dive.
Two People, Same Show, Different Experience
Consider two people watching the same action film on the same platform. Priya has a 50 Mbps connection; Marcus has 12 Mbps. Both are comfortably above the minimum for HD. The platform's adaptive bitrate system has given Priya a stream encoded at around 8 Mbps and Marcus one at 4 Mbps.
During a quiet conversation scene, both streams look identical to the naked eye. Then comes a rapid fight sequence: camera cuts every two seconds, bodies crossing the full frame, quick pans. Priya sees brief softness, maybe a flicker. Marcus sees the full mosaic effect, four or five frames of obvious blockiness on every hard cut. His encoder is working with half the bit budget and making far more aggressive quality tradeoffs to keep the stream moving at all.
Same content. Same scene. The gap only showed up when the compression had nowhere to hide.
What People Get Wrong About This
The folk remedy that needs to die: restarting your router when you see artifacts during an action scene. Your network is almost certainly fine. Artifacts appear in fast motion specifically because of how the video was encoded, not because data packets dropped mid-stream. If your connection were actually struggling, you'd see buffering, resolution drops across the whole picture, or audio sync issues. Blocky artifacts isolated to fast-moving objects while the static background stays sharp? That's a codec signature, not a network failure.
The other misconception is that higher resolution fixes it. It doesn't. A 4K stream with an aggressive compression target can look worse on fast motion than a well-encoded 1080p stream with a generous bitrate, and anyone who tells you otherwise is selling you a spec sheet. Resolution and bitrate are separate dials. What you actually want is a higher per-frame bitrate, which is usually tied to the quality tier your platform has selected for you. On most services, you can force the highest quality tier manually in settings. That won't eliminate the artifact, but it shrinks it considerably.
Newer codecs help too. H.265 (HEVC) and AV1 handle motion better than H.264, using more sophisticated prediction models that track complex movement across larger areas. Still, they're working on the same fundamental problem, just with sharper tools.
The Part Most Guides Skip
The encoder doesn't just react to motion. It tries to predict it. Before encoding a scene, many encoders run a lookahead pass, scanning upcoming frames to pre-allocate bits to complex moments. A well-tuned encoder sees the dive coming and banks extra bits for it. A poorly tuned one, or one under a tight real-time constraint like a live sports stream, doesn't have time for that luxury.
This is why live sport almost always looks worse than a pre-encoded film on the same platform at the same bitrate. The film was encoded offline, with full lookahead, possibly multiple encoding passes, and a human quality check. The match is being encoded right now, under latency pressure, with no time to second-guess anything.
So the next time a crucial goal gets swallowed by a wall of grey squares: you're not watching technology fail. You're watching it succeed at an extremely hard real-time constraint problem, at the exact moment that problem became hardest. Which, frankly, is impressive. Even if it's also genuinely annoying.