A CTU — Coding Tree Unit — is the basic chunk of pixels HEVC works with, much like JPEG works on 8×8 squares. The crucial twist: a CTU can be up to 64×64 pixels, four times larger than the fixed 16×16 macroblock used by H.264. The encoder then recursively splits each CTU into smaller pieces — 32×32, 16×16, all the way down to 8×8 or 4×4 — wherever the picture needs finer detail.
Why this matters: larger flat areas (sky, walls, out-of-focus backgrounds) can now be coded as one big 64×64 block instead of sixteen 16×16 macroblocks. Less header overhead, less mode-decision computation, and a much more compact bitstream. Conversely, fine-detail areas (eyes, hair, text overlays) can be coded as tiny 4×4 blocks for precision. The encoder picks the split level per region using rdo (rate-distortion optimisation) — it tries different splits and keeps the one with the best quality-vs-size trade-off. This adaptive partitioning is a big chunk of HEVC's ~50 % efficiency win over H.264.
The same idea, taken further, gives AV1 its superblock of 128×128 with even more flexible non-square splits, and VVC its even-larger CTU with rectangular partitions. None of this affects the workflow of a non-technical product team — it's all invisible inside the codec — but it explains why each codec generation needs more compute to encode and why hardware encoders specifically advertise their CTU support.
