Экономика per-title encoding: счёт CDN ниже

TL;DR

Per-title encoding анализирует каждую единицу контента и строит bitrate ladder, настроенный под её сложность: плоский мультфильм получает более дешёвый ladder, чем зернистый боевик, и никто не переплачивает за доставку битов, которые картинке не нужны. Context-aware encoding идёт дальше и оптимизирует внутри единицы контента – по shot'ам, а всё чаще и под устройство и сеть на другом конце – ради ещё одной ступени экономии ценой куда большего компьюта. Заявленная экономия доставки велика и измерена: примерно 20–50% на типичном каталоге, а в одном вендорском кейсе верхний 4K rung шёл на 1,9 Mbps против фиксированных 15 Mbps при том же измеренном качестве. Почему это лучшая сделка в стриминге – из-за асимметрии: дополнительный компьют на кодирование платится один раз на единицу контента, а egress, который он экономит, не тратится на каждом просмотре, всегда – так что окупают компьют уже несколько сотен просмотров.

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

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

Начнём с того, что транжирит фиксированный ladder

Короткое напоминание – экономия имеет смысл только относительно базы. Стриминговая платформа делает несколько версий качества каждой единицы контента – разные пары «разрешение + битрейт», называемые рендишнами – и складывает их в encoding ladder (или bitrate ladder), чтобы плеер переключался между ними по мере того, как сеть зрителя ускоряется или замедляется – техника под названием адаптивный битрейт-стриминг. Как ladder собирается rung за rung'ом, мы разобрали в статье encoding ladder простыми словами; один факт, который нужно унести сюда: битрейт каждого rung'а – это то, за доставку чего CDN выставляет вам счёт.

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

Трата прячется, потому что картинка выглядит нормально. Никто не жалуется, что мультфильм шёл на 6 000 kbps; он выглядел отлично. Просто он выглядел отлично на втрое большем битрейте, чем ему нужно, и вы заплатили CDN за разницу, умноженную на каждого зрителя. Per-title encoding – это дисциплина находить и убирать эту невидимую переплату.

Что такое per-title encoding на самом деле

Идея в одном предложении: вместо того чтобы угадывать один ladder на весь каталог, проанализируйте каждую единицу контента и постройте самый дешёвый ladder, который для этого конкретного контента всё ещё выглядит так же хорошо, как фиксированный. Простой контент получает более низкий, короткий ladder; сложный – тот битрейт, что ему действительно нужен. Netflix публично представил подход в декабре 2015 года резким тезисом: единого ladder «на всех» не существует, и каждая единица контента заслуживает своего.

Чтобы найти правильный ladder, нужен способ измерить «выглядит так же хорошо» – и это та деталь, без которой ничего не работает. Мера – это перцептивная метрика качества, оценка, предсказывающая, насколько хорошо видео выглядит для человеческого глаза, а не просто сколько битов оно несёт. Доминирующая – VMAF (Video Multi-Method Assessment Fusion), метрика с открытым кодом, которую Netflix разработал и выложил; она оценивает видео по шкале от 0 до 100, моделируя зрительную систему человека и сплавляя несколько сигналов качества. Полезный ориентир: разница примерно в 6 баллов VMAF – это около одной «заметной разницы» (JND), наименьшего изменения качества, которое зритель реально заметит. VMAF превращает расплывчатое «достаточно хорошо» в число, на которое можно целиться, – и именно это позволяет машине безопасно решить, что мультфильм на 2 000 kbps неотличим от того же мультфильма на 6 000 kbps.

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

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

Версия простыми словами: перестаньте платить по цене 1080p за доставку мультфильма, который идеально выглядит при трети битрейта. Современные кодировщики избавляют от буквально сотен тестовых кодировок – Bitmovin, например, прогоняет быстрый анализ сложности, предсказывающий оболочку, а Automated ABR в AWS Elemental MediaConvert анализирует каждый вход и сам выбирает число rung'ов и разрешения, по умолчанию ограничивая ladder пятнадцатью rung'ами и убирая те, что добавляют битрейт без качества. Принцип тот же; подешевело лишь нахождение оболочки.

Per-title, per-shot, context-aware: лестница гранулярности

«Per-title» – это первый rung более высокой лестницы оптимизации, и каждый шаг вверх настраивает кодировку тоньше: больше экономии и больше компьюта. Полезно видеть три уровня как последовательность.

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

Первый уровень – фиксированный ladder: один ladder, каждая единица, без анализа. Дешевле всего в работе, расточительнее всего в доставке.

Второй уровень – per-title encoding: один анализ на единицу контента, дающий один свой ladder на всю эту единицу. До этого уровня большинству платформ стоит дойти в первую очередь, потому что он забирает наибольшую долю экономии за скромную разовую стоимость анализа.

Третий уровень – per-shot, или context-aware, encoding: оптимизация внутри единицы контента. Двухчасовой фильм неоднороден по сложности – тёмной статичной сцене диалога нужно куда меньше битов, чем следующей за ней погоне. Per-shot encoding режет единицу на отдельные shot'ы и подбирает лучшее разрешение и настройку качества для каждого. Netflix выпустил именно это в 2018 году как Dynamic Optimizer, выбирая настройки per-shot ради максимума VMAF при заданном битрейте, и сообщил о снижении битрейта примерно на 30% в среднем против лучшей кодировки фиксированного качества на всю единицу. Цена – гранулярность: там, где часовой эпизод раньше кодировался примерно двадцатью многоминутными чанками, shot-based кодирование того же эпизода означает обработку порядка 900 коротких shot'ов – куда больше задач кодирования и оркестрации.

«Context-aware» – зонтичный термин для этого семейства, и контекст может выходить за пределы самого контента. Некоторые системы учитывают устройство (экран телефона не покажет детализацию, доступную 65-дюймовому ТВ, поэтому может принять более низкий rung – решение рендишны под устройство) и сеть (зрителю на стабильном соединении нужно меньше «страховочных» rung'ов, чем на капризном мобильном). Вендоры реализуют части этого по-разному. Режим quality-defined variable bitrate (QVBR) в AWS распределяет биты по сложности сцены внутри одной кодировки и даёт файлы на 25–40% меньше, чем фиксированный CBR при том же качестве. Content-aware кодирование Harmonic (EyeQ) перцептивно адаптирует битрейт под контент и заявляет до 50% сокращения полосы и хранения, включая живой тест, где поток 65 Mbps снизился до среднего 27 Mbps. Названия разные; принцип постоянен – тратить биты там, где глаз заметит, и экономить там, где нет.

Сколько это реально экономит

Заявки об экономии в этой области реальны, но вендорские, поэтому относитесь к ним как к хорошо подкреплённым диапазонам, а не гарантиям, и всегда привязанным к метрике качества. Честное резюме по публичным данным: per-title encoding режет стоимость доставки и хранения примерно на 20–50% на типичном смешанном каталоге и куда сильнее на отдельных легко сжимаемых единицах. Таблица ниже собирает названные, датированные цифры и – по нашему правилу для любого сравнения вендоров – отмечает, где каждая техника реально доступна.

Таблица 1. Техники оптимизации, заявленная экономия и где они работают. Цифры вендорские и датированные; перед цитированием сверьте с текущим источником. Экономия сильно зависит от состава контента – каталог из мультфильмов и лекций экономит куда больше, чем каталог из зернистых триллеров.

Самый яркий измеренный пример – у Bitmovin. На UHD-контенте одного клиента per-title ladder выдал оценку VMAF 94,9 всего при 1,9 Mbps для верхнего 4K rung'а, против фиксированного ladder клиента, использовавшего 15 Mbps при практически идентичной оценке. Это та же картинка примерно за восьмую часть байтов – сокращение стоимости доставки верхнего rung'а на 87%. Прокрутим следствие на один просмотр вслух, потому что именно тут это становится деньгами:

фикс. верхний rung:   15 Mbit/s × (44,65 мин × 60 с) ÷ 8 ≈ 5 023 МБ ≈ 5,0 ГБ на просмотр
per-title верхний rung: 1,9 Mbit/s × (44,65 мин × 60 с) ÷ 8 ≈   622 МБ ≈ 0,62 ГБ на просмотр
сэкономлено на полный просмотр верхнего rung'а ≈ 4,4 ГБ

При представительной ставке доставки около $0,04–$0,08 за гигабайт одна эта оптимизация экономит примерно 18–35 центов на каждом полном просмотре верхнего rung'а – ещё до учёта сэкономленного хранения и избегнутой буферизации. Второй пример Bitmovin мягче, но типичнее: на контенте 1080p средней сложности per-title encoding с более эффективным кодеком держал качество 1080p на 2 Mbps там, где фиксированному H.264-ladder клиента нужно было более 6,5 Mbps – около 70% сокращения полосы на верхнем rung'е. (Сочетание per-title с более эффективным кодеком складывает экономию; сам выбор кодека мы держим в стратегии кодеков для OTT, а механику кодеков – в разделе Video Encoding.)

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

Экономика: разовый компьют против повторяющегося egress

Самая глубокая причина, почему per-title encoding почти всегда оправдан, – не размер экономии, а её форма. Стоимость, которую он добавляет, и стоимость, которую убирает, лежат по разные стороны очень важной границы.

Дополнительный компьют – это разовая стоимость. Вы анализируете и кодируете единицу контента один раз. Сколько бы её потом ни смотрели – ноль раз или десять миллионов, – счёт за кодирование вы платите ровно один раз. Egress, который он экономит, – это повторяющаяся стоимость. Каждый просмотр гонит байты через CDN, и per-title encoding срезает байты с каждого из них, в этом месяце и в каждом, пока единица остаётся в каталоге. Разовая трата покупает экономию-навсегда. Эта асимметрия – весь аргумент, и её стоит увидеть в числах.

Возьмём представительный ladder из семи rung'ов H.264 из прошлой статьи – его битрейты суммируются в 17 475 kbps, и он хранит двухчасовой фильм примерно в 15,7 ГБ. Теперь оценим разовую кодировку. Облачные кодировщики берут плату за минуту вывода, масштабированную множителем за разрешение и усилие; AWS Elemental MediaConvert, например, берёт в профессиональном тарифе от $0,0120 за «нормализованную минуту» на малом объёме, где HD rung считается за 2×, а SD rung за 1×. Наши семь rung'ов (три HD, четыре SD) дают множитель 10×:

стоимость кодировки (фикс. ladder, разово):
  120 мин фильма × 10 (сумма множителей rung'ов) = 1 200 нормализованных минут
  1 200 × $0,0120                                 = $14,40 за весь ladder, один раз

Per-title encoding добавляет шаг анализа и часто более затратную multi-pass кодировку. Будем пессимистами и предположим, что он удваивает разовый счёт за кодировку, до примерно $29 – лишние $14,40, заплаченные однажды. Теперь повторяющаяся сторона. Пусть средний доставляемый rung фиксированного ladder – 3,0 Mbps, а настройка per-title тянет это среднее до 2,0 Mbps при том же воспринимаемом качестве (сокращение на треть, консервативное против диапазона 20–50%):

egress на 2-часовой просмотр, фикс. ladder:   3,0 Mbit/s × 7 200 с ÷ 8 = 2 700 МБ = 2,70 ГБ
egress на 2-часовой просмотр, per-title ladder: 2,0 Mbit/s × 7 200 с ÷ 8 = 1 800 МБ = 1,80 ГБ
сэкономлено на просмотр: 0,90 ГБ  ×  $0,06/ГБ  ≈  $0,054  (около 5,4 цента)

Разделите разовую стоимость на экономию с просмотра, чтобы найти точку окупаемости:

окупаемость в просмотрах = доп. разовый компьют ÷ экономия на просмотр
                         = $14,40 ÷ $0,054 на просмотр  ≈  267 просмотров

Примерно после 270 просмотров per-title кодировка окупила себя. Каждый просмотр сверх этого экономит около 5,4 цента, уходящих в маржу, плюс меньшую повторяющуюся экономию на хранении (per-title ladder здесь хранит фильм примерно в 7,3 ГБ вместо 15,7 ГБ – около 54% меньше – экономя примерно $0,19 в месяц по стандартным облачным тарифам). Для любой единицы, набирающей больше нескольких сотен просмотров за жизнь, per-title encoding – не пограничное решение; это найденные деньги. Полную модель стоимости доставки, включая то, как egress тарифицируется и дисконтируется в масштабе, см. в стоимости CDN: egress, коммиты и 95-й перцентиль, а экономику всей платформы – в модели стоимости OTT.

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

Масштабируйте арифметику одной единицы на каталог – и числа перестают быть абстрактными. Каталог из 1 000 единиц со средними 5 000 просмотров на единицу в год, при этих вводных, экономит порядка $270 000 на доставке в год против разового дополнительного счёта за компьют около $14 000 – чистая экономия за первый год выше $250 000, и больше каждый следующий год, потому что компьют больше не платится. Калькулятор экономии ниже позволяет заменить каждый ввод своим.

Когда компромисс разворачивается в другую сторону

Асимметрия выше настолько выгодна, что случаи провала узки – но они есть, и знание их удержит от лишней инженерии.

Первый – глубокий длинный хвост. Если большая доля каталога набирает лишь горстку просмотров каждая – нишевые архивные единицы, остатки с истёкшими правами, пользовательские загрузки, которые никто не смотрит, – то некоторые единицы никогда не перейдут порог окупаемости в несколько сотен просмотров, и компьют на анализ тратится без возврата. Лекарство – не пропускать per-title, а применять его лениво. Кодируйте длинный хвост дешёвым фиксированным ladder и запускайте per-title (или перекодировку в более эффективный кодек) только когда число просмотров единицы перейдёт порог. Популярность – это сигнал, что единица заслуживает оптимизации.

Второй – per-shot на малом масштабе. Per-shot кодирование умножает число задач кодирования на один-два порядка – вспомните скачок с примерно двадцати чанков до девятисот shot'ов на один эпизод. На каталоге и конкуренции Netflix этот компьют окупается тысячекратно. На нескольких тысячах единиц и скромной аудитории сложность оркестрации и компьют могут обогнать предельную экономию против обычного per-title. Дойдите сперва до per-title; тянитесь к per-shot, только когда масштаб оправдывает машинерию.

Частая ошибка: «экономия», которая на деле – худшая картинка

Самая вредная ошибка в этой области – верить сокращению битрейта без метрики качества за ним. Любой может «сэкономить 40%», просто опустив битрейт каждого rung'а, – и отгрузить более блочную, замыленную картинку, которая отпугнёт зрителей. Это не per-title encoding; это деградация с пресс-релизом. Весь метод держится на удержании измеренной цели качества – оценки VMAF или эквивалентной перцептивной метрики – постоянной, пока битрейт падает. Если вендор называет вам процент экономии, первый вопрос всегда: при каком VMAF, измеренном как, против какой базы? Экономия 50% при неизменном VMAF 94 – реальна. Экономия 50% без приложенного числа качества – это предупреждение.

Две связанные ловушки. Первая – не путайте per-title со сменой кодека. Per-title и более эффективный кодек – разные рычаги, которые складываются; демо вендора, меняющее оба сразу, может приписать выигрыш кодека per-title. Просите показать экономию per-title при фиксированном кодеке, затем экономию кодека отдельно. Вторая – уважайте свои продуктовые обещания. Если ваш премиум-тариф рекламирует 4K, convex hull простой единицы может сказать, что 4K rung расточителен, – но убрать его значит нарушить то, что вы продали и чего требует контракт с правообладателем. Держите верхний rung, который обещали, даже когда одна математика его срезала бы; per-title оптимизирует rung'и, которые вы оставляете, а не отменяет ваш продукт.

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

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

Главное

• Per-title encoding настраивает ladder под сложность каждой единицы; context-aware – по shot'ам и под устройство.
• Он опирается на перцептивную метрику качества – VMAF – чтобы резать битрейт при неизменном измеренном качестве.
• Заявленная экономия доставки – ~20–50% на смешанном каталоге, куда больше на легко сжимаемых единицах.
• Экономика выигрывает формой: компьют платится раз на единицу, egress экономится на каждом просмотре всегда.
• Представительная per-title кодировка окупается примерно за несколько сотен просмотров; всё сверх – маржа.
• Не доверяйте цифре экономии без приложенной цели VMAF – это может быть просто худшая картинка.

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

• Encoding ladder простыми словами: рендишны, разрешения, битрейты
• Стратегия кодеков для OTT: H.264, HEVC, AV1 и VVC
• Стоимость CDN: egress, коммиты и 95-й перцентиль