A block is the unit of pixels that a codec processes together. Every modern video codec breaks each frame into a grid of blocks and handles each block somewhat independently — predicting its content, transforming it, quantizing it, encoding it. The size and shape of these blocks is one of the biggest architectural decisions in any codec, and a major source of the compression gains each new codec generation delivers.
The sizes have grown over time. MPEG-2 and H.264 used fixed-size macroblocks of 16×16 pixels — every frame was just a grid of identical squares. HEVC introduced variable-size ctu (Coding Tree Units) up to 64×64, recursively split into smaller blocks where the picture needed more detail. AV1 extended this to 128×128 superblocks, also split recursively. VVC uses CTUs up to 128×128 with extra flexibility for rectangular shapes. The trend is clear: larger blocks for flat regions (sky, walls — saves header overhead), smaller blocks for detailed regions (eyes, text — captures detail precisely).
For a product team, the only place block sizes show up directly is in why each codec generation needs more compute. More flexible block partitioning means the encoder has more options per region — should this be one 64×64 block or four 32×32 blocks or sixteen 16×16 blocks or some asymmetric mix? The encoder evaluates options via rdo (rate-distortion optimisation) and picks the best one, which is computationally expensive but compresses better. That's a recurring trade-off: each codec generation costs more CPU to encode but ships smaller files, and the block partitioning flexibility is where a big chunk of that gain lives.
