Slices, Tiles и параллельная обработка

TL;DR

Современные видеокодеки разбивают каждый кадр на независимые области, чтобы несколько ядер CPU или аппаратных движков могли обрабатывать один кадр параллельно. В H.264 такие области называются slices, в HEVC и VVC к ним добавляются tiles и wavefronts, а в AV1 используются tiles, организованные в сетку по степеням двойки. Выбор между slices, tiles и wavefronts – это ключевой параметр, определяющий компромисс между скоростью кодирования и эффективностью сжатия на многоядерных системах: типичный выигрыш по времени выполнения составляет от трёх до десяти раз при потере всего одного–двух процентов битрейта. При правильной настройке 4K-стриминг в реальном времени легко помещается в одну машину; при неправильной – либо не удаётся уложиться в лимит времени, либо приходится тратить лишние биты, которые зритель мог бы потратить на что-то полезное.

Почему это важно

Если ваш сервис транслирует в прямом эфире, перекодирует архивный контент или работает с 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 кадрах в секунду вынужден обрабатываться последовательно – по одному блоку за раз, – а одного ядра для этого не хватит.

Резать кадр на куски, которые будут обрабатываться на разных ядрах, кажется простым делом, но сжатие имеет свою цену. Два соседних блока, обменивающихся информацией, сжимаются эффективнее, чем два независимых. При разрыве связи приходится тратить лишние биты, чтобы дублировать данные, которые и так известны соседнему блоку. Задача 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-кодеру использовать четыре slice, четыре ядра смогут одновременно кодировать четыре области. Цена такой оптимизации проявляется в двух аспектах. Во-первых, цепочка предсказаний разрывается на границе каждого slice, из-за чего однородные области, пересекающие две slice, теряют от одного до трёх процентов эффективности сжатия. Во-вторых, каждый slice содержит собственный заголовок с параметрами квантования, индексами референсов и состоянием энтропийного кодера – обычно 30–80 бит на slice. На кадре 1080p с 32 slice накладные расходы на заголовки составляют около двух килобит на кадр, что при 30 кадрах в секунду превращается в 60 Кбит/с чистой «бюрократии».

H.264 позволяет кодеру формировать slices двумя способами. Простой – raster-scan slices: кодер задаёт количество макроблоков на slice и разбивает их в порядке чтения. Гибкий – flexible macroblock ordering (сокращённо FMO) – даёт возможность кодеру задать произвольную карту соответствия макроблоков и slices; это полезно для стриминга с выделением области интереса, когда движущемуся объекту выделяется отдельный slice. FMO так и не получил распространения в массовых продуктах, поскольку большинство потребительских декодеров либо реализуют его слишком медленно, либо вообще не поддерживают.

Tiles – прямоугольные области в HEVC

HEVC, утверждённый в 2013 году, сохранил slices для защиты от потерь пакетов и ввёл отдельную концепцию параллелизма – tiles. Tile – это ячейка прямоугольной сетки на кадре. Кодер выбирает количество колонок и строк tiles; в результате получается регулярная сетка независимых прямоугольников.

Преимущества тайлов перед слайсами при параллельной обработке носят чисто механический характер. Тайлы – квадратные или близкие к квадрату, поэтому разрывы между предсказаниями относительно невелики по сравнению с площадью внутри тайла, а значит, потери при сжатии на тайле меньше, чем на слайсе той же площади. Кроме того, тайлы всегда вырезаются по линиям блочной сетки и упаковываются в прямоугольный макет, что позволяет кодеру назначить один тайл на одно ядро без необходимости в логике балансировки нагрузки.

Цена – небольшое сжатие и небольшая потеря гибкости. Разделение кадра на четыре тайла в формате 2×2 обычно требует 0,5–2,0 процента дополнительного битрейта при неизменном VMAF – в зависимости от контента. Спорт и концерты с активным движением по всему экрану «платят» больше; однотонные фоны и статичные студийные сцены – меньше. Тайлы должны быть прямоугольными и не меньше 64×64 пикселей по яркости, поэтому кадр в разрешении 1080p поддерживает максимум около 30 столбцов × 17 строк тайлов HEVC – с большим запасом для любого реально используемого числа ядер.

Экспериментальное исследование на 12-ядерном HEVC-кодере с тактовой частотой 3,33 ГГц показало средний прирост производительности 9,3× на 4K-последовательностях при использовании тайлов по сравнению с однотайловым базовым вариантом (Fraunhofer HHI, 2015). То же исследование зафиксировало прирост 8,7× для wavefront-параллелизма на той же платформе – разница настолько мала, что выбор между подходами определяется не только скоростью, но и особенностями контента и архитектуры пайплайна.

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

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 обеспечивает ускорение по wall-clock на 3–5× при увеличении битрейта всего на 1%. (x265 documentation, 2025). Streaming Learning Center провёл тестирование x265 с WPP на 32-ядерной системе и получил ускорение 7,3× для одного файла, однако общий прирост пропускной способности в batch-нагрузках составил лишь 9% – поскольку batch может распределить все ядра между отдельными файлами.

Tiles AV1 – сетка на основе степеней двойки

AV1, утверждённый AOMedia в марте 2018 года, сохранил концепцию тайлов, но ужесточил грамматику. Кадр AV1 делится на прямоугольную сетку тайлов, количество которых по каждой оси всегда является степенью двойки: 1, 2, 4, 8, 16 или 32. Максимальное число тайлов на кадр – 64.

Жёсткая структура «степень двойки» даёт два преимущества. Во-первых, она делает синтаксис битового потока компактным – кодер записывает log₂ числа строк и столбцов всего двумя короткими полями. Во-вторых, она хорошо согласуется с тем, как аппаратное обеспечение декодера организует работу: сетки, размер которых является степенью двойки, выровнены по границам cache lines и соответствуют ширине SIMD-операций.

Стоимость тайлов AV1 по битрейту сопоставима с HEVC: сетка 2×2 занимает 0,5–1,5 процента, 4×2 – 1–2 процента. YouTube начал внедрение AV1 в 2018 году и добавил поддержку 8K AV1 в 2020-м; оба решения используют тайл-параллелизм, чтобы поддерживать приемлемые времена кодирования на обычных облачных серверах. Netflix в декабре 2025 года сообщил, что 30 процентов его стримов теперь транслируются в формате AV1, закодированном с учётом содержания и с переменным числом тайлов, которое может отличаться от одного контента к другому.

AV1 также определяет специальный режим large-scale tile для VR и 360°-видео, при котором плеер декодирует только те тайлы, которые попадают в текущий viewport, а не весь кадр.

Таблица 1. Механизмы разрезания кадра для параллельной обработки. Стоимость сжатия зависит от контента (спорт и концерты – дороже, talking head – дешевле). Практический прирост производительности измерен относительно базового варианта на одном ядре при одинаковом контенте.

Subpictures – вклад VVC

VVC, утверждённый как H.266 в июле 2020 года, сохранил из HEVC такие элементы, как slices, tiles и WPP, и добавил четвёртый механизм – subpictures. Subpicture – это прямоугольная область кадра, кодируемая как самостоятельное мини-видео: со своим заголовком slice, собственным списком опорных кадров, а при необходимости – и собственным loop-фильтром. Такой блок можно извлечь, заменить или перепаковать без перекодирования.

Сценарий применения – композитный стриминг. Продукт для видеонаблюдения, отображающий сетку из 4×4 камер, может кодировать каждый кадр как subpicture, транслируя в высоком качестве только те, на которые смотрит оператор, а остальные снижать по качеству. 360°-VR-плеер может закодировать сферу как сетку subpictures и передавать в полном разрешении только те, что попадают в поле зрения пользователя. HEVC поддерживал аналогичный подход через motion-constrained tile sets (MCTS), однако синтаксис subpictures в VVC проще, а поддержка декодера встроена прямо в стандарт.

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

В продуктах для стриминга, видеонаблюдения и видеоконференций выбор между slices, tiles и WPP – одно из первых решений, которое мы принимаем при создании нового пайплайна. Проекты Live OTT и удалённой съёмки используют HEVC- или AV1-tiles, чтобы 4K-60 кодирование выполнялось на одной машине с предсказуемой задержкой. WebRTC SFU, которые мы поставляем для видеоконференций, используют по одному slice на кадр: на типичных конференционных разрешениях накладные расходы от заголовков slice важнее, чем выигрыш от параллелизма. В системах видеонаблюдения, где на экране отображается множество камер в одной композиции, применяются VVC subpictures или HEVC MCTS – чтобы при увеличении одной камеры оператор не заставлял сервер перекодировать всю сетку.

Типичная ошибка – копирование настроек VOD для трансляции в прямом эфире

Команды регулярно берут конфигурацию кодера из VOD per-title encoding и применяют её в live-транскодере. У VOD-задачи – 32 тайла, потому что архивные материалы обрабатываются на 64-ядерной ноде; у live-задачи – 4 тайла, так как каждому каналу выделено по 4 ядра. Запуск VOD-конфига в live-режиме либо приводит к простою ядер (большинство тайлов простаивает большую часть времени), либо нарушает бюджет задержки (кодер ждёт границы тайлов, которые приходят с опозданием). Всегда подбирайте количество тайлов под ядра, доступные этому конкретному потоку, а не всё кластеру.

Ключевые выводы

• Slices, tiles, wavefronts и subpictures – все эти методы разбивают кадр, чтобы над ним могли одновременно работать несколько ядер.
• Slices – механизм из H.264, сохранённый в основном для защиты от потерь пакетов; tiles – ключевой инструмент параллелизма в HEVC и AV1.
• WPP сдвигает строки по диагонали – небольшая плата в виде увеличения битрейта на 0,5–2,0%, но даёт ускорение одного потока в 3–5 раз.
• Tiles увеличивают битрейт на 0,5–2,0% и обеспечивают ускорение в 5–10 раз при типичном числе ядер.
• VVC вводит subpictures для композитного, ROI- и 360°-стриминга, где регионы изображения нужно динамически заменять.
• Размер сетки tiles следует выбирать исходя из числа ядер, доступных одному потоку, а не всему кластеру.

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

• Блоковая предсказательная обработка: MB, CTU, SB и суперблоки
• Энтропийное кодирование подробно: CAVLC, CABAC, арифметическое кодирование
• Структура GOP: I-, P- и B-кадры, открытые и закрытые GOP