Лестница кодирования: рендишны, разрешения, битрейты

TL;DR

Encoding ladder (или bitrate ladder) – это набор версий качества каждой единицы контента: разные пары «разрешение + битрейт», которые называют рендишнами, чтобы плеер мог переключаться между ними по мере того, как сеть зрителя ускоряется или замедляется. Каждая ступень лестницы – это rung, и в типичной ladder пять–девять rung'ов: от крошечной версии 234p для телефона на слабом сигнале до полной 1080p или 4K для быстрого соединения в гостиной. Ladder – это продуктовое решение, а не дефолт: насколько высок верхний rung, сколько rung'ов вы строите и как далеко они стоят друг от друга, вместе определяют качество картинки, счёт за хранение и байты, которые вы каждый месяц платите CDN за доставку. Эта статья показывает, из чего собран rung, как ladder живёт внутри манифеста стриминга, какая арифметика превращает выбор ladder в счёт, и какие ошибки тихо тратят деньги и на качестве, и на доставке.

Зачем это важно

Если вы основатель, продакт-менеджер или CTO стриминга впервые, encoding ladder – это первое техническое решение, которое затрагивает сразу весь бизнес: оно задаёт, насколько хорошо выглядит сервис, сколько хранилища нужно каталогу и – через байты, которые уходят зрителям, – самую крупную строку месячного счёта. Большинство команд принимают тот ladder, что идёт по умолчанию в их кодировщике, не осознавая, что дефолт построен под чужой контент и чужую аудиторию. Эта статья даёт ментальную модель, чтобы читать, оспаривать и масштабировать ladder: из чего состоит каждый rung, зачем ladder вообще нужен, сколько rung'ов реально требуется и как выбор ladder превращается в число в долларах. К концу вы сможете взглянуть на любой encoding ladder и задать три главных вопроса – не слишком ли высок верхний rung, достаточно ли низких rung'ов и настроен ли этот ladder под ваш контент или это просто копия примера Apple.

Что такое encoding ladder

Начнём с проблемы, которую ladder решает. У ваших зрителей разные интернет-соединения. Один – на домашнем оптоволокне, другой – в поезде с мерцающим мобильным сигналом, третий – на гостиничном Wi-Fi, который делят двести постояльцев. Если отдавать всем один и тот же высококачественный файл, зрителю на оптоволокне будет хорошо, а остальные будут смотреть на крутящийся индикатор буферизации. Если отдавать всем низкое качество ради безопасности, зритель на оптоволокне получит мягкую, «квадратную» картинку на 65-дюймовом экране и спросит, за что он вам платит.

Решение – сделать несколько версий каждой единицы контента и позволить плееру каждого зрителя выбрать ту, что его соединение тянет прямо сейчас. Этот набор версий и есть encoding ladder (его же называют bitrate ladder), а каждая отдельная версия – рендишн (rendition). Удобный образ: encoding ladder – это классы мест на одном рейсе. Тот же самолёт, тот же пункт назначения, разная цена и комфорт – и плеер «бронирует» лучший класс, который сеть может позволить в этот момент, опускаясь в эконом при ослаблении сигнала и возвращаясь обратно при восстановлении.

Каждая версия стоит на ступень выше или ниже следующей, поэтому набор рисуют лестницей со ступенями (rung'ами). Нижний rung – маленький рендишн низкого качества, который почти любое соединение скачает без остановок. Верхний rung – крупный рендишн высокого качества для быстрых сетей и больших экранов. Между ними – средние rung'и, где и происходит большая часть реального просмотра. Технику переключения между rung'ами по мере изменения условий называют adaptive bitrate streaming (ABR); плеер измеряет сеть и состояние собственного буфера, затем поднимается на rung повыше или спускается ниже. Логику переключения плеера держим здесь на расстоянии вытянутой руки – подробная механика живёт в нашем гайде по adaptive bitrate streaming в разделе Video Streaming. Для ladder из ABR нужно лишь одно: ladder – это меню, а ABR – едок, выбирающий блюдо каждые несколько секунд.

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

Из чего собран один rung

Rung – это не просто «720p». Это небольшой набор решений, и собрать его правильно – это и есть большая часть мастерства. Каждый rung определяют четыре свойства.

Первое – разрешение, пиксельные размеры картинки, например 1920×1080 (его называют 1080p) или 640×360 (360p). Больше пикселей – резче изображение на большом экране, но больше пикселей нужно больше данных, чтобы описать, так что разрешение и стоимость растут вместе.

Второе – битрейт, сколько данных в секунду использует рендишн, в килобитах или мегабитах в секунду (kbps или Mbps). Битрейт – рычаг, который важнее всего и для качества, и для стоимости. Высокий битрейт чисто несёт детали и движение; битрейт, заданный слишком низко для разрешения, даёт «квадраты» и смазанное движение. Главное: битрейт – это то, за что вы платите при доставке. CDN выставляет счёт за отправленные байты, поэтому битрейт каждого rung'а – ещё и его ценник.

Третье – кодек, метод сжатия, которым ужимают видео: H.264, HEVC или AV1. Более эффективный кодек отдаёт ту же картинку при меньшем битрейте, поэтому выбор кодека – это на самом деле решение про стоимость и охват. Это решение мы разбираем отдельно в стратегии кодеков для OTT, а механику самих кодеков – в нашем разделе Video Encoding. Для ladder держите один факт: тот же rung стоит меньше байтов на новом кодеке, но воспроизвести его смогут только устройства, которые этот кодек понимают.

Четвёртое – частота кадров (frame rate), сколько изображений в секунду, например 30 или 60. Частота кадров обычно остаётся постоянной по всей ladder (вы меняете не плавность движения, а резкость картинки), хотя самые низкие rung'и иногда делят её пополам ради экономии данных. Рядом с этими четырьмя свойствами стоят profile и level кодека – настройка совместимости, ограничивающая, насколько требовательным разрешено быть потоку; правила авторинга Apple, о которых ниже, требуют оставаться на уровне High Profile, Level 4.2 или ниже, чтобы поток играл на широкой базе устройств.

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

Как ladder живёт внутри манифеста

Ladder – не абстрактная идея внутри кодировщика; он записан, простым текстом, в файле, который плеер читает первым. Этот файл – манифест, небольшой текстовый документ, перечисляющий каждый rung и откуда его взять. Плеер скачивает манифест, видит меню rung'ов и начинает выбирать.

В HLS (HTTP Live Streaming, созданный Apple формат доставки, описанный в IETF RFC 8216) манифест – это master playlist, и каждый rung – одна запись EXT-X-STREAM-INF. Тег несёт пиковую и среднюю пропускную способность rung'а, разрешение и кодек, затем указывает на собственный плейлист сегментов этого rung'а. Урезанный пример на три rung'а:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=6500000,AVERAGE-BANDWIDTH=6000000,RESOLUTION=1920x1080,CODECS="avc1.640028,mp4a.40.2",FRAME-RATE=30.000
v_1080p_6000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2200000,AVERAGE-BANDWIDTH=2000000,RESOLUTION=960x540,CODECS="avc1.64001f,mp4a.40.2",FRAME-RATE=30.000
v_540p_2000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=820000,AVERAGE-BANDWIDTH=730000,RESOLUTION=640x360,CODECS="avc1.64001e,mp4a.40.2",FRAME-RATE=30.000
v_360p_730.m3u8

Каждая строка EXT-X-STREAM-INF – один rung вашего ladder; BANDWIDTH – пик, который плеер должен удержать, а AVERAGE-BANDWIDTH – типичная скорость. Структура описана в RFC 8216 §4.3.4.2. Другой основной формат доставки, MPEG-DASH (Dynamic Adaptive Streaming over HTTP, ISO/IEC 23009-1), выражает ту же идею иными словами: один AdaptationSet содержит несколько элементов Representation, у каждого – атрибуты bandwidth, width, height и codecs. Representation в DASH – это то же самое, что variant stream в HLS: один rung ladder.

Два формата, один ladder. Вы не строите ladder дважды. Современные платформы кодируют рендишны один раз и упаковывают их и в HLS, и в DASH из одного набора сегментов с помощью CMAF (Common Media Application Format, ISO/IEC 23000-19) – конвергентного формата fragmented-MP4, который читают оба протокола. Продуктовую рамку этого шага «закодируй один раз, упакуй для всех» мы разбираем в упаковке: CMAF, HLS и DASH из одного mezzanine; вывод для ladder в том, что ваши rung'и – это решения про кодек и битрейт, принятые один раз, а затем отданные в том формате, который нужен конкретному плееру.

Представительный ladder, rung за rung'ом

Числа делают ladder конкретным, поэтому вот представительный ladder из семи rung'ов на H.264 для видео 16:9. H.264 – правильный кодек для иллюстрации, потому что он играет практически на любом устройстве последнего десятилетия; это базовый охват, который везёт любая платформа. Форма ниже следует рекомендациям HLS Authoring Specification от Apple и общей отраслевой практике; относитесь к точным битрейтам как к разумной отправной точке для настройки под ваш контент, а не как к незыблемому закону.

Таблица 1. Представительный ladder из семи rung'ов на H.264. Числа взяты из отраслевого базиса в духе Apple; число rung'ов и их шаг – это уже продуктовые решения, которые принимаете вы.

Несколько правил из HLS Authoring Specification от Apple формируют эту таблицу, и их стоит знать, потому что они защищают воспроизведение на реальных устройствах. Спецификация рекомендует, чтобы для VOD-контента пиковый битрейт rung'а оставался в пределах 200% от среднего – тогда внезапно сложная сцена не «выбьет» бюджет канала зрителя. Она рекомендует High Profile, Level 4.2 или ниже – лимит совместимости, удерживающий поток воспроизводимым на базе устройств. Она рекомендует шестисекундные сегменты с ключевым кадром каждые две секунды, что задаёт, как быстро плеер может переключать rung'и. И она делает тонкое, но важное замечание о том, какой rung играет первым: спецификация предлагает 2 000 kbps как стартовый поток на Wi-Fi и 730 kbps на сотовой сети, потому что первый загруженный rung формирует важнейшее первое впечатление зрителя ещё до того, как ABR что-либо измерил.

Теперь арифметика, превращающая эту таблицу в хранение. Стоимость хранения единицы контента определяется суммой битрейтов всех rung'ов, потому что вы храните каждый рендишн. Сложите столбец: 6 000 + 4 500 + 3 000 + 2 000 + 1 100 + 730 + 145 = 17 475 kbps, около 17,5 Mbps суммарного хранимого битрейта. Для одного двухчасового фильма:

суммарный битрейт = 17 475 kbps ≈ 17,5 Mbit/s
длина фильма      = 2 ч × 3 600 с              = 7 200 с
хранимые данные   = 17,5 Mbit/s × 7 200 с ÷ 8  = 15 750 MB ≈ 15,7 GB

То есть этот ladder хранит один двухчасовой фильм примерно в 15,7 GB на все семь rung'ов. Хранение дёшево – при ~$0,023 за гигабайт-месяц этот фильм стоит сильно меньше доллара в месяц, – так что стоимость хранения ladder редко бьёт по карману. Бьёт доставка, к которой переходим дальше и которая зависит не от суммы rung'ов, а от того, какой rung реально тянет каждый зритель.

Продуктовые решения, из которых строится ladder

Вот сердце статьи: encoding ladder – это набор решений, и копирование чужих решений – то, как утекают деньги. Ваш ladder определяют пять решений.

Первое – верхний rung, наивысшее качество, которое вы предлагаете. Задавайте его тем, что оправдывают ваш контент и аудитория, а не эго. Премиальному киносервису, кормящему 4K-телевизоры, нужен высокий верхний rung; новостному сервису с «говорящей головой» или детскому мультканалу – нет, потому что лишний битрейт не покупает видимого качества на таком контенте, а отдаётся каждому топовому зрителю за полную цену. Верхний rung – самый дорогой в доставке, поэтому заслуживает самого пристального взгляда.

Второе – число rung'ов. Слишком мало – и скачки между rung'ами большие и резкие: картинка заметно дёргается при переключении. Слишком много – и вы платите за кодирование и хранение рендишнов, стоящих так близко, что разницы никто не замечает. Пять–девять rung'ов покрывают большинство каталогов; правильное число зависит от того, насколько широкий диапазон устройств и сетей вы обслуживаете.

Третье – битрейт каждого rung'а и то, как далеко rung'и стоят друг от друга. Хорошие ladder ставят rung'и так, чтобы каждый шаг примерно вдвое увеличивал или уменьшал битрейт соседа, – это держит скачки качества ровными и даёт ABR чистый, хорошо разнесённый выбор. Сбитые в кучу rung'и тратят кодирование впустую; разнесённые слишком далеко делают переключение похожим на обрыв.

Четвёртое – разрешение в паре с каждым битрейтом. Битрейт, щедрый на 540p, – голодный паёк на 1080p, поэтому разрешение и битрейт движутся вместе вверх по ladder. Частая ошибка – держать разрешение слишком высоким на низких rung'ах: rung 1080p на 800 kbps выглядит хуже, чем rung 540p на тех же 800 kbps, потому что биты размазаны слишком тонко по слишком большому числу пикселей.

Пятое – кодек и метод rate control – кодируете ли вы H.264 ради охвата, HEVC или AV1 ради эффективности, держите ли постоянный битрейт или позволяете ему меняться со сложностью сцены. Они едут рядом с каждым rung'ом и разобраны в отдельных статьях, но место им в списке решений, потому что они меняют каждое число в таблице.

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

Почему фиксированный ladder тратит деньги

Большинство платформ применяют один фиксированный ladder – те же rung'и с теми же битрейтами – ко всему каталогу. Это просто и почти для каждой отдельной единицы контента неверно, потому что контент не одинаково труден для сжатия. Быстрому зернистому боевику действительно нужны 6 000 kbps на 1080p, чтобы выглядеть чисто. Плоский мультфильм, лекция со слайдами или статичная «говорящая голова» выглядят так же при вдвое меньшем битрейте, потому что визуальной информации просто меньше. Фиксированный ladder обслуживает оба одинаково: переплачивает на лёгком контенте и изредка недоплачивает на самом сложном.

Альтернатива – per-title encoding – анализ каждой единицы контента и построение ladder, настроенного под её сложность, так что простой контент получает более низкий, дешёвый ladder, а сложный – тот битрейт, что ему действительно нужен. Netflix публично представил эту идею в 2015 году простым тезисом: единого ladder «на всех» не существует, и каждая единица контента заслуживает своего. Метод тестирует несколько кодировок и строит график «качество против битрейта», чтобы найти самый эффективный набор rung'ов – точки вдоль того, что инженеры называют выпуклой оболочкой (convex hull), кривой, ограничивающей лучшее качество, доступное при каждом битрейте. Версия простыми словами: перестаньте платить по цене 1080p за доставку мультфильма, который идеально выглядит при трети битрейта.

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

Экономия реальна и измерена. Bitmovin сообщает, что per-title encoding может срезать стоимость хранения и доставки CDN примерно вдвое на типичном каталоге, убирая рендишны, которые единице контента не нужны. Режим quality-defined variable bitrate (QVBR) в AWS Elemental MediaConvert – родственная техника, распределяющая биты по сложности сцены, – даёт файлы на 25–40% меньше, чем фиксированная кодировка CBR при том же качестве. Поскольку доставка – доминирующая статья расходов стриминговой платформы, процентное сокращение доставляемого битрейта почти напрямую падает в прибыль. Компромисс – дополнительный компьют на анализ каждой единицы контента против хранения и egress, которые он экономит, – мы оцифровываем с разобранной арифметикой и калькулятором экономии в per-title и context-aware кодировании: экономика.

Рендишны под устройство: не каждый rung для всех

Ladder ещё и должен уважать устройство на том конце, потому что rung, который устройство не может использовать, – это rung, построенный ни для кого. 4K-rung, отданный на телефон, потрачен дважды: маленький экран телефона не покажет лишних деталей, и телефон всё равно не запросит этот rung, потому что его декодер и экран ограничены ниже. А дешёвому Android-телефону на сигнале 2G по-настоящему нужен тот крошечный пол-rung 234p, которого 4K-телевизор не коснётся никогда.

Поэтому классы устройств отображаются на подмножества ladder, а не на всю лестницу. Таблица ниже намечает, как rung'и ложатся на классы устройств; колонки «использует этот rung?» – это взгляд покрытия, удерживающий вас от отгрузки рендишнов, которые никто не играет.

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

Таблица 2. Какой класс устройств реально использует какой rung. Низкие rung'и существуют для телефонов на слабых сетях; верхние – для гостиной. Строить 4K для аудитории «только телефоны» – чистая трата.

Продуктовый урок – подгонять ladder под аудиторию, которая у вас реально есть. Mobile-first сервису на рынке со скромными скоростями стоит вложиться в хорошо настроенные нижние и средние rung'и и, возможно, вовсе пропустить 4K; премиальному сервису для гостиной – везти высокие rung'и и можно проредить самые нижние. Карту классов устройств и решений воспроизведения по всему ландшафту клиентов мы рисуем в клиентской матрице OTT, а решение «рендишн под устройство» копаем в рендишнах под устройство.

От ladder к счёту: арифметика, которая решает

Свяжем ladder обратно с деньгами, потому что ради этого продуктовое решение и важно. Хранение, как показано выше, зависит от суммы всех rung'ов и стоит дёшево. Доставка зависит от того, какой rung тянет каждый зритель, и это доминирующая статья. CDN берёт плату за байты, отправленные зрителям, – повторяющийся сбор под названием egress, – и эти байты равны времени просмотра каждого зрителя, умноженному на битрейт rung'а, который он смотрит.

Проведём одного зрителя по этой цепочке. Допустим, большая часть просмотра приходится на средние rung'и, так что средний доставляемый битрейт около 3 Mbps, и зритель смотрит двухчасовой фильм:

доставляемый битрейт = 3 Mbit/s (средний реально игравший rung)
длина просмотра      = 2 ч × 3 600 с           = 7 200 с
доставлено данных    = 3 Mbit/s × 7 200 с ÷ 8  = 2 700 MB = 2,7 GB за полный просмотр

При представительной ставке CDN около $0,04–$0,08 за гигабайт один такой двухчасовой просмотр стоит примерно 11–22 цента на доставку. Умножьте на реальную аудиторию – и влияние ladder становится очевидным: если лучше настроенный ladder снижает средний доставляемый битрейт с 3 Mbps до 2,4 Mbps при том же воспринимаемом качестве, вы срезали пятую часть стоимости доставки на каждого зрителя – каждый месяц, навсегда. Поэтому ladder – не разовая задача кодирования, а постоянная настройка вашей маржи. Полная модель стоимости доставки, включая то, как egress тарифицируется по уровням и со скидками, живёт в cost engineering для CDN, а взгляд на всю платформу – в модели стоимости OTT.

Частая ошибка: отгрузка ladder по умолчанию

Самая частая ошибка, которую мы видим, – относиться к ladder как к настройке, которую принимают, а не к решению, которое принимают. Команда ставит кодировщик, оставляет заводской ladder и отгружает – не замечая, что дефолт спроектирован под общий контент и обобщённую аудиторию, а не под их мультфильмы, лекции или 4K-фильмы. Из этого следуют три конкретные ошибки.

Первая – верхний rung задан слишком высоко для контента. Кодирование плоской анимации на 6 000 kbps не даёт видимой выгоды против 3 000 kbps, но вдвое увеличивает стоимость доставки каждому зрителю, который дойдёт до этого rung'а. Лекарство – настройка per-title или, как минимум, контент-зависимый верхний rung.

Вторая – слишком мало низких rung'ов. Команды зацикливаются на верхушке ladder и забывают про низ, оставляя зрителей на слабых сетях без rung'а достаточно маленького, чтобы играть плавно. Они буферизуются, а потом уходят. Здоровый пол 145–730 kbps – это то, что вообще удерживает мобильных зрителей в просмотре.

Третья – разрешение и битрейт расходятся – rung 1080p, посаженный на голодный паёк в 1 500 kbps, выглядит хуже, чем rung 720p на том же битрейте, потому что биты размазаны по слишком большому числу пикселей. Ставьте каждому разрешению битрейт, который реально его кормит, и пусть разрешение спускается вместе с битрейтом.

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

Ladder – это место, где качество картинки и стоимость доставки решаются вместе, и сделать это правильно в масштабе – на каталоге из тысяч единиц, дюжине классов устройств и аудитории, растущей с тысячи зрителей до миллиона, – это инженерная дисциплина, а не галочка. Фора Софт строит софт для видеостриминга, OTT/интернет-ТВ, e-learning, телемедицины и видеонаблюдения с 2005 года, на 250+ выпущенных проектах для 400+ клиентов, и эта работа крутится именно вокруг такой инженерии масштаба и стоимости: настройки ladder под контент, отображения rung'ов на матрицу устройств, перевода популярных единиц контента на более эффективные кодеки и встраивания per-title encoding в конвейер, чтобы счёт за доставку оставался под контролем по мере роста аудитории. Когда медиакомпании нужна стриминговая платформа, у которой и качество, и юнит-экономика переживают встречу с реальной аудиторией, именно эта инженерия ladder-и-доставки – то, что мы приносим.

Главное

• Encoding ladder – это набор рендишнов качества, между которыми плеер переключается по сети.
• Каждый rung собран из разрешения, битрейта, кодека и частоты кадров; за битрейт берёт деньги CDN.
• Ladder живёт в манифесте – один HLS-variant или DASH-Representation на rung.
• Ladder – продуктовое решение: верхний rung, число rung'ов, шаг и разрешение стоят денег.
• Фиксированный ladder переплачивает на лёгком контенте; per-title режет доставку до ~50%.
• Подгоняйте rung'и под реальные устройства – 4K-rung для аудитории телефонов – чистая трата.

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

• Per-title и context-aware кодирование: экономика
• Стратегия кодеков для OTT: H.264, HEVC, AV1 и VVC
• Упаковка: CMAF, HLS и DASH из одного mezzanine