Содержание статьи +
- TL;DR
- Почему это важно
- Почему один кадр нельзя закодировать как единый блок
- Slices – оригинальный ответ H.264
- Tiles – прямоугольные регионы HEVC
- Wavefront Parallel Processing – диагональный трюк
- Tiles AV1 – сетка по степеням двойки
- Subpictures – вклад VVC
- Где здесь Фора Софт
- Типичная ошибка – копировать настройки VOD в live
- Ключевые выводы
- Что читать дальше
TL;DR
Современные видеокодеки делят каждый кадр на независимые области, чтобы несколько ядер CPU или аппаратных движков могли работать над одним кадром одновременно. В H.264 эти области называются slices, в HEVC и VVC к ним добавляются tiles и wavefronts, а в AV1 используются tiles, расположенные сеткой по степеням двойки. Выбор между slices, tiles и wavefronts – это главная ручка, которая отвечает за компромисс между скоростью кодера и эффективностью сжатия на многоядерных машинах: типичный выигрыш по wall-clock составляет от трёх до десяти раз ценой одного–двух процентов битрейта. Если настроить правильно – 4K live-кодирование помещается в одну машину; если нет – либо не успеваете в реальное время, либо тратите биты, которые должны были остаться в кошельке зрителя.
Почему это важно
Если ваш сервис стримит live, перекодирует back-catalogue или работает WebRTC в масштабе, скорость кодеров определяется тем, насколько хорошо они параллелятся по ядрам CPU или шейдерам GPU. Продакт-менеджер, который понимает, что «кодер режет каждый кадр на куски и пускает их на разные ядра», сможет прочитать бенчмарк вендора и задать правильный вопрос: сколько колонок tile-сетки, какой режим slice, включён ли WPP. Основатель, который может оспорить «почему мы платим за 64 ядра на поток», скоро узнает, что кодер настроен на один slice и оставляет 40 ядер простаивать. Технический лид, который строит live-пайплайн на tiles вместо slices, экономит треть счёта при том же качестве картинки.
Почему один кадр нельзя закодировать как единый блок
Чтобы превратить кадр в биты, кодер принимает тысячи мелких решений: какой режим предсказания использовать для этого прямоугольника, из какого предыдущего кадра копировать пиксели, сколько бит потратить на эту область. Сами прямоугольники – макроблоки, coding tree units и superblocks – мы разобрали в статье про block-based prediction. Естественный порядок чтения – слева направо, сверху вниз, то есть так же, как вы читаете эту страницу.
Проблема такого порядка в том, что каждый блок зависит от соседей. Блок в позиции (5, 3) нельзя закодировать, пока не готов блок (4, 3) слева – кодер может скопировать из него пиксели или предсказание. Блок (5, 3) также нуждается в строке выше, потому что часть режимов предсказания смотрит вверх. Эта цепочка зависимостей означает, что один кадр 4K на 60 fps вынужден протекать через одно ядро, по одному блоку за раз – а одного ядра не хватит.
Резать кадр на куски, которые поедут на разные ядра, кажется просто, но сжатие имеет цену. Два соседних блока, которые делятся информацией, сжимаются вместе эффективнее, чем два посторонних. В момент разрыва связи приходится тратить лишние биты, чтобы повторить то, что и так знал соседний блок. Задача slices, tiles и wavefronts – разорвать связь в самом дешёвом месте: потерять минимум сжатия за максимум параллелизма.
Slices – оригинальный ответ H.264
Slices были определены ещё в H.261 в 1988 году и пережили в неизменном виде путь до H.264. Slice – это последовательность подряд идущих блоков (в порядке слева направо, сверху вниз), которая кодируется так, как будто других slices не существует. Внутри одного slice блоки ссылаются друг на друга; через границу slice – нет.
Изначальная цель slices – не параллелизм. Это потери пакетов. Если 1500-байтный сетевой пакет теряется по пути к декодеру, декодер теряет один slice, а не весь кадр, и может чисто восстановиться со следующего slice-заголовка. Именно поэтому broadcast- и contribution-ингесты до сих пор используют multi-slice кодирование – даже когда кодер быстр на одном ядре, сеть всё равно недостаточно надёжна.
Параллельная обработка идёт бонусом. Если приказать H.264-кодеру использовать четыре slices, четыре ядра смогут кодировать четыре области slice бок о бок. Цена проявляется в двух местах. Во-первых, цепочка предсказаний рвётся на каждой границе slice, поэтому однородные области, пересекающие две slices, теряют от одного до трёх процентов эффективности сжатия. Во-вторых, каждый slice несёт собственный заголовок с параметрами квантования, индексами референсов и состоянием энтропийного кодера – обычно 30–80 бит на slice. На кадре 1080p с 32 slices накладные расходы заголовков дают около двух килобит на кадр, что на 30 fps превращается в 60 Kbps чистой бюрократии.
H.264 позволяет кодеру формировать slices двумя способами. Простой – raster-scan slices: кодер выбирает число макроблоков на slice и режет после этого количества в порядке чтения. Гибкий – flexible macroblock ordering, сокращённо FMO, который позволяет кодеру задать произвольную карту того, какой макроблок к какому slice относится; это полезно для region-of-interest стриминга, где движущемуся объекту даётся отдельный slice. FMO так и не прижился в массовых продуктах, потому что большинство потребительских декодеров реализуют его медленно или вообще никак.
Tiles – прямоугольные регионы HEVC
HEVC, утверждённый в 2013 году, сохранил slices ради защиты от потерь пакетов и добавил отдельную концепцию для параллелизма – tiles. Tile – это ячейка прямоугольной сетки на кадре. Кодер выбирает число tile-колонок и tile-строк; результат – регулярная сетка независимых прямоугольников.
Преимущества tiles над slices для параллельной работы – чисто механические. Tiles квадратные или близки к квадратным – разрывы предсказаний короткие относительно площади внутри, поэтому потери сжатия на tile меньше, чем на slice той же площади. Tiles всегда режут по линиям блочной сетки и упаковываются в прямоугольный layout, так что кодер может назначить один tile на одно ядро без логики балансировки нагрузки.
Цена – немного сжатия и немного гибкости. Резка кадра на четыре tiles в формате 2×2 обычно стоит 0.5–2.0 процента битрейта при том же VMAF, в зависимости от контента. Спорт и концерты с движением через весь экран платят больше; однотонные фоны и статичные студийные сцены – меньше. Tiles должны быть прямоугольными и не меньше 64×64 luma-пикселей, так что кадр 1080p поддерживает максимум около 30 колонок × 17 строк HEVC tiles – с большим запасом для любого практического числа ядер.
Экспериментальное исследование на 12-ядерном HEVC-кодере 3.33 ГГц показало средний speedup 9.3× на 4K-последовательностях при использовании tiles по сравнению с однотайловым baseline (Fraunhofer HHI, 2015). То же исследование зафиксировало 8.7× для wavefronts на той же машине – настолько близко, что выбор между ними диктуется не голой скоростью, а контентом и пайплайном.
Wavefront Parallel Processing – диагональный трюк
HEVC также представил третий режим параллелизма – wavefront parallel processing, сокращённо WPP. WPP оставляет весь кадр одним slice, но сдвигает работу вдоль диагонали.
Правило простое. Строка 0 стартует с колонки 0 и идёт слева направо. Строка 1 не может начаться, пока строка 0 не выдала минимум два coding tree unit'а – строка 1 нуждается в верхнем и верхне-правом соседях. Строка 2 не может начаться, пока строка 1 не выдала два CTU. И так далее. После короткой раскачки в верхнем левом углу все строки кодируются одновременно, продвигаясь синхронно вдоль движущейся диагонали – wavefront.
WPP сохраняет цепочку предсказаний по горизонтали, поэтому потери сжатия малы – около одного процента на типичном контенте. Цена в сжатии возникает только потому, что состояние энтропийного кодера – бегущие таблицы вероятностей, которые использует CABAC (его подробно разбираем в статье про entropy coding) – должно сбрасываться в начале каждой строки.
Speedup ограничен сверху отношением (число строк ÷ 2), потому что диагональная раскачка тратит первые несколько CTU в каждой строке. На кадре 4K с 34 CTU-строками теоретический потолок – 17×; на практике x265 фиксирует speedup по wall-clock 3–5× ценой одного процента битрейта (x265 documentation, 2025). Streaming Learning Center замерил x265 c WPP на 32-ядерной системе и получил 7.3× speedup для одного файла, но всего 9 процентов прироста общей пропускной способности на batch-нагрузках – потому что batch может занять все ядра отдельными файлами.
Tiles AV1 – сетка по степеням двойки
AV1, утверждённый AOMedia в марте 2018 года, сохранил концепцию tiles, но ужесточил грамматику. Кадр AV1 делится на прямоугольную сетку tiles, число которых по каждой оси всегда степень двойки: 1, 2, 4, 8, 16 или 32. Максимум – 64 tiles на кадр.
Жёсткая структура «степень двойки» имеет два бонуса. Она делает синтаксис битстрима компактным – кодер пишет log2 числа колонок и строк двумя короткими полями. Она также подстраивается под то, как декодерное железо планирует работу: сетки по степеням двойки выровнены по cache lines и ширине SIMD-полос.
Стоимость tiles AV1 в битрейте конкурентоспособна с HEVC: сетка 2×2 стоит 0.5–1.5 процента, 4×2 – 1–2 процента. YouTube начал развёртывание AV1 в 2018 году и добавил 8K AV1 в 2020; оба полагаются на tile-параллелизм, чтобы держать времена кодирования адекватными на commodity cloud. Netflix в декабре 2025 сообщил, что 30 процентов его стримов теперь идут на AV1, закодированные с content-aware числом tiles, варьирующимся от title к title.
AV1 определяет также специальный режим large-scale tile для tile-VR и 360-видео, где плеер декодирует только те tiles, что попадают в текущий viewport, а не весь кадр.
| Механизм | Семейство кодеков | Геометрия | Стоимость сжатия (типично) | Практический speedup | Лучше всего для |
|---|---|---|---|---|---|
| Slice (raster) | H.264, HEVC, VVC | Последовательность блоков | 1–3% на 32 slices | 2–4× от числа slices | Защита от потерь пакетов |
| FMO slice | Только H.264 | Произвольная карта | 2–5% | Ограничен поддержкой | Region of interest |
| Tile | HEVC, VVC, AV1 | Прямоугольная сетка | 0.5–2.0% | 5–10× | Multi-core параллелизм |
| WPP wavefront | HEVC, VVC | Весь кадр, ступенчатые строки | ~1% | 3–5× | Скорость одного потока |
| Subpicture | Только VVC | Независимые прямоугольные регионы | 0.5–1.5% | 5–10× | Композитные стримы, ROI |
Таблица 1. Механизмы разрезания кадра для параллельной обработки. Стоимость сжатия зависит от контента (спорт и концерты платят больше; talking head – меньше). Практический speedup замерен относительно baseline на одном ядре на том же контенте.
Subpictures – вклад VVC
VVC, ратифицированный как H.266 в июле 2020, сохранил slices, tiles и WPP из HEVC и добавил четвёртый механизм – subpictures. Subpicture – это прямоугольный регион кадра, который кодируется как самостоятельное маленькое видео – со своим slice-заголовком, своим списком референсов, опционально своим loop-фильтром – и который можно извлечь, заменить или перепаковать без перекодирования.
Сценарий применения – композитный стриминг. Surveillance-продукт, показывающий сетку 4×4 камер, может кодировать каждый tile как subpicture, выдавать в высоком качестве только те subpictures, на которые смотрит оператор, и понижать качество остальных. 360°-VR-плеер может кодировать сферу как сетку subpictures и стримить в полном разрешении только те, что попадают во viewport. HEVC поддерживал аналогичный трюк через motion-constrained tile sets (сокращённо MCTS), но синтаксис subpictures в VVC чище и поддержка декодера встроена в сам стандарт.
Где здесь Фора Софт
В streaming-, surveillance- и conferencing-продуктах, которые мы строим, выбор между slices, tiles и WPP – одно из первых решений, которое мы фиксируем для любого нового пайплайна. Live OTT и remote-production проекты используют HEVC- или AV1-tiles, чтобы держать 4K-60 кодирование в одной машине с предсказуемой задержкой. WebRTC SFU, которые мы поставляем для видеоконференций, используют один slice на кадр – на типичных конференционных разрешениях стоимость задержки от заголовков slice важнее, чем выигрыш параллелизма. Surveillance-проекты, показывающие много камер одной композицией, идут на VVC subpictures или HEVC MCTS, чтобы оператор, увеличивающий одну камеру, не заставлял сервер перекодировать всю сетку.
Типичная ошибка – копировать настройки VOD в live
Команды регулярно берут конфигурацию кодера из VOD per-title encoding и кладут её в live-транскодер. У VOD job – 32 tiles, потому что back-catalogue гоняется на 64-ядерной ноде; у live job – 4 tiles, потому что каждому live-каналу выделено 4 ядра. Запуск VOD-конфига в live-режиме либо морит голодом ядра (большинство tiles простаивает большую часть времени), либо ломает бюджет задержки (кодер ждёт границ tiles, которые приходят поздно). Всегда подгоняйте число tiles под ядра, доступные этому конкретному потоку, а не кластеру.
Ключевые выводы
- Slices, tiles, wavefronts и subpictures – все рвут кадр так, чтобы над ним работали несколько ядер.
- Slices – механизм H.264, сохранённый ради защиты от потерь пакетов; tiles – главный инструмент параллелизма в HEVC и AV1.
- WPP сдвигает строки по диагонали – малая цена в битрейте, speedup одного потока 3–5×.
- Tiles стоят 0.5–2.0% битрейта и дают 5–10× speedup при типичных количествах ядер.
- VVC добавляет subpictures для композитного, ROI- и 360°-стриминга, где регионы нужно подменять на лету.
- Размер tile-сетки выбирайте по ядрам, доступным одному потоку, а не кластеру.