Block-based prediction: MB, CTU, SB и superblocks

TL;DR

Каждый современный видеокодек сжимает кадр примерно одинаково: он разбивает кадр на прямоугольники, предсказывает каждый из них по соседним блокам или по предыдущим кадрам и записывает в поток лишь небольшую разницу – остаток. Такой прямоугольник называют macroblock в H.264, coding tree unit (CTU) в HEVC и VVC, а также superblock (SB) в VP9, AV1 и черновике AV2. Единственная существенная разница между кодеками – в том, насколько гибко они могут делить этот прямоугольник дальше. H.264 зафиксировал размер macroblock на уровне 16×16; HEVC увеличил его до 64×64 с использованием квадродерева; AV1 пошёл дальше – до 128×128 с 10-уровневым деревом разбиений; VVC и AV2 добавили тернарные, бинарные и асимметричные варианты разбиения, чтобы дополнительно сэкономить 10–30% битрейта. Статья объясняет, что блок – это универсальная единица работы внутри энкодера, которую меняла каждая новая генерация кодеков, и почему компромисс между размером блока и временем кодирования – это ключевой выбор, определяющий до 80% эффективности сжатия.

Зачем это знать

Если вы разрабатываете стриминговый продукт, ваша команда потратит на настройку блочного разбиения больше времени, чем на любую другую опцию энкодера, потому что решение о разбиении одновременно определяет и выходной битрейт, и реальное время кодирования. Счета за облачный транскодинг, бюджеты задержки в live-стриминге, кривые «качество против стоимости» – всё это зависит от того, какой размер блока выберет энкодер. Продакт-менеджер, понимающий, что «энкодер ищет в дереве прямоугольников», читает бенчмарк вендора, задаёт правильные вопросы о выборе пресета и не удивляется, когда быстрый пресет требует на 25% больше битрейта. Основатель, который на совещании по дорожной карте кодеков может спросить: «А почему мы всё ещё используем 16×16 блоки в 2026 году?» – экономит компании месяцы работы с устаревшим кодом.

Кадр – это сетка из прямоугольников

Чтобы сжать кадр, каждый современный кодек начинает с одного и того же действия: накладывает на изображение сетку и обрабатывает каждую ячейку как независимую единицу. Ячейка – это наименьший блок пикселей, который энкодер рассматривает целиком. Внутри одной ячейки энкодер делает одно предсказание (на основе соседей или предыдущего кадра), вычисляет остаток (ошибку после предсказания) и записывает в поток компактное описание.

Представьте, что вы кладёте на стену мозаику. Если на стене ровный синий участок – хватит одной большой плитки. Если на стене лицо – нужны маленькие плитки вокруг глаз и рта и большие – на гладких щеках. Решение о разбиении блоков и есть выбор размера плитки «на лету», по одному кадру: минимум битов – на скучные области, максимум – на сложные.

Стартовый прямоугольник называют по-разному в различных семействах кодеков. В H.264 / AVC это macroblock, сокращённо MB, фиксированного размера 16×16 пикселей яркости. В H.265 / HEVC и H.266 / VVC используется coding tree unit (CTU) – 64×64 в HEVC и 128×128 в VVC. В VP9 и AV1 применяется superblock (SB) – 64×64 в VP9 и 128×128 в AV1. Названия различаются по историческим причинам, но их роль одинакова: это самый большой прямоугольник, который энкодер обрабатывает как единое целое.

Нажмите, чтобы увеличить

Причина, по которой каждая генерация увеличивала размер прямоугольника, проста. Большой верхнеуровневый блок позволяет описать плавный, медленно движущийся участок одним вектором движения и крошечным остатком, вместо шестнадцати или шестидесяти четырёх дублирующих копий одного и того же вектора. Кадр 4K, сжатый с помощью macroblocks H.264 размером 16×16, содержит 32 400 macroblocks на кадр; тот же кадр, сжатый с помощью superblocks AV1 размером 128×128, – всего 2 025 superblocks на кадр, то есть в пятнадцать раз меньше верхнеуровневых блоков. Накладные расходы на каждый блок накапливаются быстро: чем меньше блоков – тем меньше оверхеда.

Macroblock – H.264 / AVC

Macroblocks были определены в H.261 в 1988 году и без изменений унаследованы MPEG-1, MPEG-2, MPEG-4 Part 2 и H.264. Macroblock всегда составляет 16×16 пикселей яркости, плюс два блока 8×8 цветности при формате сэмплирования 4:2:0 – о цветовой дискретизации мы подробно писали в статье про цветовые пространства.

В H.264 изменился не размер макроблока, а степень свободы внутри него. Более ранние кодеки требовали одного предсказания на макроблок. H.264 позволил разбивать макроблок на подблоки для компенсации движения:

• 16×16 – один вектор движения на весь макроблок.
• 16×8 или 8×16 – по одному вектору на каждую из двух половин.
• 8×8 – по одному вектору на каждую из четырёх четвертей.
• Внутри каждой четверти 8×8: 8×4, 4×8 или 4×4 – до шестнадцати векторов в одном макроблоке.

Это называется tree-structured motion compensation, потому что варианты разбиваются по двухуровневому дереву. Энкодер выбирает самый дешёвый вариант с помощью процесса под названием rate-distortion optimization, или RDO – о нём мы подробно рассказываем в статье про mode decision и RDO. Пока достаточно понимать: энкодер работает как поисковый движок – перебирает разбиения, оценивает стоимость каждого и оставляет наименее затратный.

Потолок 16×16 для macroblock устарел. Современный контент – 1080p, 4K, HDR – часто содержит большие однородные участки, которые можно описать одним вектором на 64×64. H.264 не может этого сделать: ему приходится повторять один и тот же вектор в шестнадцати macroblocks. Это главная причина, по которой H.264 проигрывает 30–50% битрейта современным кодекам 2026 года на том же контенте.

CTU и квадродерево – HEVC / H.265

HEVC, завершённый в 2013 году, сохранил идею макроблоков, но отказался от фиксированного размера 16×16. На смену пришёл новый верхний прямоугольный блок – coding tree unit (CTU) размером 16×16, 32×32 или 64×64. Почти все реальные HEVC-энкодеры используют размер 64×64.

Внутри CTU HEVC использует квадродерево (quadtree) – рекурсивную структуру разбиения, в которой любой квадратный блок можно разделить на четыре равные четверти, а каждую из них – снова, до минимального размера 8×8. Блок CTU 64×64 соответствует глубине 0, а лист 8×8 – глубине 3.

Представьте, что CTU – это торт размером 64×64. Его можно съесть целиком, а можно разрезать на четыре куска по 32×32 и для каждого решить, резать ли дальше. Если кусок однородный – оставляем его целым. Если на нём мелкая текстура – режем на четыре подкуска по 16×16 и так далее. Энкодер выбирает наиболее выгодное дерево разбиения с помощью RDO.

Почему это работает: на небе в формате 4K HDR можно описать целый блок 64×64 одним вектором движения и почти нулевым остатком. На лице в том же кадре энкодер дойдёт до блоков 8×8 вокруг глаз, где каждый пиксель меняется от кадра к кадру, и оставит 32×32 на щеке, где движение однородное. Общая стоимость в битах оказывается значительно ниже, чем если бы энкодер использовал блоки 8×8 по всему кадру, при этом качество остаётся идентичным.

Цена – время кодирования. Полный RDO-поиск на глубине 3 в HEVC оценивает 1 + 4 + 16 + 64 = 85 кандидатов разбиения на CTU, не считая выбора режимов предсказания внутри каждого. Умножьте это на 32 400 ÷ 64 ≈ 510 CTU на кадр 1080p, затем на 60 кадров в секунду для трансляции в реальном времени – и получится 26 миллионов оценок разбиения в секунду. Реальные энкодеры используют методы ранней остановки: если разбиение 32×32 уже достаточно хорошее, они не углубляются дальше. Но полный поиск остаётся теоретическим пределом качества.

Почему 64×64 оказался оптимальным выбором, а не 128×128: исследования HEVC показали, что 64×64 обеспечивают 95% эффективности больших блоков при разрешении 1080p, а оставшиеся 5% выигрыша не оправдывают возросшей сложности. AV1 и VVC всё же выбрали большие размеры блоков, поскольку к 2018 году доминирующие разрешения сместились в сторону 4K и 8K.

Нажмите, чтобы увеличить

Superblock и 10-вариантное дерево – VP9 и AV1

VP9, завершённый в 2013 году одновременно с HEVC, ввёл термин superblock для обозначения той же концепции – размером 64×64. Его структура разбиения оказалась проще, чем у чистого квадродерева HEVC: superblock мог делиться на четыре подблока 32×32 (классический разбиение по квадродреву) или на две горизонтальные или вертикальные половины – вплоть до 8×8 (при этом 4×4 зарезервированы под специальные случаи intra). Такой подход, сочетающий четыре + горизонтальные/вертикальные разбиения, иногда называют partial quadtree или R-shaped tree.

AV1, завершённый AOMedia в марте 2018 года, отказался от идеи superblock из VP9 и сделал три ключевые отличия. Во-первых, максимальный размер был удвоен – до 128×128. Во-вторых, количество вариантов разбиения увеличено с четырёх до десяти. В-третьих, введены асимметричные разбиения – три прямоугольника вместо четырёх квадратов – чтобы эффективнее обрабатывать T-образные границы текстур, с которыми квадродеревья справляются плохо.

Полный набор разбиений AV1 для одного блока, который поддерживает все из них:

• PARTITION_NONE – оставить блок без изменений.
• PARTITION_HORZ – две горизонтальные половины (верхняя и нижняя).
• PARTITION_VERT – две вертикальные половины (левая и правая).
• PARTITION_SPLIT – четыре равных квадранта (классическое разбиение по типу quadtree). Только этот вариант поддерживает рекурсивное деление.
• PARTITION_HORZ_A – три прямоугольника: два узких сверху и один широкий снизу.
• PARTITION_HORZ_B – три прямоугольника: один широкий сверху и два узких снизу.
• PARTITION_VERT_A – три прямоугольника: два узких слева и один высокий справа.
• PARTITION_VERT_B – три прямоугольника: один высокий слева и два узких справа.
• PARTITION_HORZ_4 – четыре тонкие горизонтальные полосы (соотношение 4:1).
• PARTITION_VERT_4 – четыре тонкие вертикальные полосы (соотношение 1:4).

Четыре T-разбиения – главный трюк. Лицо в профиль, граница здания на фоне неба, вертикальная кромка текста – это паттерны контента, которые квадродерево вынуждено описывать тремя блоками неправильной формы, а AV1 улавливает одним решением. На типичном контенте T-разбиения и 4-полосные вместе дают 3–5 % выигрыш по битрейту AV1 над VP9 при одинаковой фиделити.

Есть ограничения. Блоки размером 128×128 и 8×8 не могут использовать разбиения 4:1 и 1:4. Блоки 8×8 вообще не допускают никаких T-разбиений. Прямоугольные разбиения, применённые один раз, нельзя делить дальше – рекурсивно можно делить только квадратный тип PARTITION_SPLIT. Поэтому дерево разбиений в AV1 иногда называют constrained 10-way recursive tree, а не свободным графом разбиений: ограничения введены, чтобы декодер оставался управляемым.

Нажмите, чтобы увеличить

QT + MTT и тернарный split – VVC / H.266

VVC, завершённый JVET в июле 2020 года как H.266, выбрал четвёртый путь. Верхний уровень кодирования – CTU 128×128, как в AV1. Структура разбиения – квадродерево с вложенным multi-type tree, обычно сокращаемое до QT + MTT или QTMT.

Разбиение выполняется в две фазы. Сначала CTU рекурсивно делится квадродеревом на более мелкие квадраты – та же рекурсия, что и в HEVC. Затем каждый лист квадродерева может быть дополнительно разделён multi-type tree (MTT), который добавляет пять вариантов:

• Без разбиения – лист квадродерева является финальным кодовым блоком.
• Бинарный горизонтальный split – деление на две горизонтальные половины.
• Бинарный вертикальный split – деление на две вертикальные половины.
• Тернарный горизонтальный split – три горизонтальные полосы в пропорции 1:2:1.
• Тернарный вертикальный split – три вертикальные полосы в пропорции 1:2:1.

Тернарный 1:2:1 – это новая геометрическая идея, предложенная VVC. Во многих реальных изображениях границы текстур проходят на отметках 1/4 или 3/4 блока, а не посередине, на 1/2. Бинарное разделение ставит границу не туда, а тернарное – точно. Благодаря этому тернарное разделение даёт VVC ещё 3–7 % выигрыша в битрейте по сравнению с чистым бинарным деревом на том же контенте.

Геометрическая гибкость достигается ценой времени. Энкодер VVC должен оценить полную QT-рекурсию, все пять MTT-вариантов и их комбинации. Исследования по снижению сложности показывают, что исчерпывающий поиск разбиений в VVC в 5–10 раз медленнее, чем в HEVC, при обработке того же контента, причём основную часть времени занимает MTT. Поэтому внедрение VVC происходит медленнее, чем у любого современного кодека: даже на специализированном кремнии создать real-time энкодер крайне сложно.

VVC, как и AV1, разделяет дерево разбиения для luma и chroma в intra-слайсах – эта функция называется dual tree и позволяет chroma использовать более крупные блоки там, где luma разбивается на мелкие. Это даёт выигрыш в 1–2% битрейта на HDR и 10-битном контенте, где chroma естественным образом более гладкая, чем luma.

Таблица 1. Дизайн блочного разбиения в современных видеокодеках. Сложность энкодера приведена для full-search референсных энкодеров; продакшен-энкодеры (x265, libaom, VTM) снижают её в 5–50 раз за счёт early-termination, теряя 1–3 % качества.

Почему большие блоки выигрывают на высоком разрешении

Простое правило из теории сжатия: чем больше избыточная область в изображении, тем больший блок может её эффективно описать. До 720p большинство избыточных областей не превышают 64×64 пикселей, потому что камера агрессивно сглаживает входной сигнал – блоки 16×16 захватывают основную часть выигрыша. На 1080p уже блоки 64×64 дают больший эффект. На 4K один блок 128×128 может описать пятисантиметровый участок кожи или неба одним вектором движения и почти нулевым остатком.

Конкретное число: бенчмарки NETINT 2024 на 4K 60fps HDR-корпусе показали, что AV1 с суперблоками 128×128 выигрывает у AV1, принудительно ограниченного 64×64, по 4,8 % битрейта при одинаковом VMAF – исключительно за счёт эффективности больших блоков. Та же пара сравнений на 1080p SDR даёт всего 1,1 % разницы, поскольку избыточных участков больше нет.

Следствие: чем выше разрешение и битовая глубина, тем дороже обходится отсутствие больших блоков. Поэтому в черновике AV2 на май 2026 года в некоторых конфигурациях блоки расширены до 256×256 для 8K и высокой частоты кадров. По той же причине аппаратные энкодеры H.264 для камер 4K практически исчезли из новых продуктовых линеек – стоимость реализации макроблоков становится слишком высокой на современных разрешениях.

Энкодер – это поисковый движок. Практическая цена

Каждая история про блочное разбиение заканчивается на одном и том же: энкодер ищет. Чем больше дерево разбиения – тем больше объём поиска, тем дольше кодирование и тем выше стоимость секунды видео.

Рабочий пример. Энкодер x265 на пресете medium, кодирующий 4K HDR на современном CPU, обрабатывает примерно 8 кадров в секунду в реальном времени. Тот же контент с x265 на placebo – самом медленном пресете, при котором выполняется почти исчерпывающий перебор вариантов разбиения – обрабатывается со скоростью около 0,4 кадра в секунду, то есть в двадцать раз медленнее, ради дополнительных 4–7% эффективности по битрейту. Тот же контент с libaom-av1 при cpu-used=2 обрабатывается со скоростью около 0,6 fps; при cpu-used=6 – уже около 30 fps, но с увеличением битрейта на 12–18%.

Компромисс жёсткий и неизбежный: каждый шорткат пресета – это разбиение, которое энкодер не оценил. Шорткат может быть таким: «если RD-стоимость родительского блока низкая – не углубляться дальше» или «если в предыдущем кадре здесь был выбран блок 32×32 – попробуй сначала 32×32 и завершай работу заранее, если результат удовлетворительный». Это и есть early termination-эвристики, которыми наполнены современные энкодеры. Именно эта область остаётся одной из самых активных в академических исследованиях 2024–2026 годов, где решения о разбиении, управляемые нейросетями, становятся стандартом в облачных транскодинг-пайплайнах.

Практические рекомендации для стримингового продукта:

• Для VOD, который кодируется один раз и транслируется миллионы раз – выбирайте самый медленный пресет, укладывающийся в бюджет. Каждый процент сэкономленного битрейта умножается на количество зрителей.
• Для live, который кодируется один раз и просматривается один раз – выбирайте самый быстрый пресет, способный обеспечить требуемое качество. Задержка и нагрузка на CPU важнее эффективности кодирования.
• Для ABR-лесенок (читать дальше) – верхняя ступень (самое высокое качество, которое вы отдаёте) должна использовать более медленный пресет, чем нижняя, потому что зрители этой ступени потребляют больше всего данных.

Типичная ошибка – форсировать маленькие CTU/superblocks на современном контенте

Удивительно, но множество продакшен-пайплайнов сознательно ограничивают размер CTU или суперблоков значениями 32×32 или 16×16, полагая, что это экономит время кодирования. На деле это работает наоборот. Маленькие верхнеуровневые блоки вынуждают энкодер генерировать больше заголовков блоков, векторов движения и сигналов разбиения кадра, а RDO-поиск по плоской структуре из множества мелких блоков не быстрее глубокого анализа меньшего числа крупных. В результате – штраф в 5–10% битрейта при неизменном качестве, без какой-либо экономии времени кодирования. Если в вашем пайплайне есть флаг --ctu-size 16, обязательно проведите аудит. Скорее всего, эта настройка сохранилась с тех пор, как давно ушедший инженер перенёс её из конфига H.264 эпохи 2010 года и с тех пор никто не пересматривал это предположение.

Где здесь Фора Софт

Мы разрабатываем код блочного уровня для энкодеров, настраиваем шорткаты разбиения в x264 / x65 / libaom / VPP и поставляем облачные транскодинг-пайплайны с 2005 года – для видеостриминга, OTT и Internet TV, видеоконференций, e-learning, телемедицины, видеонаблюдения и AR/VR. Наши команды разбираются и в «желе» – Nvidia NVENC, Intel QSV, NETINT VPU, AMD VCE, кастомные FPGA, – и в эвристиках разбиения софтверных энкодеров, лежащих в основе выбора каждого пресета. Когда клиент просит сократить счёт AWS Elemental на 30% без потери VMAF, ответ почти всегда кроется в дереве разбиения.

Ключевое

• Современные кодеки сжимают кадры, разбивая их на прямоугольники и предсказывая каждый из них отдельно – различие заключается лишь в способе разбиения.
• Верхний уровень блока называется macroblock (в H.264 – 16×16), CTU (в HEVC – 64×64, в VVC – 128×128) или superblock (в VP9 – 64×64, в AV1 – 128×128).
• Крупные верхнеуровневые блоки экономят битрейт при высоком разрешении: один вектор движения описывает большой однородный участок.
• AV1 использует 10-уровневое дерево разбиения с T-образными и 4-полосными разбиениями; VVC применяет квадродерево, вложенное в многотипное дерево с тернарным разбиением.
• Поиск оптимального разбиения – основной фактор, влияющий на время кодирования; каждый шорткат пресета означает, что энкодер не оценивал определённое разбиение.
• Ограничение размера CTU или superblock на современном контенте влечёт штраф в 5–10% битрейта без какой-либо экономии времени; проверьте конфигурацию на наличие устаревших флагов.

Что читать дальше

• GOP-структура: I, P, B-кадры, открытые и закрытые GOP
• Принятие решений о режиме и оптимизация соотношения скорости и искажений (RDO)
• Внутрикадровое кодирование: как сжимается один кадр