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

Меня зовут Александр Коншин, я Тимлид команды Computer Vision в онлайн-кинотеатре Иви. 15 лет пишу код. 5 из них посвятил нейросетям и обработке изображений. Сейчас создаю сервисы, которые генерируют промо-контент для фильмов и мультиков с помощью алгоритмов машинного обучения и компьютерного зрения. Мы работаем с длинным контентом в виде фильмов, сериалов или мультфильмов и дополнительными материалами: трейлерами, фильмами о фильме, хайлайтами — короткими форматами, которые помогают пользователю быстро ознакомиться с содержанием.

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

Зачем генерировать трейлеры и хайлайты самостоятельно

Прежде, чем перейдём к теме статьи, обозначу разницу в терминах:

Трейлер — это законченное художественное произведение. Примерно за 2-3 минуты помогает влюбить человека в длинный фильм и сделать так, чтобы он его посмотрел. Трейлер запускается по желанию пользователя — когда он сам переходит на это видео.

Хайлайты — это короткие визуальные истории на 20-40 секунд, такие яркие кадры, которые стартуют автоматически и привлекают внимание человека, пока он просматривает ваш ресурс. Они помогают поймать взгляд и вызвать интерес.

У нас была гипотеза, что динамичное промо для фильма даёт больше конверсий в просмотр, чем обычный постер на странице. Чтобы проверить, запустили серию А/Б-тестов, где показывали гостю страницы о фильме автоматически стартующий хайлайт. Дальше посчитали конверсии в просмотры и оценили профит: вышло, что если раскатать такой подход на весь контент, мы получим около 200 миллионов рублей в год, что очень неплохо.

Для нас это означало хорошую возможность развивать продукт. Но с такой идеей было две проблемы:

1. Трейлеры есть не у всего контента. Из 80 000 единиц видео только 30% покрыты нормальными трейлерами.

2. Готовых хайлатов почти нет.

Трейлер для одного полуторачасового видео собирается около двух месяцев. Видео нужно нарезать так, чтобы оно было интересным, продавало и человек захотел посмотреть полную версию фильма. В США это делают продюсеры и специально обученные монтажеры. У нас свой собственный продакшн, и процесс создания трейлера — это многоэтапный квест в несколько версий с согласованиями. Это значит, что если наш продакшн по какой-то причине облажается, и у нас будет фильм, но не будет к нему трейлера, то придётся ждать ещё полтора месяца, пока не получим новый трейлер.

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

Как мы генерировали трейлеры

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

Собрали опыт и данные для модели

Чтобы понять, как устроено производство трейлеров, мы расспросили команду продакшена: как они работают и на чём фокусируются. Узнали, на что смотрит монтажёр, на что смотрит режиссёр, и побежали смотреть, какие у нас есть данные, чтобы начать работу.

В итоге на старте у нас было:

1. Некоторое количество трейлеров. Примерно 30% всего видеоконтента.

2. Создатели видеоконтента, которые знают, как правильно собрать хороший трейлер.

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

Определили понятия

Сцена — это определённый отрезок времени в фильме, объединённый местом действия и актёрами.

Шот — это расстояние от одной монтажной склейки до другой. Сцены состоят из шотов. А шоты состоят из кадров.

Кадр — статическая картинка, из множества которых состоит видео.

Научились определять части фильма, подходящие для трейлера

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

1. Нарезали видео на шоты от одной монтажной склейки до другой, две версии файлов: видеофайл с длинным видео и готовый трейлер, который для него уже создал человек.

2. Сравнивали шоты и искали среди них равные. Если есть равенство, шот считали хорошим.

Чтобы оценить шоты, мы взяли фичер экстрактор, который сами доработали. В него закидывали 3 кадра из шота,. затем полученные фичи аггрегировали, и на выходе имели значения от 0 до 1, где 0 — совсем не подходит для трейлера, 1 — подходит.

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

Обучили модель

В результате собрали модель, которую обучили на основании того, как люди создают трейлеры. Но это всего 30% успеха, если не меньше, потому что из модели предстояло сделать работающий продукт.

Как генерировали хайлайты

Общая схема генерации хайлайтов: генерируем шоты, делаем из шотов сцены, из сцен отбираем подходящие и собираем хайлайты.

Далее подробно про каждый этап.

Сгенерировали шоты

1. Определили монтажные склейки.

Это можно сделать с помощью FFmpeg: вычислять покадрово статистики яркости пикселей, и в местах резких скачков считать, что произошла монтажная склейка. Но есть минусы в его использовании. В динамических сценах, когда кадры резко сменяют друг друга, будет найдено много ложных склеек, а плавные склейки, типа фейд-ин и фейд-аут, наоборот скорее всего не будут обнаружены.

В поисках альтернативных решений мы нашли модель, которая по скорости не хуже, чем FFmpeg, а по качеству превосходит его в полтора раза. С её помощью определили шоты.

2. Вытянули шоты из кадров, но здесь держали в уме две вещи:

В шотах могут быть титры. Но так как у титров есть известные нам координаты, то делаем фильтрацию и находим то, что надо убрать.

В шотах попадаются спойлеры. Если спойлер попадает в трейлер или хайлайт, фильм дальше смотреть не интересно. Искать спойлер и обучать под это модель — неподъемная задача. Поэтому мы просто убирали всё, что во второй половине фильма, и брали первую.

Как результат — получили фильм, нарезанный на шоты, отфильтрованные по эмпирическим правилам.

Собрали сцену из шотов

1. Объединили непересекающиеся сцены и отрегулировали фильтры

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

Не забываем про ограничения по времени сверху и снизу. Берём только те, которые не короче N секунд и не длиннее M секунд.

Например, если нужен более динамичный трейлер, то берём более короткие сцены. Если хотим больше диалогов, то ставим 70 секунд и более.

2. Исключили все сцены, которые обрезали речь персонажей.

С помощью модели на фичах mel-спектрограмм и классификаторе Net-VAD (на основе CNN) обнаруживаем границы речевой активности и обрезаем сцены, которые её прерывают.

Если это не сделать, сцена будет обрываться и не подойдёт для дальнейшей работы.

3. Проранжировали весь набор данных: насколько вероятно, что из них получится трейлер.

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

Сгенерировали хайлайт

На входе алгоритма сразу вводим параметры, которые регулируют динамичность как хайлайта, так и сцены:

1. Определяем, сколько хайлайтов нужно создать.

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

3. Сортируем сцены по времени.

4. Отбираем финальных кандидатов.

Что получилось и как оценивали результат

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

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

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

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

Что оценивали:

1. Качество нарезки сцен.

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

2. Качество ранжирования сцен между собой.

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

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

Ограничения метода

Не обойтись без постмодерации

В процессе тестирования мы выяснили, что не все хайлайты мы имеем право публиковать на нашем ресурсе. Даже если они крутые и, на первый взгляд, хорошо конвертируют просмотр. Некоторые из них могут нарушать законы Российской Федерации, или вовсе не проходят цензуру.

Вывод: мы автоматизировали производство, но совсем избавиться от постмодерации не получается.

Не подходит для сериалов, мультфильмов и спорта

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

Сериалы

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

 

Мультфильмы

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

Поэтому для детского контента в ML всегда отдельное направление, которое строит отдельные модели.

Спорт

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

Конечно, можно обучить модель на какие-то кульминационные моменты каждого вида спорта: голевая передача, гол, нокаут. Но есть более простой статический метод: вы парсите текстовую трансляцию, где важные моменты фиксируются по точному времени, отступаете пять секунд назад, делаете 10-секундный ролик, и получаете видео ситуации, которая привела к голу. Работает практически безотказно.

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

Как внедряли модель в продакшен

Итак, у нас есть модель, и мы верим, что она классно работает. Запускается силами инженеров computer vision на тестовых стендах, и пропускная способность для нашего бизнеса — около 10 хайлайтов в неделю. Нам хотелось быстрее, плюс нужно было это дело как-то внедрять.

Синхронизация команд 

У нас две команды: разработка — занимается пайпланом кодирования, и computer vision — занимаются RnD. Каждая из команд погружена в свои задачи и бэклоги у них отдельные.

Например, у команды энкодера может быть куча задач о том, как сделать нормальный Downmix из 5.1 в Stereo, потому что при адаптивном стриминге скачет уровень звука. Команда CV работает с моделями. Поэтому, чтобы синхронизировать работу, ребята из computer vision взяли гайды работы системы кодирования и добавили в неё свой дополнительный модуль. А команда разработки сделала ревью.

GPU или CPU

Замеры скорости показали, что на GPU пайплайн работает примерно в 2 раза быстрее, чем на CPU. Выигрыш не слишком большой, потому что некоторые этапы типа кеширования шотов или даунскейл пока работают только на CPU.

Так как GPU у нас было мало, а CPU — много, остановились на последних. Потому что практически любая кодирующая машина может сделать эти операции.

Внедрение

Мы не сразу нашли решение и внедрить модель получилось только с четвёртой попытки. Рассказываю, какие шаги мы прошли до финального результата.

Попытка 1: работа с исходниками

Когда модуль разработали, его нужно было внедрить в пайплайн кодирования. Но с первого раза ничего не получилось: модель тренировалась на видео 720*300, а система кодирования работает только с оригинальными исходниками.

Исходник – это полученное от студии или правообладателя, или производителя контента классное, несжатое, большое видео в максимальном разрешении.

Как результат работы с уменьшенным форматом мы имели регулярные падения и низкую скорость работы.

Попытка 2: DownScale исходника

В поисках решения сделали DownScale оригинала и попробовали запустить модель с ним. Скорость работы оказалась очень низкой. Так развалился первый костыль, на который мы хотели минимально потратить ресурсы разработки.

Попытка 3: использование файлов, готовых к стримингу

Решили использовать файлы, готовые к стримингу, для поиска координат, из которых потом можно нарезать готовый хайлайт. Всё хорошо полетело и первое время даже работало. Оказалось, нам везло: пока FPS исходника совпадал с FPS файла, готового к стримингу, модель работала, как только частота отличалась — всё развалилось.

Файлы, готовые к стримингу, мы приводили к одному FPS, чтобы плееры на разных устройствах не сошли с ума. К примеру, если сначала у файла 25 FPS, потом 30, потом 40, то какой-нибудь корейский телевизор расскажет всё, что он думает о разработчиках, и уйдёт в жёсткий ребут. Поэтому у нас получались кривые шоты, из кривых шотов получились кривые сцены, из кривых сцен получались кривые хайлайты.

Наш короткий вывод: сделать отдельный флоу.

Попытка 4: использование файлов, готовых к стримингу, в низком разрешении

В итоге взяли готовый к стримингу файл в низком разрешении. Из него получили координаты шотов. Дальше взяли максимальный файл по битрейту в высоком разрешении и на основании координат сделали хайлайты. И модель полетела.

Выводы

Мы построили модель по производству синтетических трейлеров и хайлайтов на основе готовых видео-файлов и опыта создателей видеоконтента. Из неё сделали работающий продукт.

Что важно учесть:

1. Несмотря на автоматизацию производства, мы не смогли обойтись без постмодерации контента и подключения человека: например, для проверки на цензуру и юридическую чистоту сцен. Как легальный сервис мы соблюдаем законы РФ.

2. У модели и той последовательности шагов, которые я описал, есть ограничение: модель не подходит для создания трейлеров и хайлайтов для сериалов, мультфильмов и спортивных трансляций. Для них нужно искать отдельное решение.

3. Важно внимательно подойти к выбору инструментов при подготовке модели: некоторые из них нам пришлось дорабатывать самостоятельно, а какие-то, например, Net-VAD классификатор, пропал из общего доступа.

4. Ссылки на инструменты, которые мы использовали в работе над моделью:

Модель для детекции шотов

Экстракторы фич

24 и 25 ноября при поддержке генерального партнера - компании 1С - на конференции HighLoad++ пройдет открытая трансляция главного зала. Доступно абсолютно всем, просто подключайтесь и смотрите крутые доклады. Подробности по ссылке

До встречи в эфире!