Привет, я Василий Коровин, аналитик в Yandex Infrastructure. Уже три года в команде видеоплатформы я занимаюсь аналитикой нашего плеера. Это тот самый веб‑плеер, который используется для воспроизведения видео на разных сервисах Яндекса (например, на Кинопоиске, Диске, Практикуме и Погоде). А также с этого года он доступен в облачном сервисе для хранения, обработки и трансляции видео Cloud Video.

Мы подробно рассказывали о разработке плеера тут и тут. Сегодня же хочу рассказать, как мы понимаем, нравится или не нравится людям им пользоваться. Для этого нам пригодится аббревиатура QoE — с английского она расшифровывается как «quality of experience», и переводится как «метрика качества восприятия» пользователями нашего сервиса.

Скрытый текст

Чуть-чуть теории и примеров

С QoE есть одна проблема, которую проще объяснить на примере. Допустим, вы встречаете коллегу и спрашиваете: «Насколько ваш начальник вырос за прошлый год?» Он может вам ответить, мол, на пять сантиметров, а нужно было на семь. И вы оба прекрасно понимаете, о чём говорите.

В случае с QoE нет такой единой метрики — это, скорее, семейство метрик, и многие придумывают что‑то своё. Как принято в Яндексе, мы тоже придумали своё, опираясь на доступные знания.

Сам по себе QoE можно разделить на две части. Это Quality of service, или какие‑то объективные метрики: то, что мы будем брать из логов. И User experience — какие‑то субъективные восприятия, опросы.

Оценить даже субъективное счастье пользователей хотелось бы в числах. И первое, к чему многие приходят, это Mean Opinion Score, или MOS. С ним мы просто берём среднее арифметическое по всем метрикам, с помощью которых оценивается качество работы системы. Тут может быть практически всё, что угодно.

Есть пара примеров, как это работает для субъективных оценок. Здесь таксисты Yandex Go оценивают меня.

Как видите, я идеальный пассажир по мнению 40 последних таксистов.

Какие проблемы есть с опросами? Во‑первых, их надо проводить. Это тоже искусство, которым у нас не всегда владеют. Во‑вторых, как говорил доктор Хаус, люди склонны врать. Если вы спрашиваете: «А как вы относитесь к „Дому-2“?», то оценка, скорее всего, будет гораздо ниже, чем реальная, потому что не все готовы сознаваться в такой любви.

Что такое MOS, разобрались. Можем ли мы теперь выразить уже полученные результаты этого MOS какими‑то формулами? В сетевых играх используется так называемая G‑модель.

В левой части мы видим результаты тех самых опросов, а в правой части кубический многочлен, где х — это число, которое считается через Ping и Jitter. Говорят, эта модель даёт точность порядка 98%. Игры наподобие Quake 4 оценивали с её помощью.

И есть ещё один пример, который ближе к нашему предмету обсуждения. Это метрика компании Huawei, которой они измеряют качество видео. В основе лежит пятибалльная, точнее даже шестибалльная шкала, поскольку включает значения от 0 до 5. Здесь учитываются три фактора.

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

Получается вот такая формула.

$U-vMOS = (sQuality-1)(1+ \frac{α(sInteraction-1) + β(sView-1)} {4(α+β)})$

Это были интересные примеры, но зачем они нужны и что мы сами хотим от своих метрик?

Зарождение и эволюция собственных метрик

У Яндекса есть очень много дашбордов, в которых содержится большой объём данных. Я сам создал больше 10 дашбордов за недолгое время работы. Нам хотелось иметь какой‑то один дашборд, в котором будет три пункта:

Понятная информация о текущем состоянии сервиса.
Информация о том, что случились какие‑то проблемы, желательно с возможностью быстро понимать причину этих проблем.
Информация о том, как изменения в коде от разработчиков влияют на работу сервиса.

Здесь стоит вернуться к тому, как вообще устроена видеоплатформа. У нас есть клиентское приложение, оно взаимодействует с Player SDK, который в свою очередь взаимодействует с двумя частями: это CDN и, собственно, видеоплатформа, где находится база контента, транскодинг и всё прочее.

Теперь обратимся к этапам развития платформы, чтобы увидеть эволюцию этих метрик.

Появляется плеер. Тогда у нас практически не было никаких логов, и всё, на что мы могли смотреть, это статус ответов CDN. Метрикой тогда была доля успешных запросов. Плюсы очевидны — мы знаем, что происходит с CDN. Минусы — мы не понимаем всё остальное. То есть, на самом деле это вообще не имеет отношения к тому, о чём мы говорим, поскольку здесь пока плеер практически отсутствует.
Появляется логирование ошибок. На этом этапе метрика — это суммарное количество ошибок, которые у нас есть. Плюсы — мы уже замечаем какие‑то причины проблем. А минусы — по сути, мы видим, что у нас работает или не работает плеер, и нет никаких промежуточных состояний. В сложных случаях мы часто не знаем, что происходит.
Начинаем собирать сообщения Heartbeat. Они говорят о том, что плеер проработал успешно 30 секунд или какое‑то другое время. Новая метрика — это общее количество Heartbeat'ов. Она уже может служить сигналом о негативных или позитивных изменениях. Минусы — мы не знаем причин этих изменений. Кроме того, понятно, что ночью люди смотрят меньше, чем днём. Соответственно, часто это падение нам ни о чём не говорит.
Обращаем внимание на «столды». Это калька с английского слова stalled, которой мы обозначаем задержки в видео. Появляется новая метрика — отношение времени столдов ко всему времени работы плеера. Понятно, что чем оно больше, тем хуже. У нас пока нет никакого разделения, мы просто видим одно большое число. Мы уже понимаем: что‑то нехорошо, что‑то хорошо, но где это хорошо и что нехорошо — всё ещё непонятно.
Наконец, когда логи приняли современный вид, в этом процессе был сделан первый важный шаг. У нас появляется так называемая сессия видеосмотрения — это комбинация VSID (идентификатор созданного плеера) и videoContentID (идентификатор контента, который мы смотрим). Если в одном плеере вы посмотрели две серии вашего любимого сериала, то это было две сессии. И каждую такую сессию мы уже можем рассматривать и оценивать как отдельную единицу.

Второй важный шаг: у нас появляются понятия событий. А событий много: это Start, изменение источника SetSource, FatalError, PlayerAlive и масса других. Здесь у нас возникает новый подход — посессионная метрика, когда мы говорим: «Давайте все события назовём хорошими или плохими и посмотрим на два последних события».

Понятно, что Start — это хорошее событие, а Error — плохое. Теперь смотрим на два последних события. Если два последних события плохие, то сессия плохая. Если два последних события хорошие, то сессия хорошая. Плюсы — мы уже неплохо определяем плохие сессии, появляется какая‑то понятность. Минусы — нам нужно постоянно следить за актуальностью нашей базы событий, потому что могут появляться новые. Если за этим не уследить, может случиться какая‑нибудь беда. И всё ещё есть проблема в хороших сессиях, потому что «плохое» могло случиться посередине.

Вся эта эволюция привела нас к формулированию новой цели в деле QoE.

Итак, какой должна быть метрика:

Простая: желательно что‑то типа «работает или не работает», без сотых процентов.
Понятная: когда мы смотрим на неё, желательно уже через три секунды понимать, что вообще произошло.
Чувствительная к изменениям: это забота о коллегах‑разработчиках, которые вносят изменения, и хотят сразу видеть эти изменения, иначе их работа будет непонятной.
Коррелирующая с нашими внутренними представлениями о прекрасном: другими словами, хотите ли вы показать такую видеосессию своей маме? Скажем, мы получили какую‑то метрику и с опорой на неё говорим: «Вот хорошая сессия», — а там столды четыре минуты, например. Мы не можем взять такой грех на душу.

Новое понимание метрик QoE

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

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

Инициализация — это старт плеера, когда идёт загрузка перед началом видео.
Прерывание — состояние, когда в середине видео пошли паузы, а вас это раздражает.
Отказ — сессия, в которой был какой‑то трафик, но при этом не было времени смотрения. То есть всё окончилось, не начавшись.
Наличие фатальных ошибок — тут все события FatalError.
Качество видео — многомерное понятие, о котором подробнее поговорим ниже.

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

Инициализация. В этом примере показано распределение времени инициализации в видеосессиях. Мы видим, что эта картинка в чём‑то похожа на экспоненту, на которой мы и выбираем границы критериев.

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

Для определения границы хорошей/плохой инициализации мы провели несколько А/B‑экспериментов: удлиняли её и смотрели, как люди отваливаются. В итоге было выбрано, что в районе до 70-го перцентиля инициализацию мы посчитали хорошей. А всё, что находится выше 85-го перцентиля, считается плохой сессией.

Буферизация прерывания. Во‑первых, чем дольше столды, тем хуже. И чем больше столдов, тем хуже. Эти две мысли можно преобразовать в математическую штуку: нам важно количество столдов (пользователя раздражает, когда много маленьких пауз) и длина максимального столда (раздражает, когда одна огромная пауза). А когда и пауз много, и они огромные — этот случай мы вообще рассматривать не будем.

Здесь у нас также построено распределение и приняты границы: 85-й и 70-й перцентиль. Вы спросите, как так совпало? Кривые здесь получились похожие.

Фатальная ошибка. Тут всё просто: если она есть, то мы считаем, что это плохо. Если фатальной ошибки нет, мы считаем, что это хорошо.

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

Качество видео. Существует много вариантов, как оценивать качество видео. Это задача, которая уже имеет какие‑то решения (наподобие VMAF), но чаще всего для них используется покадровое сравнение. Все сессии проверять довольно дорого и требовательно к ресурсам.

Нам хотелось сделать что‑то, пусть не такое точное, но гораздо более простое в расчётах. Поэтому для оценки качества видео мы подсмотрели метрику у компании Mux. Это оценка показываемой нами картинки от 100 до 0. Чтобы понять, как оно работает, нам нужно разобраться с понятием Upscale.

Допустим, вы смотрите кино в каком‑то контейнере, и видео внутри имеет какое‑то качество. Если контейнер меньше, чем качество видео, или равен ему, мы считаем, что всё хорошо. Если же контейнер больше, чем качество, то картинка получается растянутой, а Upscale считается по такой формуле.

Если картинка у вас в два раза больше, то Upscale будет считаться как 1. Довольно простая формула, мне кажется.

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

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

Казалось бы, мысль здравая. Но возможен ещё один случай: есть люди, которые сами себе ставят низкое качество. Например, я пришёл домой и включил качество ниже, чтобы сэкономить трафик. Или может быть, что я забыл очки, и мне не нужно хорошее качество, если я не вижу разницы, например.

У нас для таких пользователей есть понятие User Capping, которое сохраняется при выборе. Если пользователь сам себе поставил маленькое качество, мы тоже не хотим себя штрафовать, потому что это его сознательный выбор. Добавляем в наш минимум третий компонент, и получается вот такая формула Upscale:

Мы получаем эту формулу для каждого момента времени, считаем средний Upscale на весь период и максимальный Upscale.

Теперь появляется формула компании Mux для расчета VQS — коэффициента качества видео. Если Upscale был нулевой, то оценка будет 100. Если Upscale был больше, то и оценка, соответственно, будет меньше.

Мы ставили А/B‑эксперименты и смотрели, как люди отваливаются. Вообще оказалось, что если мы показываем плохое качество, на самом деле, люди готовы немножко терпеть, но мы не готовы. Поэтому мы ввели такие границы, как 95 баллов VQS — это уже жёлтая сессия, а 87,5 и ниже — уже красная сессия. Она соответствует примерно пятидесятипроцентному растягиванию.

Как считается итоговая метрика

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

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

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

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

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

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

Небольшой пример из жизни. Однажды у ребят произошло вот такое. Как мы видим по общему дашборду, всё стало плохо.

Буквально через три секунды мы открываем следующую страничку и находим, что ухудшилась именно метрика качества видео.

Буквально через несколько минут обнаружилось, что именно в коротких видео у нас всё стартовало с очень плохим качеством. А плохое качество для коротких видео — показывает очень большой Upscale, что будет сильно влиять. Это и произошло.

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

QoE-метрика в видеоплатформе Яндекса