Motion Estimation Simulator

Simulate inter-frame motion estimation, block matching, search patterns, and compression residuals.

Worked example — Motion Estimation Simulator

Average SAD per Block	1693
Average Vector Magnitude	1.54 px
Points Searched per Block	14400 points (225.0 per block)

These are the values the calculator shows when the page opens. Change any input above to recompute them.

Loading interactive simulation...

Fast search never looks at most of the window 🖖

Motion estimation is the bottleneck of video compression. A macroblock of size 16x16 is matched against the reference frame in a search window to find the candidate with the lowest Sum of Absolute Differences (SAD). Exhaustive Full Search evaluates all (2r+1)² positions, which is slow. Fast algorithms like Diamond and Hexagon search evaluate only a fraction of points by moving the search center iteratively, terminating when the minimum is at the center of the pattern. Hover over any block to see its search window and candidate evaluations in real time.

Why send motion, not pixels 🖖

Consecutive video frames are almost identical, so instead of storing each frame in full, a codec describes the current frame as pieces of the previous one that have shifted. Each 16×16 block gets a motion vector pointing to its best match, plus a small residual holding whatever the shift couldn't explain. Smooth camera pans compress beautifully, because a single vector replaces thousands of pixels.

Motion vectors aren't really motion 🖖

The encoder never asks what actually moved — it only hunts for the block that minimises SAD. So on flat or noisy regions the winning vector can point somewhere absurd, nothing like the true displacement. Raise the noise slider and watch the vector field scatter into nonsense. This is why motion vectors make a poor optical flow, yet perfect compression: they serve bitrate, not physics.

ONE STAGE OF A CHAIN — WHAT ARRIVES, WHAT LEAVES, WHAT BREAKS DOWNSTREAM

Where This Sits In The Encoding Pipeline

A video encoder is not one algorithm but eight stages in a fixed order, and the order is not arbitrary: each stage exists because the one before it made its job possible. This tool models one of them. The chain below links to the other seven.

Motion Estimation Simulator — finds where each block moved to, then codes the difference instead of the block

What arrives: A P or B frame together with its reference frames.
What leaves: A motion vector per block, and a residual — precisely what the prediction got wrong.
What the next stage assumes: Quantization receives a residual, not a picture. Residuals sit close to zero almost everywhere, which is exactly why quantizing them is cheap.
What goes wrong here: A poor match does not produce a wrong picture, it produces an expensive one. The residual carries more energy, and the same quantizer setting then emits more bits for it. This stage changes the size of the output rather than any of its settings.

Previous stage: GOP structure Next stage: Quantization

Problem solved in full

The search window derived from 225 positions per block 5 steps
A full motion search checks 225 positions per block, 14 400 in total. Work out the search window from that, and what a fast search buys.
1. 225 is a perfect square, and that is the clue: the search is a square window of 15 by 15 candidate displacements, which means −7 to +7 pixels in each direction.
  
  $full search over \pm 7 px in each axis : 15 \times 15 = 225 positions per block$
2. Dividing the total by the per-block count gives the number of blocks the frame was cut into.
  
  $\frac{14 400}{225} = 64 blocks$
3. The cost grows with the square of the search radius, so widening the window is expensive fast: radius 7 costs 225 positions, radius 15 costs 961, radius 31 costs 3969.
  
  $cost \propto (2 R + 1)^{2} : R = 7 \Rightarrow 225, R = 15 \Rightarrow 961, R = 31 \Rightarrow 3969$
4. That quadratic is why fast searches exist. A three-step search samples nine points, refines, and repeats — 27 positions instead of 225.
  
  $three-step search : 3 stages \times 9 points = 27$
5. Eight times cheaper, and not equivalent: it descends toward a local minimum and can walk past the true best match if the error surface has more than one dip.
  
  $\frac{225}{27} = 8.3 \times fewer, and it can miss the true minimum$
Answer

The tool prints 14400 points searched at 225.0 per block. The trade is the whole of practical video encoding: full search is optimal and quadratic in the radius, so every encoder ships a heuristic instead and accepts occasionally choosing a worse vector. You can see half the cost of being wrong in the Residual Energy (MSE) row: a bad vector leaves a larger residual, and a larger residual is more data to code. Fast motion search is not an approximation to save time in the abstract; it is a bet that the bits lost to imperfect vectors are fewer than the bits you could spend elsewhere.

$full search is O (R^{2}) per block; fast searches trade optimality for 8 \times$

References (2)

Block matching and motion vectors as the standard uses them: T. Wiegand, G. J. Sullivan, G. Bjontegaard and A. Luthra, "Overview of the H.264/AVC video coding standard." IEEE Transactions on Circuits and Systems for Video Technology 13(7), 560–576, 2003.
The diamond search this tool implements alongside full search: S. Zhu and K.-K. Ma, "A new diamond search algorithm for fast block-matching motion estimation." IEEE Transactions on Image Processing 9(2), 287–290, 2000.

By the 42Math team · Updated 2026-05-29

Reviewed against published sources. Corrections welcome. Editorial policy · Corrections

All Computing lessons →

Example problems

Slow Pan - Slow horizontal pan: near-zero residual, motion vectors point uniformly right
Fast Pan - Fast pan: larger SAD at search boundary, high-energy border residuals
Diverging zoom - Zoom-in motion: diverging vectors from centre, no single translation vector fits
Noisy handheld camera - Noisy camera: high SAD despite correct vectors — noise energy dominates residual