Привет, Хабр. Меня зовут Павел Муханов. Я руководитель лаборатории качества видеоплатформы VK.

ВКонтакте, ОК, VK Клипы, VK Видео и другие сервисы VK, предоставляющие возможность просмотра видео, используют в качестве core-технологии видеоплатформу VK. Она объединяет видеохостинг, стриминг и облачное хранилище и предоставляет аудитории бесшовный доступ к огромной библиотеке контента. Чтобы гарантировать стабильную работу видеоплатформы — предсказуемое качество видео и корректную работу плеера, — мы в лаборатории качества внимательно следим за метриками.

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

Возможные проблемы видео и их причины

При проигрывании видео может возникать довольно много отклонений. Например:

• Долгий первый кадр. Пользователь запускает видео, но вместо того, чтобы начать просмотр, видит долгую анимацию загрузки

• Столлы (зависания). Пользователь начинает смотреть видео, но видеоряд периодически зависает

• Низкое разрешение. Видео запускается без проблем и в нужном качестве, но во время просмотра качество снижается до некомфортного уровня (например, до 144р)

Помимо этого, могут возникать и проблемы на уровне приложения:

• быстрая разрядка батареи

• чрезмерный нагрев устройства

• медленная работа приложения

Основные причины таких отклонений во время воспроизведения видео:

• дезадаптация к пропускной способности сети, из-за чего плеер выбирает неправильное разрешение

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

• баги в клиентах и на бэкенде

Чтобы свести такие проблемы к минимуму, наша лаборатория качества регулярно проводит:

• замеры качества видео (VMAF, столлы, первый кадр)

• регресс релизов видео и звонков

• мониторинг работы приложений и не только 

Мы проводим black box тестирование — не используем специально подготовленные билды, а проверяем всё на продакшен-сборках.

Нам как команде платформы важно:

• иметь инструмент для оценки качества продуктов

• прокачивать внутреннюю экспертность

• исследовать конкурентов, чтобы находить точки роста для развития собственных продуктов

Методы измерений качества видео

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

Метрики, которые применяем мы в видеоплатформе VK для оценки качества:

• PSNR (Peak Signal-to-Noise Ratio)

• SSIM (Structural Similarity Index Measure)

• VMAF (Video Multi-Method Assessment Fusion)

На каждой из них остановимся чуть подробнее.

PSNR 

PSNR — референсная метрика, которая считается покадрово и измеряет отношение пиковой мощности сигнала к среднеквадратичному шуму. Чем выше значение PSNR, тем лучше качество изображения. Покажем, как она вычисляется.

Для начала нужно вычислить значение MSE (средняя квадратичная ошибка между двумя изображениями), чтобы использовать его дальше в расчётах: 

Здесь MAX — максимальное возможное значение пикселя (например, 255 для 8-битного цвета).

Преимущества PSNR:

• очень легко вычислить и интерпретировать

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

SSIM

SSIM — референсная метрика, основанная на покадровом сравнении структурных компонентов изображений. Она сравнивает яркость, контраст и структуру двух изображений. Значение SSIM варьируется от −1 до +1, где +1 означает полное совпадение.

Формула для расчёта SSIM:

Здесь μ — среднее значение интенсивности пикселей, σ — дисперсия интенсивности пикселей, а c₁ и c₂ — константы для стабилизации формулы.

Преимущества SSIM:

• учитывает яркость, контрастность, структуру и другие характеристики, важные для восприятия видео

• позволяет нам лучше понимать, как пользователь воспринимает изменения, возникающие из-за компрессии или обработки изображений

VMAF

VMAF — современная референсная метрика, объединяющая несколько методов анализа, среди которых:

• VIF (Visual Information Fidelity)

• DLM (Detail Loss Metric)

• MCPD (Mean Co-Located Pixel Difference)

Важное отличие VMAF от классических метрик, например PSNR — в неё добавлена специализированная обученная модель, построенная на искусственных нейронных сетях. Она способна выявлять нюансы восприятия видео человеческими глазами.

Преимущества VMAF:

• точно отражает восприятие качества человеком

• учитывает одновременно структуру, движение и артефакты, что важно для целостной оценки

• совместима с современными кодеками (например, H.265, AV1)

• предоставляет результат в виде числа от 0 до 100 — это просто и удобно в работе

Мы используем эти метрики в комплексе, чтобы оптимизировать процессы:

• быстрая метрика SSIM вычисляется для каждого видео

• медленная метрика VMAF вычисляется для специально подготовленного датасета

Расскажем, как мы оцениваем работу плеера.

Методы измерений первого кадра и столлов

Основные метрики, которые нам нужны для оценки работы плеера:

• время показа первого кадра

• суммарное время столлов

• стартовое разрешение

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

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

Примечание: также разметка позволяет фиксировать и дропы кадров (пропуски), но это более актуально для видеозвонков.

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

По нему видно, что:

• мы начинаем стартовать при зажатой сети

• ждём, пока появится первый кадр

• после этого немного отпускаем сеть, плеер воспроизводит видео с хорошим битрейтом

• затем зажимаем сеть сильнее, чем в начале

• в какой-то момент плеер не успевает набрать данные в буфер — и появляются зависания

Разберём несколько примеров графиков исследования плеера.

Примеры графиков исследования плеера

Возьмём сценарий, когда:

• стартуем с безлимитной скоростью

• проигрываем видео до наполнения буфера

• режем скорость до 128 Кбит/с

• возвращаем скорость до 4 096 Кбит/с

График покажет, что буфер наполняется, а после плеер начинает быстро потреблять данные. Когда буфер пустеет, плеер зависает. После возвращения скорости до 4 096 Кбит/с буфер начинает наполняться. Но полосы пропускания недостаточно, чтобы набрать полный объём, поэтому дальше плеер проигрывает видео с буфером, заполненным примерно наполовину.

График изменения разрешения видео в этом случае будет такой:

Плеер начинает воспроизведение с разрешением 1080р, а когда буфер пустеет, разрешение падает до 144р. С ростом скорости сети качество постепенно повышается до 720р, но уже не возвращается до исходных 1080р. Это пример неидеальной работы плеера.

Но возможны разные варианты. Например, у нас другие условия:

• стартуем с безлимитной скоростью

• проигрываем до наполнения буфера

• режем скорость до 128 Кбит/с

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

При этом на графике разрешения чётко видно, что воспроизведение начинается с разрешения 720р, а после наполнения буфера переходит на 2К. Как только буфер опустеет, разрешение упадёт до 144р до момента, пока буфер снова не наполнится. 

Инструменты

Для оценки качества видео мы используем несколько инструментов.

QLAB

QLAB — самописный фреймворк для запуска замеров. Он состоит из нескольких сервисов:

• Hub

• Task Scheduler

• Node

• Сервер

На CI QLAB работает так:

• задача попадает в GitLab-агент

• GitLab-агент идёт в Task Scheduler

• Task Scheduler отправляет задачу на Hub

• Hub отправляет задачу на выбранную ноду — подключённое устройство, с которого нужно снять метрики

• метрики с устройства отправляются на Hub

• Hub отправляет метрики в сервис анализа

• сервис анализа отправляет их в ClickHouse и Superset

QLAB нужен для запуска любых сценариев, записанных в JSON. Сценарий обычно состоит из нескольких шагов:

• установка клиента или клиентов

• запуск клиента или клиентов

• порча сети выбранным способом

• начало записи экрана

• старт замера

• основное действие (например, включить видео)

• остановка записи экрана

• анализ

• стоп

Нам важно проверять работу плеера в условиях не только хорошей, но и плохой сети. Поэтому мы добавили во фреймворк различные механизмы, которые позволяют эмулировать потери пакетов (Packet loss), задержки (Delay) и просадки ширины канала (Bandwidth) — это делается с помощью стандартной Linux-утилиты tc netem (Traffic Control Network Emulator).

Также мы можем использовать и более сложные сценарии. Например:

• Jitter — нестабильность или колебания времени доставки пакетов

• Reordering — перестановку порядка следования пакетов при передаче

Nimbus

Это самописный сервис для анализа видео, который умеет считать VMAF/SSIM/PSNR и DOVER. Nimbus подходит для пакетной обработки и может выгружать таблицы с результатами в базы данных.

Nimbus позволяет отслеживать результаты оценки качества видео по различным метрикам практически для каждого кадра.

Также Nimbus позволяет строить IPB-графики (intra-frame, predicted frame, bi-directional predicted frame graph). Это структуры кадров, которые применяются в кодировании видео для оптимизации сжатия и уменьшения размера видеопотоков.

Примечание: I — ключевой кадр, P — предсказанный на основе I-кадра, B — предсказанный на основе кадров I и P.

Алгоритм работы с Nimbus прост. Например, указываем ссылку на интересующее нас видео. Сразу после этого можем увидеть все доступные версии видео с разным разрешением, включая оригинал, и скачать нужную нам.

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

Далее можем посмотреть diff между кадрами и посчитать VMAF.

На выходе получаем график распределения VMAF и его значение — в нашем случае оно равно 90.

Также Nimbus можно использовать для проведения регресса транскодеров. При этом:

• датасет формируется на основе статистики о просмотрах и загрузках

• есть датасет роликов по обращениям пользователей (артефакты после нарезки, видео дёргается)

Регресс мы проводим на тестовом окружении:

• мы загружаем видео в тестовый канал, где оно нарезается

• скачиваем нарезку, формируем архив для Nimbus и сохраняем его в S3

• Nimbus получает уведомление, что архив готов, и скачивает его из S3

• идёт оценка

• результаты загружаются в ClickHouse или YT

Полный прогон занимает 4 часа.

На выходе получаем результаты RD (Rate Distortion). Они показывают оценку эффективности транскодеров видео и аудио на основе сравнения видео, одно из которых закодировано нашим пресетом, а другое — стандартным:

VK: 1080p VMAF — 96,4, bitrate = 2 490 kbps/s

baseline: 1080p VMAF — 97,2, bitrate = 3 602 kbps/s

baseline: >ffmpeg -i original_file.mp4 -c:v libx264 -y out.mp4

VK: 1080p VMAF — 93,6, bitrate = 1 560 kbps/s

baseline: 1080p VMAF — 95,1, bitrate = 2 500 kbps/s

baseline: >ffmpeg -i original_file.mp4 -c:v libx264 -y out.mp4

Мониторинг

Мониторинг проводим регулярно, используем разные сетевые условия:

• limits_10min_receiver_net_good — хорошая сеть — по сути, без ограничений

• limits_10min_receiver_net_medium — средняя — 3 мбит, 3% потерь, задержка 50 мс

• limits_10min_receiver_net_bad — плохая — 1 мбит, 8% потерь, задержка 250 мс

Запускаем его на реальных устройствах.

Используем такой мониторинг для проверки разных сценариев. 

Например:

Немного о нашем стенде

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

Стенд состоит из:

• двух контуров. В dev-контуре идут разработка и исследования, в prod — запускаются мониторинги

• двух роутеров для ухудшения сетевых условий

• умных розеток

• USB-термометров

• PC 32 cores, 4 080 (CUDA)

Результаты и планы на будущее

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

• до 40% снизить битрейт видео в зависимости от типа контента без потери качества

• на 25% снизить трафик при просмотре видео

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