Доля ребуферинга: настоящая цена остановки

Кратко

Ребуферинг – это спиннер посреди воспроизведения: момент, когда у потока заканчивается буферизированное видео и он замирает, чтобы дозагрузиться. Доля ребуферинга (rebuffering ratio) измеряет это как часть сессии, проведённую в остановке, а не в просмотре. Это та метрика QoE стриминга, что сильнее всего связана с уходом зрителей: причинно-следственное исследование показало, что остановка длиной всего 1% видео стоит около 5% просмотра (Krishnan & Sitaraman, IMC 2012). Измеряйте её точно – суммарное время остановок, делённое на время остановок-плюс-игры, со стартом, вынесенным за скобки, – но никогда в одиночку, потому что доля скрывает, вызвана ли она одним долгим зависанием или множеством коротких.

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

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

Что такое остановка на самом деле

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

Событие ребуферинга – также называемое остановкой, зависанием или опустошением буфера (buffer underrun) – это то, что происходит, когда бак иссякает. Поток приходит медленнее, чем видео хочет играть, буфер опустошается до нуля, точке воспроизведения нечего показывать, и игра замирает, пока не придёт достаточно нового видео, чтобы продолжить (RFC 9317, IETF, 2022). Это и есть спиннер. Орган стандартизации, определяющий метрики опыта стриминга, называет этот момент «голоданием» буфера, а флаг уровня запроса, который плеер для него поднимает, так и зовётся buffer starvation (CTA-5004, CMCD, 2020).

Одно различие решает, значат ли что-нибудь ваши цифры: ребуферинг – это не старт. Ожидание перед самым первым кадром, пока плеер впервые заполняет буфер, – это время старта (video start time), отдельная метрика со своей статьёй о времени старта и первом кадре. Ребуферинг считает только те остановки, что случаются после начала игры. Если включить старт в долю ребуферинга, вы дважды учтёте начальное ожидание и раздуете число; эти две метрики измеряют и лечат раздельно. Перемотку по инициативе зрителя, вызвавшую краткую дозагрузку, тоже обычно исключают – по той же причине: это не сбой доставки, а прыжок зрителя.

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

Доля ребуферинга, вычисленная

Доля ребуферинга – это часть сессии просмотра, которую зритель провёл в остановке вместо просмотра. Запишем формулой, затем подставим числа.

доля ребуферинга = время остановок / (время остановок + время игры)

Знаменатель – это время остановок плюс время игры, то есть время, в которое сессия реально занималась видео, а не настенные часы, которые могли бы включать паузы или ожидание старта. Именно на этом определении сходится рекомендованная практика, чтобы два стека аналитики, сообщающие «долю ребуферинга», измеряли одно и то же (CTA-2066, CTA, 2020). Результат выражают в процентах.

Разберём конкретную сессию. Зритель смотрит 45-минутную серию – 2 700 секунд контента. Плееру нужно 3 секунды, чтобы показать первый кадр; это старт, и здесь он не считается. Во время игры поток останавливается трижды: один раз на 5 секунд, один на 7 и один на 15.

время остановок = 5 + 7 + 15 = 27 секунд
время игры      = 2 700 секунд
доля ребуферинга = 27 / (27 + 2 700)
                 = 27 / 2 727
                 = 0,0099  =  0,99%

Чуть меньше 1% сессии было спиннером. Звучит мало. Остальная часть статьи – о том, почему это не так.

Одного числа мало: частота и длительность

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

Возьмём наши 27 секунд остановок. Сессия A тратит их как одно зависание в 27 секунд. Сессия B тратит их как девять отдельных зависаний по 3 секунды, разбросанных по серии. Обе сообщают долю ребуферинга 0,99%. Но Сессия B прервала зрителя девять раз, а Сессия A – один. Исследования и практика согласны: множество прерываний хуже одного той же суммарной длины – заикание из частых коротких остановок может раздражать сильнее, чем одно более долгое ожидание (Mux, 2023). Доля сама по себе их не различает.

Поэтому измеряйте ребуферинг как три числа, а не одно:

• Доля ребуферинга – часть времени сессии в остановке (те 0,99% выше). Главное число.
• Частота ребуферинга – как часто случаются остановки, в событиях на час просмотра (Сессия A: ~1,3/час; Сессия B: ~12/час). Ловит заикание, которое доля скрывает.
• Длительность ребуферинга – как долго длится каждая остановка, обычно как медиана и 95-й процентиль, чтобы одно катастрофическое зависание не растворилось в среднем.

Четвёртое уточнение важно, когда вы хотите оценить собственную доставку, а не всю среду зрителя: доля ребуферинга, вызванная соединением (CIRR, connection-induced rebuffering ratio), считает только остановки из-за сети и доставки, исключая те, что зритель вызвал перемоткой (Conviva, 2026). CIRR – это число, за которым стоит следить, когда вопрос звучит «останавливается ли наш конвейер?», а не «видел ли этот зритель спиннер вообще?».

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

Таблица 1. Читайте долю ребуферинга вместе со спутниками. Ни одно число не равно опыту; каждое скрывает то, что раскрывают другие.

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

Как измеряют это число

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

Два стандарта держат цифры сопоставимыми. CTA-2066 определяет события и метрики QoE стриминга – включая долю ребуферинга и как её вычислять, – чтобы «доля ребуферинга» на одном дашборде совпадала с «долей ребуферинга» на другом (CTA-2066, 2020). CTA-5004 (Common Media Client Data, CMCD) стандартизирует поля, что плеер прикрепляет к каждому медиазапросу, – среди них длину буфера и флаг его опустошения, – чтобы данные, сигнализирующие о близкой или случившейся остановке, доходили до любого бэкенда в одном виде (CTA-5004, 2020; ревизия CMCDv2 CTA-5004-A вышла в 2026). Если взять из этого раздела одно правило, возьмите это: используйте стандартные определения, иначе две команды будут оптимизировать тихо разные числа.

Для оценки опыта на уровне сессии параметрическая модель ITU-T P.1203 сворачивает остановки – их число, длины и место на таймлайне – в единую оценку MOS от 1 до 5 для сессии адаптивного стриминга, рядом с картинкой и переключениями битрейта (ITU-T Rec. P.1203, 2017). Это мост от сырой доли ребуферинга к предсказанной оценке опыта, и одна из причин, почему остановки весят так много: их позиция и количество, а не только суммарная длина, двигают модель.

Почему остановка стоит вам зрителя

Причина, по которой ребуферинг занимает верхнюю строку любого дашборда QoE, – не интуиция. Это измерено, а в самом сильном исследовании – причинно.

Сначала пришёл широкий корреляционный вывод: на коротком VOD, длинном VOD и live доля буферизации оказывает наибольшее влияние на вовлечённость из всех метрик качества – больше, чем битрейт, больше, чем старт (Dobrian et al., SIGCOMM 2011). Эффект сильнее всего для live, где после остановки не догнать живой край: для 90-минутного live-события рост доли буферизации на 1% сокращал просмотр более чем на три минуты (Dobrian et al., 2011).

Затем пришли причинные данные – из квазиэкспериментального исследования большого набора Akamai (Krishnan & Sitaraman, IMC 2012). Его вывод о ребуферинге стоит запомнить: зритель, испытавший задержку из-за остановки, равную всего 1% длины видео, смотрел примерно на 5% меньше, чем сопоставимый зритель без остановок. Поскольку исследование отделило причину от простой корреляции, эти 5% – не «остановки и низкий просмотр идут вместе», а «остановка заставила зрителя уйти раньше».

Прогоним через нашу сессию. 45-минутная серия остановилась на 27 секунд – доля ребуферинга 0,99%, почти ровно тот 1%, что описывает исследование. Значит, модель предсказывает примерно на 5% меньше просмотра:

потеря просмотра ≈ 5% × 45 минут
                 ≈ 2,25 минуты на затронутого зрителя

Две с четвертью минуты, стёртые 27 секундами спиннера. Теперь масштаб. Допустим, 500 000 сессий в тот день получили ту же ~1% долю:

потерянный просмотр = 500 000 сессий × 2,25 минуты
                    = 1 125 000 зрительских минут
                    ≈ 18 750 часов просмотра потеряно за один день

Эти часы – рекламные показы, которые не отрисовались, live-аудитория, что разбрелась до финала, и подписчики на одну плохую ночь ближе к оттоку. Арифметика – это линейное прочтение наклона из исследования, а не закон природы: ваша аудитория, контент и каталог отличаются, – но важен порядок величины. Остановка меньше получаса, помноженная на аудиторию, измеряется десятками тысяч потерянных часов.

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

Компромисс, который адаптивный плеер делает каждую секунду

Если остановки так дороги, почему бы просто не держать огромный буфер и никогда не пересыхать? Потому что буфер заполняется на том битрейте, что выбирает плеер, а битрейт – это ровно то, что зритель тоже хочет повыше. В этом балансирование в сердце адаптивного стриминга по битрейту (ABR): плеер выбирает уровень качества для каждого сегмента в несколько секунд, и этот выбор – постоянная ставка между картинкой и плавностью.

Выберите битрейт выше, чем сеть может выдержать, и буфер сливается быстрее, чем наполняется, – в итоге до нуля, и поток останавливается. Выберите битрейт ниже, чем сеть могла бы нести, и воспроизведение незыблемо, но мягче нужного, тратя доступную полосу на худшую картинку. Плеер сегмент за сегментом выбирает между риском остановки и ценой мягкого изображения. Литература стандартов формулирует решение именно так: выбор битрейта оптимизирует под максимально достижимое качество или под минимальный шанс события ребуферинга (RFC 9317, 2022).

Буфер – это амортизатор, делающий ставку выживаемой. Более глубокий буфер терпит больше колебаний сети, прежде чем иссякнуть, поэтому плееры наполняют запас перед тем, как разрешить переход вверх. Поэтому же две главные семьи логики ABR расходятся в том, на что они смотрят: на основе пропускной способности алгоритмы оценивают скорость сети и берут качество, которое она унесёт, что хорошо на старте при пустом буфере; на основе буфера алгоритмы (подход, описанный Netflix в работе об адаптации по заполнению буфера) читают само заполнение буфера – повышают при глубоком запасе, понижают до того, как он иссякнет, – и сокращают остановки в установившемся режиме (Huang et al., SIGCOMM 2014). Многие плееры в продакшене работают на логике пропускной способности при старте и передают эстафету буферной логике, как только запас построен.

Вывод про измерение, который и относится к этому разделу: доля ребуферинга – не изолированное число, которое минимизируют в вакууме. Загоните её в ноль, прибив самый низкий битрейт, – и вы поменяли проблему остановок на проблему мягкой картинки; гонитесь за самым высоким битрейтом – и зовёте остановку обратно. Метрики картинки из статьи как выбрать правильную метрику и метрики доставки отсюда нужно читать вместе – это синтез в статье связь объективных метрик картинки с QoE, – потому что плеер торгует одно против другого в реальном времени. Как алгоритм принимает это решение – территория раздела «Видеостриминг»; этот раздел владеет тем, как вы измеряете результат.

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

Частые ошибки при измерении ребуферинга

Та же метрика, что так предсказательна, легко читается неверно. Повторяются пять ловушек.

Первая – сообщать только долю и упустить заикание. Спокойные 0,5% из дюжины крохотных зависаний – опыт хуже, чем подсказывает число; всегда смотрите долю вместе с частотой, как на Рисунке 2. Вторая – включать старт в долю: начальное заполнение буфера – своя метрика, и счёт его как ребуферинга раздувает число и смешивает две разные проблемы с двумя разными решениями. Третья – глобальное среднее, прячущее обрыв: здоровая доля по всему флоту может скрывать один CDN, устройство или регион, что останавливается всерьёз, – поэтому статья мониторинг качества в продакшене настаивает на сегментации перед доверием к агрегату.

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

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

Фора Софт строит продукты для видеостриминга, OTT, конференций, онлайн-обучения, телемедицины и видеонаблюдения с 2005 года, и в каждом live- или VOD-продукте доля ребуферинга – одно из первых чисел, что мы выносим на дашборд. Мы инструментируем остановки из событий плеера по стандартным определениям (CTA-2066) и клиентским данным (CMCD), чтобы доля, частота и длительность значили одно и то же на вебе, мобайле и ТВ – и чтобы регрессия проявлялась как сдвинувшееся число, а не как тикет в поддержку. Для live-продуктов вроде конференций и live-OTT, где нет эталонного оригинала для оценки и остановку не отыграть, догнав, эта телеметрия – главный сигнал качества. Задача не в более аккуратном графике, а в том, чтобы поймать CDN или устройство, чей буфер пересыхает, прежде чем аудитория разбредётся.

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

• Ребуферинг – это остановка посреди игры: буфер пересох, и поток замёрз.
• Доля ребуферинга = время остановок ÷ (остановки + игра); старт и перемотку исключают.
• Сообщайте долю вместе с частотой и длительностью – доля одна скрывает частые короткие остановки.
• Остановка в 1% длины видео сократила просмотр на ~5% (Krishnan & Sitaraman, 2012).
• Ребуферинг сильнее всех метрик QoE влияет на вовлечённость (Dobrian, 2011).
• ABR торгует битрейтом против риска остановки каждый сегмент; буфер – амортизатор.

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

• Метрики QoE стриминга: что предсказывает, останется ли зритель – рамка для всего Блока 6.
• Время старта и первый кадр – вторая половина первого впечатления.
• Связь объективных метрик картинки с QoE – чтение метрик картинки и доставки вместе.