QoE: время старта и ребуферинг

TL;DR

Quality of experience (QoE) – это мера того, как видео по-настоящему ощущалось при просмотре: быстро ли стартовало, играло ли без заморозок, выглядело ли чётко и не падало ли – и на OTT-платформе, той, что доставляет видео через интернет, а не через кабельную приставку, именно QoE решает, останется зритель или уйдёт. Четыре числа значат больше всего: video startup time (сколько прошло от нажатия play до первого кадра), rebuffering ratio (доля времени просмотра, в которое картинка была заморожена в ожидании дозагрузки), реально отданный битрейт (насколько чёткой была картинка) и доля сбоев воспроизведения (доля попыток, что завершились ошибкой и не проиграли вовсе). Это не инженерные vanity-метрики: знаковое исследование 23 миллионов просмотров показало, что зрители начинают уходить примерно после двух секунд задержки старта, и каждая лишняя секунда добавляет около 5,8% к доле отказов, а видео, замёрзшее всего на 1% своей длины, смотрели на 5% меньше. Эта статья даёт каждой QoE-метрике простое определение, проходит арифметику, превращающую медленный старт в потерянную выручку, называет ловушки, что прячут проблему QoE, и указывает, где живут стек измерений и инженерия.

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

Если вы управляете OTT-платформой или планируете её, QoE – это единственный набор чисел, что связывает вашу инженерию с вашей выручкой. У медиа-основателя может быть лучший каталог, правильная цена и красивое приложение – и он всё равно потеряет зрителя в первые секунды, потому что видео слишком долго стартовало или замёрзло на той самой сцене, что была важна. Эта статья для нетехнического оператора – основателя, продакт-менеджера или стриминг-руководителя – которому нужно понять QoE достаточно, чтобы ставить цели, читать дашборд и задавать инженерам правильные вопросы, не становясь инженером. Она лежит под картой OTT-аналитики, которая раскладывает три семьи стриминговых метрик; здесь мы уходим вглубь третьей семьи – качества – и двух метрик внутри неё, что вызывают больше всего потерянного просмотра: startup time и rebuffering.

Одна идея: качество – это то, что чувствует зритель, а не то, что отдал сервер

Начните с различия, что предотвращает большинство путаницы вокруг QoE. О потоке можно задать два разных вопроса. Первый – quality of service (QoS): сделали ли сеть и серверы свою работу – была ли доступна полоса, дошли ли байты, были ли низкими ошибки? Второй – quality of experience (QoE): хорошо ли провёл время зритель – быстро ли стартовало видео, играло ли плавно и хорошо ли выглядело на его экране? QoS измеряется на инфраструктуре; QoE измеряется на плеере, там, где реально сидит человек.

Эти двое связаны, но не одно и то же, и именно в разрыве между ними платформы теряют деньги. Content-delivery network может рапортовать идеально здоровые 99,99% доступности, пока зритель на перегруженном домашнем Wi-Fi смотрит на крутящийся лоадер и сдаётся. Сеть сделала своё дело; опыт всё равно провалился. В этом – суть интернет-стандарта, что управляет всей этой областью: RFC 9317 от Internet Engineering Task Force (Operational Considerations for Streaming Media, октябрь 2022) выстраивает всю проблему вокруг «quality of experience (QoE) при стриминге видео» и отмечает структурное слепое пятно – CDN «не может сказать, какой запрос принадлежит какой сессии воспроизведения… или застрял ли какой-либо из клиентов и не находится ли он в rebuffering». Байты, покидающие сервер, и опыт, доходящий до зрителя, измеряются в разных местах, и правду видит только плеер.

Поэтому дисциплина QoE – измерять то, что испытал зритель, с плеера, и стандартизировать как вы это измеряете, чтобы две команды понимали под «startup time» одно и то же. Остальная часть статьи – это набор QoE-метрик, на которых стоит стандартизироваться, цели, что имеют значение, и ловушки, что прячут проблему, пока зритель ещё не ушёл.

Квартет QoE: четыре числа, решающие, останется ли зритель

В стандартах и у крупных вендоров аналитики раз за разом всплывает один и тот же небольшой набор метрик как ядро стримингового качества. Назовём их квартетом QoE. Две из них – startup time и rebuffering – дают больше всего потерянного просмотра, поэтому им ниже отдано больше места, но все четыре должны быть на дашборде любого оператора.

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

Первая – video startup time (также video start time, VST или join time): время от мига, когда зритель нажал play, до мига, когда первый кадр реально появился на экране. Вторая – rebuffering ratio (буферизационный коэффициент или rate): доля всего времени просмотра, в течение которой видео было заморожено в ожидании дозагрузки данных. Третья – отданный битрейт: средний поток данных видео, что реально получил зритель, ближайший прокси того, насколько чёткой была картинка. Четвёртая – доля сбоев воспроизведения: доля попыток play, что завершились ошибкой вместо проигрывания – худший опыт из всех, ведь зритель не видит ничего.

Эти четыре – не список, придуманный одной компанией. Стандарт Consumer Technology Association CTA-2066 (Streaming Quality of Experience Events, Properties and Metrics, март 2020) существует именно для того, чтобы определить «набор событий медиаплеера, свойств, метрик QoE и связанной терминологии для представления стримингового QoE между системами, плеерами и вендорами аналитики» – потому что, как отмечает само вступление стандарта, эти метрики «использовались слегка (или сильно) по-разному, что вело к проблемам совместимости». CTA-2066 задаёт общую терминологию и «как каждую метрику следует вычислять для согласованной отчётности». Этот стандарт – причина, по которой ваше число startup time можно сравнить с чьим-то ещё, если все ему следуют.

Точные, инженерного уровня определения этих QoE-метрик – какие именно события плеера ограничивают каждое измерение – принадлежат нашему разделу про стриминг; см. метрики QoE видео в разделе Video Streaming для определений на уровне событий плеера. Здесь фокус – на взгляде OTT-оператора: что каждая метрика значит для вашего бизнеса, какую цель держать и как каждая отображается на уходящих зрителях.

Video startup time: первые две секунды решают судьбу сессии

Video startup time – это первое, что испытывает зритель, и первое место, где вы его теряете. Это ожидание между нажатием play и появлением первого кадра – крутящийся лоадер, чёрный экран, миг сомнения, не сломалось ли приложение. Поскольку это происходит до того, как доставлена хоть какая-то ценность, терпение зрителя здесь самое тонкое.

Цена медленного старта – не догадка. Яснейшее свидетельство – знаковое академическое исследование Кришнана и Ситарамана, проведённое на сети доставки Akamai и опубликованное на Internet Measurement Conference 2012. Они проанализировали беспрецедентный набор данных: 6,7 миллиона уникальных зрителей по всему миру, посмотревших 23 миллиона видео в течение 216 миллионов минут за десять дней. Вывод, который должен знать каждый стриминг-оператор: зрители начинают уходить от видео, если оно не стартует примерно за две секунды, и за этим порогом каждая дополнительная секунда задержки старта повышает долю отказов примерно на 5,8%. Зритель, что ждёт десять секунд старта видео, в больших числах – это зритель, которого уже нет.

Именно поэтому «менее двух секунд» стало отраслевым ориентиром для startup time, а лучшие платформы уходят заметно ниже. Цель – не стандарт (никакая спецификация не предписывает две секунды), но кривая отказов за ней – одна из самых воспроизводимых находок в исследованиях стриминга.

Математика: во что обходится старт на две секунды медленнее за год

Проговорим арифметику вслух, ведь именно здесь QoE становится строкой бюджета. Пусть ваша платформа видит 1 000 000 попыток показа в день, а изменение конфигурации – медленнее origin, тяжелее плеер, лишний вызов рекламы до первого кадра – добавляет к startup time две секунды, толкая вас из быстрого старта в зону отказа.

Применим цифру исследования – 5,8% дополнительного отказа за каждую добавленную секунду:

доп. отказ = 2 секунды × 5,8% за секунду = 11,6%
потеряно показов в день = 1 000 000 × 11,6% = 116 000 показов
потеряно показов в год = 116 000 × 365 ≈ 42 340 000 показов

Теперь привяжем ценность. В рекламной модели пусть каждый показ стоит консервативные $0,02 рекламной выручки:

потеряно выручки в год = 42 340 000 показов × $0,02 ≈ $847 000

Примерно $847 000 в год – из-за двух секунд. И это до долгосрочного ущерба: тот же корпус исследований нашёл, что зритель, не дождавшийся старта видео, заметно реже возвращается на сайт вообще. Startup time – не инженерная сноска; это одно из самых рычажных чисел платформы.

Что делает старт медленным, простыми словами

Startup time – это сумма нескольких ожиданий, выстроенных встык: плеер должен найти и достичь сервер, скачать манифест (маленький текстовый файл, перечисляющий, где лежат сегменты видео), запросить лицензию на расшифровку, если контент защищён, скачать первый сегмент-другой, наполнить небольшой буфер, а затем начать декодировать и рисовать кадры. Всё, что удлиняет один из этих шагов, удлиняет старт. Частые виновники: далёкий origin-сервер без ближнего кэша, слишком большой первый сегмент, запрос лицензии, идущий последовательно вместо параллельного, или – частый и предотвратимый случай – client-side реклама, которая должна загрузиться и проиграться до того, как контент вообще начнётся.

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

Rebuffering: заморозка, теряющая больше всего времени просмотра

Если startup time решает, начнётся ли сессия, то rebuffering решает, выживет ли она. Rebuffering – это то, что происходит, когда видео останавливается посреди воспроизведения, потому что у плеера кончились скачанные данные и он вынужден встать на дозагрузку – замёрзший кадр, спиннер, «buffering…», что прерывает сцену. Conviva, один из крупных вендоров стриминг-аналитики, определяет это прямо: rebuffering – «это когда видео застревает во время воспроизведения и зритель должен ждать, пока видео возобновится», и отмечает, что «частый rebuffering – главный источник плохого quality of experience и часто ведёт к уходу аудитории от контента».

Метрика, которую вы отслеживаете, – это rebuffering ratio: общее время заморозки, делённое на общее время просмотра, в процентах. Если зритель смотрел 30 минут и 18 секунд из них провёл замёрзшим в дозагрузке, rebuffering ratio = 18 секунд ÷ 1800 секунд = 1%. Отраслевой ориентир – держать это ниже примерно 1%, а лучшие платформы – около или ниже 0,5%. Опять же, это операционные цели, не стандарты – но чем ниже, тем лучше, и связь с потерянным просмотром прямая.

Насколько прямая? То же исследование Akamai её измерило: зритель, чьё видео замёрзло всего на 1% своей длительности, посмотрел на 5% меньше минут, чем сопоставимый зритель, чьё видео играло плавно. Штраф рычажный – небольшая заморозка стоит кратного себе в потерянном просмотре, ведь заморозка не просто теряет замёрзшие секунды, она толкает зрителей бросить совсем. Именно поэтому rebuffering, а не чёткость картинки, – обычно QoE-метрика, теснее всего связанная с вовлечённостью: зрители куда легче терпят слегка мягкую картинку, чем картинку, которая останавливается.

Почему возникает rebuffering – и компромисс с чёткостью

Rebuffering – это в основе гонка двух скоростей: насколько быстро плеер может скачивать видео против того, насколько быстро он его проигрывает. Любой адаптивный плеер держит небольшой резервуар скачанного видео – буфер; пока в буфере есть данные, воспроизведение плавное. Когда сеть замедляется и буфер пустеет быстрее, чем наполняется, видео замирает. RFC 9317 описывает задачу плеера точно: слать «достаточно медиа, чтобы плеер не «застрял», но не столько, чтобы плеер не мог его принять».

Здесь rebuffering встречается с метрикой чёткости картинки, ведь плеер постоянно выбирает между ними. Механизм, что это делает, – adaptive bitrate (ABR) streaming, техника, которой плеер переключается между более качественными (большими, чёткими) и менее качественными (меньшими, мягкими) версиями одного видео в зависимости от скорости сети, которую он сейчас измеряет. Когда сеть сильна, плеер поднимается к более высокому битрейту и картинка резчает; когда сеть слабеет, плеер падает к более низкому битрейту, чтобы держать буфер полным и избежать заморозки. Вся цель ABR-алгоритма, в словах RFC 9317, – «наименьшие шансы события rebuffering (заморозки воспроизведения)» при доставке наивысшего качества, что позволяет соединение. Глубокая механика того, как ABR делает этот выбор, принадлежит слою стриминга – см. adaptive bitrate streaming – но вывод для оператора прост: rebuffering и битрейт – это два конца одного рычага, и платформа, которая никогда не делает rebuffering, но всегда выглядит мягко, просто выбрала один провал вместо другого.

Большая часть избегания обоих сразу – это задача кодирования и доставки, а не плеера. Хорошо построенная encoding ladder – набор уровней качества, из которых выбирает плеер – даёт ABR-алгоритму разумные ступени, на которые можно шагнуть вниз, чтобы плавно сбросить качество вместо заморозки. А content-delivery network, что кэширует ваше видео близко к зрителям, определяет, насколько быстро буфер вообще наполняется. QoE стоит ниже по течению от этих решений.

Отданный битрейт и доля сбоев: две другие метрики квартета

Третья метрика, отданный битрейт (или средний битрейт), – это средний поток данных видео, что зритель реально получил за сессию, в мегабитах в секунду (Mbps). Это лучший единичный прокси того, насколько чёткой выглядела картинка, ведь более высокий битрейт несёт больше визуальной детали. Универсальной цели нет – нужный битрейт зависит от разрешения, кодека и контента – но задача оператора: отдать наивысший битрейт, что выдерживает сеть зрителя без запуска rebuffering. Платформа, что отдаёт высокий средний битрейт при низком rebuffering ratio, настроила компромисс хорошо; та, что отдаёт высокий битрейт при высоком rebuffering ratio, слишком агрессивна; а та, что никогда не делает rebuffering, но отдаёт низкий средний битрейт, оставляет чёткость на столе.

Четвёртая метрика, доля сбоев воспроизведения, ловит худший опыт, что может быть у зрителя: попытку play, что завершается ошибкой и не отдаёт видео вовсе. Conviva делит это на два временных ведра, которые стоит различать. Video start failure (VSF) – попытка, что падает до появления первого кадра: зритель нажал play и получил ошибку вместо видео. Video playback failure (VPF) – поток, что завершился из-за ошибки после того, как уже начал играть: порча файла, внезапный обрыв, исчерпанный ресурс. Оба считаются против всех попыток. Как формулирует Conviva, сбой воспроизведения «представляет худший возможный опыт зрителя, ведь он полностью прерывает поток, так что смотреть нельзя». Цель для обоих – двигать к нулю; любая устойчивая доля сбоев выше доли процента – это пожар.

Цели – операционные конвенции индустрии 2026, не стандарты; они меняются по типу контента, устройству и региону. Датируйте и перепроверяйте любое публикуемое число. Терминология метрик – по CTA-2066.

Привести опыт к одному числу: QoE-скоры и MOS

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

Первый – стандартизированная перцептивная модель. Рекомендация International Telecommunication Union ITU-T P.1203 – первая международно стандартизированная модель QoE для HTTP-адаптивного стриминга. Она берёт технические параметры сессии – качество видео, качество звука, переключения качества, начальную задержку загрузки и заморозки (rebuffering) – и выдаёт Mean Opinion Score (MOS): единое число от 1 (плохо) до 5 (отлично), оценивающее, как опыт оценил бы типичный человек. P.1203 обучалась и валидировалась более чем на тысяче аудиовизуальных тест-последовательностей, содержащих ровно те искажения, на которые натыкаются OTT-зрители – заморозки, артефакты кодирования и переключения качества. Она ограничена (рассчитана на сессии примерно до пяти минут, разрешения до 1080p, частоту до 30 fps в начальном охвате), но важна тем, что это открытый, стандартизированный способ превратить сырые QoE-измерения в перцептивный скор, что значит одно и то же везде.

Второй – композитный индекс вендора. Streaming Performance Index (SPI) от Conviva, например, оценивает общее качество каждого потока, объединяя video start failure, выходы до старта видео, rebuffering ratio, video playback failures, video startup time и качество картинки в один скор с peer-бенчмарками, чтобы поставить ваше число в контекст. Ценность композита – операционная простота, один циферблат для дашборда руководителя. Риск в том, что веса проприетарны и непрозрачны, поэтому композит полезнее всего, когда вы всё ещё можете разложить его на лежащий ниже квартет, чтобы видеть, что его сдвинуло. Платформы, что выдают эти скоры – включая маршрут открытой телеметрии – мы сравниваем в стеке измерения QoE.

Как QoE измеряется: плеер говорит, CDN слушает

Число QoE честно ровно настолько, насколько честно место, где оно измерено, а честное место – плеер. Поскольку опыт зрителя происходит на его устройстве, метрики, что его описывают, должны собираться там и слаться обратно. Это задача бикенов на стороне плеера – небольших отчётов, что видеоплеер испускает по мере событий (запрошен play, показан первый кадр, началась заморозка, кончилась заморозка, переключён битрейт, выброшена ошибка) – которые сервис аналитики агрегирует в квартет. Инструментирование этих бикенов – отдельная дисциплина; см. инструментирование QoE плеера о том, как события захватываются на каждой платформе.

Есть и стандартизированный способ для плеера рассказать сети доставки, что он испытывает, что закрывает слепое пятно, описанное RFC 9317. Стандарт Consumer Technology Association CTA-5004, Common Media Client Data (CMCD) (сентябрь 2020), задаёт стандартный формат для плеера, чтобы прикреплять медиа-релевантную информацию – уровень его буфера, битрейт, что он запрашивает, грозит ли ему заморозка – к запросам, что он шлёт CDN. Без этого, как объясняет RFC 9317, CDN «производит миллионы строк лога в секунду», но «не имеет понятия сессии» и «не может сказать… застрял ли какой-либо из клиентов и не находится ли он в rebuffering или вот-вот застрянет». CMCD позволяет сети видеть то, что видит плеер, чтобы приоритизировать сегмент, что зрителю вот-вот понадобится, до того, как буфер опустеет. Для оператора урок в том, что измерение QoE и улучшение QoE всё больше – это одни и те же данные, текущие в два пункта назначения: ваш дашборд аналитики и ваш CDN.

Частые ошибки, что прячут проблему QoE

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

Самая частая – отчёт о QoE как об одном среднем по всему. Средний по платформе startup time в 1,8 секунды выглядит здоровым и может полностью скрыть, что зрители на smart TV в одном регионе ждут восемь секунд. QoE живёт в распределении и в сегментах – по устройству, региону, контенту, CDN. Среднее – это число, что даёт серьёзной проблеме спрятаться внутри здорового заголовка; всегда читайте 95-й перцентиль и разбивку по сегментам.

Вторая – путать quality of service с quality of experience – доверять дашборду доступности CDN 99,99% как доказательству, что зрители счастливы. Как установлено выше, сеть может быть здоровой, пока опыт проваливается на последнем хопе в дом. Измеряйте на плеере, или вы измеряете не то.

Третья – позволить вызову рекламы раздуть startup time. Когда client-side реклама должна загрузиться и отрендериться до первого кадра контента, воспринимаемый зрителем startup time включает всё ожидание загрузки рекламы – и если сервер рекламы медленный, вы изготовили проблему отказа из собственного монетизационного стека. RFC 9317 отмечает это прямо: вставка рекламы «не значит, что вставка рекламы не влияет на quality of experience пользователя», а плохая связь с рекламным сервисом «может вызвать rebuffering, даже если к базовым медиа-ассетам… можно обратиться быстро». Server-side вставка рекламы – один ответ; в любом случае меряйте startup с рекламой в пути, ведь именно это чувствует зритель.

Четвёртая – гнаться за битрейтом ценой rebuffering. Толкать наивысшее возможное качество картинки ощущается как победа качества, но если это опустошает буфер и замораживает видео, вы променяли чёткость, которую зрители терпят, на заморозку, из-за которой уходят. Квартет надо читать вместе: прирост битрейта, что поднимает rebuffering ratio, – обычно чистая потеря QoE.

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

Фора Софт строит ПО для видеостриминга и OTT/Internet TV с 2005 года: 250+ выпущенных проектов для 400+ клиентов, и QoE – там, где стриминговый масштаб становится продуктовым решением, а не слайдом. Когда платформе нужно держать старт ниже двух секунд и rebuffering ниже 1% на телефонах, smart TV и приставках – и в регионах с очень разными сетями – работа в том, чтобы инструментировать согласованные бикены плеера на каждом экране, настроить encoding ladder и стратегию CDN, от которых зависит квартет, и построить дашборды, что читают QoE по сегментам, а не по обманчивому среднему. Это тот же стриминговый, кодировочный и доставочный опыт, что мы применяем в видеоконференциях, e-learning, телемедицине и видеонаблюдении, где замёрзший кадр недопустим никогда. Мы нейтральны к слою аналитики: инструментируем по стандартам (CTA-2066, CMCD), чтобы ваши числа оставались переносимыми.

Ключевые выводы

• QoE измеряет то, что почувствовал зритель – быстрый старт, без заморозок, чёткая картинка, без сбоев – на плеере, не на сервере.
• Квартет QoE: video startup time, rebuffering ratio, отданный битрейт и доля сбоев воспроизведения.
• Зрители уходят после ~2 с задержки старта; каждая лишняя секунда добавляет ~5,8% отказа (исследование Akamai на 23 млн).
• Видео, замёрзшее на 1% длины, смотрят на ~5% меньше – штраф rebuffering рычажный.
• Читайте QoE по сегментам и перцентилям, никогда – одним средним по платформе, что прячет сбои.
• Стандартизируйте измерение (CTA-2066, CMCD), чтобы числа были сравнимы и CDN мог по ним действовать.

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

• Карта OTT-аналитики: аудитория, вовлечённость, качество – как QoE вписывается в три семьи метрик.
• Стек измерения QoE: Mux Data, Conviva и открытая телеметрия – как измерять квартет в масштабе.
• Аналитика удержания и вовлечённости – как QoE трассируется вперёд в отток и продление.