Привет! Меня зовут Михаил Мазанов, я отвечаю за технологический стек работы с медиаданными в Кинопоиске: от съёмок оригинальных проектов до доставки и просмотра видео на всех экранах. Для нашей пятой ежегодной конференции про стриминг PlayButton 2024 я готовил большой доклад про оптимизацию качества видео Кинопоиска, а для Хабра решил пересобрать его в виде статьи — для тех, кому текстовый формат предпочтительнее видео.

Кроме технических графиков, вас ждёт ещё и наглядная разница в работе алгоритмов сжатия на примере «Рика и Морти» и «Джона Уика».

Начнём же мы с разговора о качестве.

Что такое качество

Чтобы оптимизировать любой процесс, необходимо задать чёткие критерии. Для нас «качество» — это совокупность свойств, состав и значение которых формируется при создании продукта или услуги с целью удовлетворения актуальных потребностей.

Кажется немного сложным, но сейчас всё расскажу по порядку.

Существующие потребности важно учитывать, потому что они меняются с течением времени. То, что считалось стандартом качества 10 лет назад, уже не соответствует нормам 2024 года.

Запросы потребителей и технические возможности постоянно растут, с ними меняется и самое понятие «хорошего качества» — это динамическая величина. 

Про этапы видео-пайплайна Кинопоиска 

Всего у нас три таких этапа, и на каждом из них мы применяем разные подходы к контролю качества.

Закупка контента и производство оригинальных проектов.

Здесь мы сами диктуем технические требования к качеству производимого и закупаемого контента. За их соблюдением следит отдел контроля качества Плюс Студии (продюсерского центра Кинопоиска). Внутри этого отдела сформированы технические требования к производству оригинального контента Кинопоиска и они публично доступны уже более года — если вам интересно, можете почитать.

Ещё мы проводим конференции ProductionLab для производителей профессионального контента, на которых рассказываем о наших стандартах партнерам и обсуждаем современные технологии производства кино и сериалов. Записи этих конференций доступны на Кинопоиске в формате сериала.

Обработка (сжатие) контента

Первый закон качественного сжатия — конечный продукт не должен быть по качеству ниже, чем оригинальный (исходный).

На шуточной «шкале шакалов» наглядно показаны пикселизация и артефакты сжатия, которых мы должны избегать в конечном продукте.

Второй закон качественного сжатия — это соразмерность контента сетевой полосе (клиентской и серверной). Если с клиентской всё понятно, то под серверной ёмкостью мы подразумеваем ёмкость CDN, которая должна расти соразмерно росту аудитории потребляемого контента.

Стриминг и воспроизведение контента

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

Про ёмкость CDN

Далее подробней разберём, что происходит с качеством видео в Кинопоиске на этапе его сжатия. Смотрящая аудитория Кинопоиска в начале 2022 года составляла 5,8 миллионов зрителей, а сейчас 13 миллионов, а общий TVT (сумма времени просмотра пользователями) за это время вырос в 2,8 раз.

На верхнем (синем) графике показан рост TVT фильмов и сериалов Кинопоиска за 3 года, а на нижнем (красном) показан рост трафика. Что интересного на этом графике? Во‑первых, видно, что скорость роста трафика ниже скорости роста TVT. Во‑вторых — это новогодние пики трафика, которые я отметил стрелочками.

Здесь видно, что пик трафика на новый год 2024 года меньше, чем пик годом ранее (хотя TVT за этот месяц стал больше, чем годом ранее), что показывает работу системы оптимизации. Как и почему так получилось — расскажу далее.

Как сдерживать рост трафика

Мы используем как клиентские, так и серверные подходы. Например, на клиентах мы настраиваем размеры буферов, работу механизма ABR и используем кэширование контента.

Эти способы работают, но дают несущественный процесс снижения трафика — в пределах единиц процентов. Десятки процентов дают серверные способы оптимизации трафика, а именно повышение эффективности сжатия. Чтобы эффективно сжимать большие объёмы контента и не просматривать весь видеокаталог вручную, во время обработки контента мы вычисляем метрики объективного качества.

Какие метрики мы изучали:

• PSNR — не использовали в проде

• SSIM — использовали до ноября 2023 года

• MS‑SIM — используем сейчас

• VMAF — начали использовать в декабре 2024 года

Метрики качества видео мы рассчитываем для работы нашей системы оптимизации качества видео ZeroPass‑ это семейство алгоритмов per‑scene‑сжатия, позволяющих гибко управлять балансом «битрейт видео — качество видео — ресурсы на сжатие».

Для более глубокого погружения в тему советую ознакомиться с докладами моего коллеги с предыдущих конференций:

• Константин Торопин — На пути к снижению битрейта (PlayButton 2022)

• Константин Торопин — Как экономить битрейт без вреда для пользователей (VideoTech 2023)

Основные версии ZeroPass, разработанные в нашей команде за три года:

• 1.0 (12.2021) — Первая версия на SSIM

• 1.1 (06.2022) — Constant Delta, линейный поиск

• 2.0 (08.2023) — Бинарный поиск, метрики внутри кодеков, уход от 3-pass

• 2.1 (10.2023) — Переход на MS‑SSIM

• 3.0 (12.2023) — Переход к интерполяциям

• 3.1 (01.2024) — Улучшение fallback‑ов, Capped CRF, поддержка HDR

• 3.2 (12.2023) — Тестирование Multiply Delta на новый год

• 3.3 (06.2024) — Тестирование VMAF на 1080p

• 3.4 (12.2024) — Переход на VMAF

Тестовые версии — 3.2, 3.3 и 3.4. Остальные мы использовали в проде в течение долгого времени.

На графике ниже — относительная статистика того, какие версии ZeroPass «живут» в Кинопоиске относительно используемых в них метрик: по оси Y — 100% видео Кинопоиска, по X — изменение плотности разных версий Zero Pass по времени за последний год.

Как видите, с начала 2024 года мы перешли на ZeroPass с метрикой MS‑SSIM, и им уже обработана половина каталога. Также есть классический небольшой «длинный хвост» из мало просматриваемых видео, которые никак не оптимизированы.

Отдельно выделен момент использования версии Zero Pass V3.2, которая ушла в прод в начале 2024 года и помогла оптимизировать трафик во время пиковой новогодней нагрузки на нашу сеть доставки контента.

К новому 2024 году мы подготовились заранее, когда осознали, что упираемся в инфраструктурный потолок и не умещаемся в ёмкость CDN. Было принято решение создать и раскатить версию ZeroPass, которая более агрессивно сжимает видео. Это значит, что мы немного уронили качество изображения (в среднем на 0.000 095 пункта по MS‑SSIM) на период с января по середину февраля, что привело к уменьшению среднего битрейта видео и, соответственно, к сокращению трафика, а после новогоднего пика нагрузки откатили изменения и вернулись к старой, менее агрессивной схеме оптимизации.

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

На графике выше пунктирной линией показаны TVT и трафик всего Кинопоиска, включая кетчапы, прямые эфиры и трейлеры. Если бы мы никак не оптимизировали трафик, он бы рос точно так же, как график TVT — их графики накладывались бы друг на друга.

Наша цель на грядущий новый год — оптимизировать трафик таким образом, чтобы не ронять качество. И мы придумали, как это сделать.

Как работал ZeroPass v0

Давайте на примере серии «Рика и Морти» посмотрим, как работала первая версия ZeroPass, которая так и не вышла в прод. Мы использовали её три с половиной года назад в процессе нашего RnD и в разработке первой версии для продакшн‑использования. У меня сохранились слайды из наших внутренних презентаций, делюсь ими. Рассмотрим кодирование в AVC в разрешение 1080р.

На графике отмечены 4 разных момента времени скриншотами из соответствующих этому времени сцен. Первый скриншот — много движений в кадре, второй скриншот — мало движений (диалог) третий скриншот — опять много движения в динамической сцене. Последний скриншот — титры (почти без движения в кадре).

Верхний график с битрейтом 6 мегабит — это наше линейное кодирование, когда мы не используем оптимизацию трафика (здесь отображён именно средний битрейт, поэтому в виде прямой линии. На самом деле эта линия битрейта не прямая — это покажем на следующих графиках). А красный график вверху — это битрейт после кодирования с помощью ZeroPass v0, в нём был реализован подбор битрейта к ~20-секундным фрагментам видео, поэтому ступеньки битрейта на графике такие редкие.

Нижние графики — это метрика PSNR линейного кодирования (синий график) и кодирования с помощью ZeroPass v0 (красный график). Видно, что благодаря работе нашего алгоритма метрика немного выровнялась и перестала так сильно «скакать» — теперь она стремится к значению в районе около 47–48 единиц по PSNR. Ещё раз отмечу, что это был прототип, и в продакшн‑окружении мы не использовали оптимизацию на основе метрики PSNR.

Мы видим, что в сценах, где движения много, наш алгоритм повышает битрейт — даже видны вылеты за 6 мегабит, что допускалось в нулевой версии ZeroPass, но в текущих версиях этого уже не происходит. Мы контролируем, чтобы пиковый битрейт видео в разрешении 1080р не превышал 6 мегабит в секунду.

А теперь посмотрим, как будет работать будущая версия Zero Pass V4, которая на данный момент (декабрь 2024 года) ещё не в проде — мы готовим её прямо сейчас, и релиз состоится до конца 2024 года. Внутри себя она будет делать оптимизацию на основе метрики VMAF, но мы покажем расчеты и по VMAF, и по MSSIM, чтобы вы увидели, как по‑разному работают эти метрики.

Возьмём ту же самую серию «Рика и Морти». На нижнем графике синяя линия — среднее почанковое значение метрики ms‑ssim обычного линейного VBR кодирования с целевым битрейтом в 6 мегабит, а красная — это также MS‑SSIM, но уже от кодирования через нашу систему оптимизации ZeroPass V4.

На верхних графиках отображён битрейт каждого чанка — синяя линия это обычное VBR‑кодирование, а красная — это ZeroPass V4. Видно, как сильно скачет битрейт чанков при VBR‑кодировании. Хоть среднее значение и получается, как мы и попросили, 6 мбит/сек, но разброс битрейтов между чанками очень высокий, и это сложно объяснить чем‑то, кроме желания кодека во что бы то ни стало в среднем «попасть» в заданный нами целевой битрейт. Красная линия вверху — это битрейт наших 4-секундных чанков, полученных в ZeroPass V4. Видна зависимость получаемого битрейта от значения метрики.

На сценах с обилием движущихся сцен идут пики по битрейту и провалы по метрикам. На статичных сценах — наоборот. Тут MS‑SSIM приведён просто как пример, но на самом деле мы будем рассчитывать битрейт внутри этого алгоритма на основе значений метрики VMAF.

В версии Zero Pass V4 мы можем гибко управлять целевым качеством и получать различные значения целевого битрейта. В данном примере мы получили средний битрейт оптимизированного видео 1,6 мбит/сек (анимация в среднем требует меньшего битрейта, чем фильмы и сериалы) — и мы умеем двигать эти «средние» 1.6 мегабита как вверх, так и вниз для достижения необходимого нам целевого качества. И это целевое качество в ZeroPass v4 мы оцениваем по метрике VMAF.

Вот перед нами тот же самый мультик, но уже разложенный по метрике VMAF — здесь отчётливо видно, что мы стараемся держать метрику в одном пределе: 94–95.

Рассмотрим другой пример.

Эпизод сериала минут 40 длиной, битрейт и метрика MS‑SSIM его линейного кодирования — синие графики, а красные — это битрейт и значение MS‑SSIM при кодировании в ZeroPass v4.

Первая сцена — знаменитый пешеходный переход в Токио, где все люди начинают ходить одновременно, там гигантское количество мелких деталей. Видно, как по MS‑SSIM у него идёт провал, и в это время алгоритм делает пик битрейта, потому что очень много мелких деталей.

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

Третья сцена — студент перелистывает книжку очень быстро, множество мелких деталей, тоже видим, как битрейт подскакивает.

Последняя сцена — это титры, битрейт вообще в минимуме в районе нескольких сотен килобит.

Вот так выглядит рассчитанная метрика VMAF, здесь видна эффективность работы алгоритма с точки зрения попадания в метрику.

Мы попросили ZeroPass V 4 выдерживать 93 по VMAF, и тут видна явная прямая линия (красный график метрики VMAF внизу) — алгоритм всеми силами старался соблюсти значение метрики. Семейство алгоритмов ZeroPass эволюционировало, и мы пришли к тому, что мы можем просить не просто сжать контент, а попросить сжать в определённое качество. И ZeroPass контролирует это — мы получаем стабильное значение метрики. Кроме этого, мы можем настраивать, какое целевое качество нам нужно на выходе — то есть мы можем эту красную линию VMAF осознанно двигать как вверх, так и вниз. И вместе с этим, соответственно, изменится и график битрейта. Таким образом, мы научились управлять средним битрейтом видео — и, как следствие, полосой пропускания всего нашего CDN, напрямую через метрику качества VMAF.

Как устроен объективный контроль

Кроме работы с объективными метриками, мы проводим субъективный контроль датасета со сложными сценами.

Вот пример разницы в разных версиях алгоритма:

Это увеличенная центральная часть кадра, на первый взгляд, в ней всё отлично, но версия Zero Pass V1 (слева) давала нам артефакты на небольших движущихся объектах. В кадре движется только человек по центру, и Zero Pass V1 «квадратил» его при движении, а вот следующая версия Zero Pass V2 (справа) убрала эти крупные пиксели. И вот тут можно, конечно, долго вглядываться, но различия между исходником от правообладателей и Zero Pass V2 — минимальны.

Вот сравнение на темных сценах.

Тут также видно, что ZeroPass v1 расквадратил движущиеся объекты в тёмной сцене, и что в ZeroPass V2 этой проблемы нет.

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

Подробно про наш транскодер мы рассказывали вот здесь:

• Андрей Рикунов — Параллельный транскодер — это сложно? (PlayButton 2021)

• Михаил Мазанов — Система параллельного кодирования видео Кинопоиска (VideoTech 2021)

Перед тем как обрабатывать видео, мы режем его на небольшие кусочки — от 5 до 2 минут (это гибко настраивается). Эти кусочки кодируем в параллельном режиме в облаке, потом их склеиваем и, соответственно, отдаём уже пользователям в стриминг.

Это позволяет нам довольно быстро обрабатывать очень небольшие исходники и уменьшать нагрузку, которую создаёт перебор вариантов кодирования в алгоритмах.

Вот для примера график нагрузки на нашу квоту от декабря 2023. Видно, что в пике мы используем 60 тысяч ядер — и это не предел.

Аналитические дашборды результатов транскодирования

Этот дашборд позволяет оценить, сколько ресурсов мы потратили на кодирование одного или нескольких видео. Вот здесь сверху отфильтровано всё по одной серии «Преступления и наказания»: на эту серию, которая длится примерно 40 минут, мы потратили примерно 6 тысяч ядер‑часов, и кодирование длилось 20 часов.

Мы на самом деле можем и быстрее, просто увеличив степень параллельностим. В данном примере мы нарезали серию на 5-минутные фрагменты, но можем как увеличивать, так и уменьшать степень параллельности и, соответственно, ускорять или замедлять время кодирования. Кому‑то может показаться, что 6 тысяч ядер‑часов — это много, но такова наша реальная текущая плата за обработку SDR и HDR‑версий видео в разрешении 4K с использованием алгоритма оптимизации ZeroPass. И эти затраты на ядра кратно ниже затрат на трафик, который сгенерировало бы неоптимизированное видео.

На дашборде показан средний битрейт всех видео Кинопоиска за последние 3 года. Видно, что за это время с помощью ZeroPass мы снизили средний битрейт видео примерно на 40% — с 6 мбит/сек до 3.6 мбит/сек для разрешения 1080p (около 80% просмотров идёт в этом разрешении).

Помните, я начал статью с того, что у нас есть TVT и общий трафик — трафик фильмов и сериалов. Мне всегда хотелось понять как вообще эти данные друг в друга пересчитываются.

Я построил график по TVT и померил разницу в процентах между скоростью роста синей линии и скоростью роста красной линии — TVT и трафика.

На самом деле, я получил те же самые 40%. То есть мы на графике среднего битрейта мы видим экономию 40% битрейта по общему каталогу фильмов и сериалов, а на графике роста TVT и трафика мы подтверждаем эти данные по исторической статистике за три года — мы обеспечили замедление скорости роста трафика на те же самые 40%. Это наглядное подтверждение результатов работы нашей команды на больших данных.

Что ещё мы планируем

Тема оптимизации трафика очень большая, и задачи становятся в разы масштабней, чем 3 года назад. Наши планы на будущее:

• Поддерживать новые кодеки (HEVC для HD‑контента — делаем прямо сейчас, релиз в декабре 2024, AV1 — изучаем покрытие устройств и степень размытия кэшей CDN).

• Использовать разные параметры сжатия для разных типов контента, подбирать их с помощью ML (AVC ~50 параметров, HEVC ~200 параметров).

• Запустить динамический подбор качества отдачи — например, имея несколько вариантов сжатия 1080p, можно оптимальнее утилизировать полосу CDN как в пиковые часы, так и во время простоя.

• Оптимизировать Live‑трансляции (подбор статичных параметров динамическая оптимизация на лету; ZeroPass для Live‑трансляций).

• P2P‑стриминг.

Если у вас есть вопросы по оптимизации трафика, пишите в комментариях, с удовольствием отвечу.

_{В публикации использованы фрагменты из фильмов и сериалов: John Wick 4 by Chad Stahelski, Lionsgate // Rick and Morty series by Justin Roiland & Dan Harmon, The Cartoon Network // Tokyo Vice series by J. T. Rogers, HBO}