QoE против QoS в видеостриминге – объяснение

Кратко

Quality of Service (QoS) – это то, что доставляет сеть и пайплайн: пропускная способность, задержка, потери пакетов, частота ошибок. Quality of Experience (QoE) – это единственное, что чувствует зритель: удовольствие или раздражение. Это не одно и то же измерение, и в зазоре между ними стриминговые команды теряют зрителей: сетевой дашборд может светиться зелёным, пока плеер встаёт колом в самый неподходящий момент. Хороший QoS необходим, но недостаточен для хорошего QoE – можно доставить каждый байт вовремя и всё равно отгрузить медленный старт, уродливое кодирование или паузу на кульминации. Эта статья определяет оба термина по их базовым стандартам (ITU-T E.800 для QoS, ITU-T P.10/G.100 для QoE), показывает, почему идеальный QoS всё ещё может давать плохой QoE, и объясняет, почему серьёзная команда меряет оба.

Почему это важно

Если вы ведёте стриминговый продукт, вы почти наверняка уже меряете QoS – ваши дашборды CDN и сети полны графиков пропускной способности и частоты ошибок, – и, возможно, читаете эти зелёные цифры как доказательство, что зрители довольны. Это не так. QoS меряет трубу; QoE меряет человека на её конце, а зритель уходит из-за того, чего сетевой график никогда не покажет: пятисекундного старта, единственного зависания во время гола, картинки, которая технически доставлена, но видимо «мыльная». Понимание разницы подсказывает, какой дашборд предсказывает отток, почему «с сетью всё в порядке» – не ответ на «почему ушли зрители» и куда потратить следующий инженерный час. Это мост из остального раздела «Качество и измерение видео» в блок про стриминговый QoE, где каждая метрика на стороне зрителя получает собственную статью.

Две буквы разницы, два разных вопроса

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

Quality of Service (QoS) – это системный вопрос: делает ли сеть и пайплайн доставки свою работу? Его меряют в единицах, которые инженеры и так отслеживают, – мегабиты в секунду пропускной способности, миллисекунды задержки, проценты потерянных пакетов. Quality of Experience (QoE) – это человеческий вопрос: доволен ли зритель? Его меряют тем, как быстро видео началось, было ли зависание, выдержала ли картинка – и, в итоге, остался ли человек. Одно – факт об инфраструктуре; другое – факт о человеке. Они скоррелированы, в чём и весь смысл измерять QoS, но это не одно и то же, и в пространстве между ними живут ошибки стриминга.

Ресторанная аналогия удерживает мысль на месте. QoS – это приборная панель кухни: температура духовки, лог холодовой цепи морозильника, GPS курьерской машины, показывающий, что она приехала вовремя. Каждый показатель может быть идеальным. QoE – единственное, что на самом деле оплачивает счёт: понравилась ли гостю еда. Машина, приехавшая точно по графику с холодным, плохо приготовленным блюдом, имеет безупречную логистику и взбешённого клиента. Приборная панель необходима, полезна и совершенно недостаточна сама по себе. Гостя всё равно придётся спросить.

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

Quality of Service: что доставляет труба

Quality of Service – более старая, сетевая дисциплина, и у неё есть формальное определение. Рекомендация ITU-T E.800 (09/2008) определяет QoS как «совокупность характеристик телекоммуникационной услуги, влияющих на её способность удовлетворять заявленные и подразумеваемые потребности пользователя услуги». На практике для стримингового видео эта совокупность сводится к горстке измеримых сетевых и доставочных свойств.

Первое – пропускная способность (throughput): сколько бит в секунду реально проходит через соединение, в килобитах или мегабитах в секунду (kbps / Mbps). Она задаёт жёсткий потолок битрейта, а значит и качества картинки, которое можно доставить без зависаний. Второе – задержка (latency): время в миллисекундах между запросом и первым байтом ответа. Третье – джиттер (jitter): разброс этой задержки, тоже в миллисекундах, который огромно важен для live и реального времени. Четвёртое – потери пакетов (packet loss): процент пакетов данных, которые так и не дошли, вынуждая переотправку или оставляя дыры. Пятое – доступность (availability): процент времени, когда услуга вообще достижима.

К этим сетевым числам стриминговый пайплайн добавляет свой QoS на стороне доставки: cache-hit ratio на CDN, частоту ошибок источника (доля ответов HTTP 4xx/5xx), время скачивания сегментов. Это по-прежнему системные измерения – они описывают, насколько хорошо отработала машинерия, а не как ощущалось видео. Команда может смотреть, как все они остаются зелёными.

Сила QoS в том, что он объективен, непрерывен и диагностичен. Когда что-то ломается, метрики QoS говорят, где в системе сломалось, – насыщенный канал, отказавший источник, теряющая «последняя миля». Его предел не менее важен: QoS никогда не говорит, был ли зритель доволен. Не может, потому что он никогда не меряет зрителя. Идеально здоровая сеть – это предпосылка хорошего опыта, а не его измерение. За механику доставки этих чисел – adaptive bitrate, плееры, CDN – этот раздел отсылает к разделу «Видеостриминг»; здесь нас занимает, что мерить, а не как устроена доставка.

Quality of Experience: что воспринимает зритель

Quality of Experience переворачивает точку зрения с системы на человека. Рекомендация ITU-T P.10/G.100 – официальный словарь этих терминов у органа стандартизации – со своей редакции 2017 года определяет QoE как «степень восторга или раздражения пользователя приложения или услуги». И добавляет, что этот восторг или раздражение «вытекает из выполнения его ожиданий» относительно услуги «в свете личности пользователя и его текущего состояния». QoE по определению субъективен: он живёт в зрителе, а не в проводе.

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

Для стриминга QoE делают измеримым через набор индикаторов на стороне зрителя, которые служат суррогатом того самого восторга или раздражения. Время старта (startup time, или time-to-first-frame) – сколько миллисекунд или секунд проходит между нажатием play и появлением видео. Ребуферинг (rebuffering) – зависания, прерывающие воспроизведение после старта; их считают и как число пауз, и – важнее – как долю ребуферинга (rebuffering ratio), процент общего времени просмотра, который зритель провёл, глядя на спиннер. Средний битрейт и частота переключений битрейта описывают, насколько хороша и стабильна была картинка. Сбои старта видео и уходы до старта видео ловят зрителей, не увидевших ни кадра. А рядом со всем этим – воспринимаемое качество картинки тех кадров, что всё же показались: территория объективных метрик вроде VMAF и субъективного Mean Opinion Score (MOS), разобранных в другом месте этого раздела.

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

Почему идеальный QoS всё ещё может давать плохой QoE

Вот самая важная мысль статьи. Хороший QoS необходим, но недостаточен для хорошего QoE. Нельзя доставить хороший опыт по сломанной сети – но можно совершенно точно доставить плохой опыт по идеальной. Здоровье сети не означает, что зритель доволен, и считать зелёный дашборд QoS доказательством хорошего опыта – самая частая и самая дорогая ошибка в стриминге.

Пройдём по способам, которыми безупречная труба всё же разочаровывает зрителя. Само кодирование может быть плохим – поток без зависаний и ошибок, но плохо сжатой картинки доставлен идеально и всё равно выглядит плохо; сеть сделала работу, а зритель всё равно видит мыло. Старт может быть медленным – если логика буферизации плеера ждёт пять секунд до первого кадра, сеть перенесла каждый байт вовремя, а зритель всё равно ушёл до начала показа. Лестница adaptive bitrate может быть настроена криво – плеер, перещёлкивающий разрешения каждые пару секунд, выдаёт технически высокий средний битрейт и видимо нестабильную, отвлекающую картинку. И тайминг решает всё – единственная двухсекундная пауза это мелкая помеха на титрах и катастрофа во время пенальти. QoS считает паузу; только QoE знает, что она случилась в худший возможный момент.

Обратная асимметрия так же реальна и так же поучительна. Хороший опыт может пережить несовершенную сеть, потому что плеер спроектирован прятать проблемы QoS от зрителя. Буфер поглощает джиттер; adaptive bitrate меняет немного резкости на непрерывный поток, когда пропускная способность проседает. В этом и вся работа современного видеоплеера: превращать переменный QoS в стабильный QoE. Именно поэтому QoE нужно мерить напрямую – плеер занят тем, что ломает простую связь между здоровьем сети и счастьем зрителя в обе стороны.

Сколько на самом деле стоит пауза – арифметика

Яснее всего, что QoE нужно мерить отдельно, показывает связь между ребуферингом и вовлечённостью. Основополагающее исследование – Dobrian et al., представленное на ACM SIGCOMM в 2011 году на большом клиентском датасете аналитической компании Conviva. Его центральный вывод: из всех метрик качества, что они мерили, доля ребуферинга – доля времени в буферизации – сильнее всего влияла на то, как долго люди смотрели, для любого типа контента.

Дадим этому число. Исследование сообщило, что для live-контента рост доли ребуферинга на 1% снижал вовлечённость более чем на три минуты на 90-минутном live-событии. Пройдём арифметику вслух:

Доля ребуферинга = время в буферизации ÷ общее время сессии
1% от 90-минутного события = 0.01 × 90 мин = 0.9 мин ≈ 54 секунды зависаний
Итог: > 3 минут потерянного времени просмотра на затронутого зрителя

То есть примерно 54 секунды спиннера стоили не 54 секунды вовлечённости – они стоили больше трёх минут, потеря в несколько раз больше самой паузы, потому что раздражённый зритель не просто пережидает паузу, он уходит. А теперь заметьте, что показал бы QoS-взгляд на то же событие: краткий провал пропускной способности, быстро восстановленный, вполне в пределах нормы. Сеть рассказала историю о мелкой, решённой заминке. Зритель рассказал историю о трёх потерянных минутах. Только один из этих дашбордов предсказал отток, и это была не сеть.

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

Мерить оба: карта метрик

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

Табл. 1. QoS и QoE как два инструмента. QoS говорит, отработала ли машинерия; QoE – было ли это важно зрителю. Зрелая программа смотрит оба и никогда не читает один вместо другого.

Связь между двумя колонками причинная, но нежёсткая: QoS – это вход в QoE, опосредованный плеером. Низкие потери и достаточная полоса делают хороший опыт возможным; качество кодирования, логика ABR, поведение старта и сам контент решают, реализуется ли эта возможность. Поэтому связать метрики качества картинки с метриками доставки – тема статьи «Связь объективных метрик и QoE» – это и есть синтез, к которому движется вся область.

Стандарты, которые это фиксируют

Это не вольная терминология; различие закреплено в именованных рекомендациях, и ссылка на них держит разговор о качестве точным. QoS определён в ITU-T E.800 (09/2008). QoE определён в ITU-T P.10/G.100, официальном словаре, с формулировкой про «восторг или раздражение» из редакции 2017 года. Конкретно для стриминга ITU-T P.1203 – первая стандартизованная модель, предсказывающая оценку QoE (MOS по шкале 1–5) для HTTP adaptive streaming из битрейта, разрешения и событий зависаний; это параметрическая, основанная на битстриме модель, а не full-reference, и её можно комбинировать с моделями качества картинки семейства P.1204. На стороне инструментирования плеера CTA-2066 из проекта WAVE Ассоциации потребительских технологий стандартизует события, свойства и определения метрик стримингового QoE, чтобы время старта и ребуферинг значили одно и то же в разных плеерах и у разных аналитических вендоров. Сообщая число QoE, называйте стандарт за ним; «QoE хороший» без модели и определения метрики так же пусто, как «VMAF высокий» без модели.

«Частая ошибка: читать зелёный дашборд QoS как довольного зрителя. Классический провал – смотреть на пропускную способность, частоту ошибок и потери, видеть, что всё здорово, и заключать, что опыт хорош. Это стриминговая версия закона Гудхарта: сетевая команда оптимизирует метрику, которой владеет, метрика остаётся зелёной, а зрители всё равно уходят – потому что никто не померил время старта, паузу во время гола или кодирование, доставленное безупречно и всё равно выглядящее плохо. Вторая, противоположная ошибка – переоптимизировать одну ручку QoS в ущерб опыту: выжимать самый высокий битрейт, что тянет канал, максимизирует число QoS и вызывает ребуферинг в момент, когда полоса проседает, меняя метрику, которую зритель не видит, на паузу, которую он точно заметит. Лечится одинаково в обоих случаях – инструментируйте плеер, мерьте QoE напрямую и относитесь к QoS как к диагностическому входу в него, а не как к его заместителю.»

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

Фора Софт делает видеопродукты с 2005 года – live-стриминг, OTT, WebRTC-конференции, e-learning, телемедицину и видеонаблюдение – и во всех них мы относимся к QoS и QoE как к двум инструментам, а не одному. Мы инструментируем сеть и пайплайн, потому что там диагностируют проблемы, но судим релиз по тому, что плеер сообщает со стороны зрителя: как быстро стартовал, было ли зависание, насколько стабильно держалась картинка. Когда сетевой дашборд клиента зелёный, а зрители всё равно отваливаются, мы идём искать на стороне опыта – старт, ребуферинг, кодирование, логика ABR, – потому что почти всегда ответ там. Назвать вопрос о качестве прежде, чем тянуться за числом, – честный способ мерить доставленный опыт, и это основа измерений на стороне доставки в нашей методологии бенчмарков.

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

• QoS меряет сеть и пайплайн; QoE меряет восторг или раздражение зрителя.
• Хороший QoS необходим, но недостаточен – идеальная сеть всё ещё может отгрузить плохой опыт.
• QoS определён в ITU-T E.800; QoE – в ITU-T P.10/G.100; стриминговый QoE – в ITU-T P.1203.
• Доля ребуферинга – сильнейшая связь QoE с вовлечённостью: 1% стоит 3+ минут на 90-мин live.
• Зелёный дашборд QoS не значит довольного зрителя; мерьте QoE в плеере.
• Выжимать максимум битрейта (победа QoS) может вызвать ребуферинг (потеря QoE) – мерьте оба.

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

• Стриминговый QoE: метрики, предсказывающие, останется ли зритель
• Доля ребуферинга и цена зависания
• Субъективное и объективное качество – два разных вопроса