Артефакты стриминга: переключения, фризы, тайлинг

Коротко

Артефакты этой статьи создаёт не кодировщик, а сеть и плеер – поэтому метрики качества картинки, которым вы доверяете оценку кодирования, по своей природе их не видят. На надёжном транспорте (TCP или QUIC под HLS и DASH) проблема сети не портит пиксели – она опустошает буфер, и вы получаете фриз (ребуферинг) или падение на версию похуже (переключение ABR). На ненадёжном транспорте (UDP/RTP под WebRTC, контрибуцией и вещанием) потерянный пакет, который не удалось скрыть, становится видимым разрушением – блочным тайлингом и смазанными областями, что распространяются по группе кадров до следующего ключевого кадра. Ничего из этого не появляется в полноэталонной оценке, посчитанной по файлу, поэтому их измеряют сессионными моделями (ITU-T P.1203 и P.1204) и плеерными QoE-метриками (CTA-2066), подкреплёнными данными о вовлечённости, которые доказывают: однопроцентный стойл стоит реального времени просмотра.

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

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

Артефакты другого класса

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

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

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

Два режима доставки решают, какой артефакт вы получите

Чтобы понять эти артефакты, нужно понять одну развилку: едут ли биты по надёжному транспорту, который пересылает потерянное, или по ненадёжному, который не пересылает. Выбор решает, станет ли сбой сети стойлом или смазом.

Надёжный транспорт – Transmission Control Protocol (TCP) или более новый QUIC – гарантирует доставку. Каждый пакет подтверждается; потерянное пересылается, прежде чем данные попадут в декодер (литература по протоколам стриминга, например Ant Media, 2026). HTTP Adaptive Streaming – HLS и MPEG-DASH, технология почти всего видео-по-запросу и большей части живого OTT, – работает именно поверх этого. Поэтому потерянный пакет в потоке HLS никогда не станет видимым разрушением: декодер всегда получает полный, корректный битстрим. Повреждение проявляется иначе. Пересылка занимает время, а управление перегрузкой TCP снижает темп отправки при потере, так что байты приходят с опозданием. Если они приходят позже, чем может прикрыть буфер плеера, происходит одно из двух: плеер падает на версию с меньшим битрейтом, чтобы успевать (переключение), либо буфер пустеет и воспроизведение встаёт (фриз). Надёжный транспорт превращает потерю пакетов в проблему времени, а не пикселей.

Ненадёжный транспорт – User Datagram Protocol (UDP), обычно несущий Real-time Transport Protocol (RTP), – не пересылает, потому что ожидание повтора сорвёт бюджет задержки. WebRTC-конференции, контрибуционные фиды с малой задержкой и классическое вещание/IPTV используют именно его. Здесь потерянный пакет потерян, и если декодер не сумеет его скрыть, вы видите потерю напрямую как тайлинг и разрушение. Размен намеренный: реалтайм принимает редкий видимый сбой в обмен на субсекундную задержку, благодаря которой разговор ощущается естественным.

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

Этот раздел – самое полезное, что стоит держать в голове, потому что он подсказывает, какой артефакт ждать от какого продукта. VOD-приложение встаёт и переключается; оно не тайлит. Видеозвонок тайлит и замерзает; он редко «ребуферит» в смысле VOD. Измеряйте соответственно.

Фриз: артефакт без неверных пикселей

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

Вот почему это побеждает метрику картинки. Во время фриза каждый кадр на экране – корректный, полностью декодированный кадр; просто это один и тот же корректный кадр, удержанный слишком долго. Полноэталонная метрика – PSNR, SSIM или VMAF – сравнивает декодированные кадры с эталоном и не находит ничего плохого, потому что с пикселями всё в порядке. Ошибка во времени, а не в изображении, а у покадровой оценки картинки нет оси времени. Как сказано в документации стандартизированной стриминговой модели, её сессионная интеграция моделирует стойлы и колебания качества «особенно в сравнении с моделями только качества видео (например, VMAF)» (AVEQ, обзор ITU-T P.1203, 2025). Метрика не ошибается – она отвечает на другой вопрос.

У фриза также самые жёсткие бизнес-цифры, и поэтому его измеряют даже там, где не измеряют ничего другого. Канонический источник – анализ Krishnan и Sitaraman 23 миллионов просмотров от 6,7 миллиона зрителей в сети Akamai (Internet Measurement Conference, 2012). Два вывода держат каждый бюджет ребуферинга с тех пор:

• Зритель, у которого ребуферинг равен 1% длительности видео, смотрит примерно на 5% меньше видео, чем сопоставимый зритель без ребуферинга.
• Зрители начинают уходить, как только старт превышает примерно 2 секунды, и каждая дополнительная секунда старта поднимает уровень отказов примерно на 5,8%.

Это не цифры качества картинки. Это цифры доставки, и именно поэтому стриминг-команда, игнорирующая стойлы, оптимизирует не то.

Переключение: картинка хороша, но всё время меняется

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

Две разновидности переключения раздражают зрителя. Понижение – очевидное: картинка внезапно мягчает, когда плеер падает на меньшее разрешение или битрейт, заметнее всего на детальном или динамичном контенте. Осцилляция – тоньше: плеер прыгает вверх-вниз между уровнями, так что картинка не успокаивается, и постоянная смена отвлекает сильнее, чем стабильное низкое качество. Консенсус исследований по адаптивному стримингу называет четыре фактора QoE, и переключение качества стоит рядом с остальными как полноправное искажение: начальная задержка, стойлы, среднее качество и само переключение (Barman и Martini, обзор QoE ABR, 2019).

Вот ещё причина, по которой одна оценка картинки вводит в заблуждение. Прогоните VMAF по каждой версии лестницы – и каждая ступень наберёт прекрасно, ведь каждая ступень и есть чистое кодирование. Артефакт не в какой-то версии; он в последовательности версий, которую сшил плеер, и в том, как часто и как далеко он прыгал. У оценки по версии нет способа это представить. Стандартизированная модель решает это, интегрируя качество посекундно по всей сессии, так что поток «в среднем хороший», но мечущийся между уровнями, получает оценку ниже стабильного – ровно так, как его оценивает человек.

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

Тайлинг: как выглядит нескрытая потеря пакета

Теперь артефакт со стороны пикселей. На ненадёжном транспорте потерянный пакет означает, что кусок кодированной картинки так и не пришёл, – а поскольку видеокодеки пакуют кадр в блоки (макроблоки в H.264, единицы дерева кодирования в HEVC и AV1), пропавшие данные проявляются как тайлинг: прямоугольные области кадра, заполненные мусором, замёрзшим устаревшим содержимым или плоским смазом там, где должна быть реальная картинка. Это похоже на рваную мозаику и есть безошибочная сигнатура потери при доставке, а не сжатия.

Две вещи делают тайлинг хуже одного повреждённого блока, и обе – из того, как кодеки сжимают по времени. Во-первых, большинство кадров хранятся не целиком; они хранятся как разности от других кадров. Группа кадров (GOP) начинается с самодостаточного ключевого кадра – I-кадра, точнее IDR-кадра, – за которым идут предсказанные кадры (P- и B-кадры), кодирующие лишь то, что изменилось. Потеряйте часть опорного кадра – и ошибка не останется на месте: она распространяется на каждый последующий кадр, что предсказан от него, смазываясь и тянучась вперёд, пока не придёт следующий ключевой кадр и не сбросит картинку (Huszák и Imre, анализ структуры GOP и распространения потерь, 2010). Потеряйте часть самого ключевого кадра – и повреждён весь GOP.

Арифметику стоит увидеть один раз. При обычном интервале ключевых кадров в 2 секунды при 30 кадрах в секунду один испорченный опорный кадр может видимо повредить до 2 × 30 = 60 кадров – две полные секунды воспроизведения – прежде чем следующий ключевой кадр всё вычистит. Вот почему одна потеря пакета может дать смаз, длящийся куда дольше одного кадра, и почему частота ключевых кадров – один из рычагов ограничения ущерба от потерь.

Во-вторых, декодеры пытаются скрыть потерю, и у сокрытия свой вид. Сокрытие ошибок заменяет пропавший блок либо копией соответствующей области из предыдущего кадра (временное сокрытие), либо интерполяцией от соседних блоков (пространственное сокрытие). Когда временная догадка неверна – содержимое сдвинулось – вы получаете характерное смазывание или тянучку, где кусок предыдущего кадра впечатан не туда. Современные реалтайм-стеки часто берут самое безопасное сокрытие: браузерные реализации WebRTC замораживают последний хороший кадр, пока не придёт ключевой кадр, вместо показа рваной картинки (getstream.io и bloggeek.me, отказоустойчивость медиа в WebRTC, 2025). Так что даже на ненадёжном транспорте современная умолчательная стратегия часто превращает потенциальный тайл в короткий фриз – два артефакта ближе друг к другу, чем кажется.

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

Почему ваша метрика картинки слепа ко всем трём

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

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

«Частая ошибка: сертифицировать опыт файловой оценкой картинки. Дорогая ошибка – прогнать VMAF по лестнице кодирования, увидеть на каждой ступени 95+, и подписать «качество». Эта оценка валидировала кодирование. Она ничего не говорит о том, получили ли зрители стойлы, смотрели ли, как картинка осциллирует, видели ли разрыв от потери пакета, – потому что ничего этого нет в файлах, которые вы измерили. Поток может быть 96 VMAF на каждой версии и всё равно терять время просмотра при доле ребуферинга 1%. Если доставленный опыт в области интереса, метрика картинки необходима, но недостаточна: дополните её сессионным измерением QoE и плеерными метриками доставки – иначе вы оцениваете ту половину тракта, что и так, скорее всего, была в порядке.»

Как реально измерить переключения, фризы и тайлинг

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

Плеерные метрики доставки – первый этаж. Самое дешёвое и прямое измерение – инструментировать плеер и считать события: время старта, число и длительность стойлов, долю ребуферинга, число и величину переключений ABR. У индустрии есть для этого стандартный словарь. CTA-2066, спецификация Consumer Technology Association Streaming Quality of Experience Events, Properties and Metrics, определяет общий набор плеерных событий и QoE-метрик – доступность, время старта, непрерывность (семейство стойлов) и качество, – чтобы разные плееры и аналитические вендоры сообщали одно и то же одинаково (CTA WAVE R4 WG20, публичная версия). Это числа, которые ваш дашборд должен нести рядом с VMAF, а не вместо него.

Сессионные модели QoE – синтез. Чтобы превратить эти события в единую оценку опыта, контролирующий стандарт – ITU-T P.1203, первая стандартизированная модель QoE для HTTP adaptive streaming. Она предсказывает Mean Opinion Score (MOS, шкала человеческой оценки 1–5) для целой сессии до пяти минут и – вот в чём суть – явно сворачивает качество сжатия, пространственные и временные переключения, начальную задержку загрузки и стойлы, интегрируя их посекундно через модуль Pq (ITU-T P.1203, 2017; валидирована на 1000+ последовательностях и более чем 25 000 человеческих оценок, Robitza и др., 2018). Важно: P.1203 – не полноэталонная метрика: она работает с метаданными потока и битстримом – кодек, битрейт, разрешение, типы и размеры кадров плюс события стойлов у клиента, – так что ей не нужен нетронутый эталон и она работает без декодирования пикселей. Её преемница, видеомодель ITU-T P.1204.3 (2020), – битстрим-модель, валидированная до 4K для H.264, HEVC и VP9, и её посекундные выходы могут питать ту же сессионную интеграцию. Это семейство – то, как ставят защищаемое число на стриминговую сессию, со стойлами и переключениями включительно.

Безэталонные метрики картинки – для случая тайлинга. Когда артефакт – это разрушение со стороны декода без чистого эталона (live, UGC, захваченный плейаут), нужна слепая метрика, что оценивает повреждённую картинку напрямую, ища блочные разрывы краёв и прогоны замёрзших кадров – сигнатуры потери. Это безэталонный инструментарий (раскрыт в безэталонном качестве для live и UGC); скрипт-компаньон ниже – намеренно простая версия этой идеи.

Таблица 1. Три артефакта стриминга, которые не создаёт кодировщик, и почему файловая метрика картинки пропускает каждый. Переключение прячется в последовательности, фриз – во времени, тайлинг – в декодированном выводе, который метрика не видит. Измеряйте их сессионными моделями (P.1203/P.1204), плеерными метриками (CTA-2066) и безэталонными проверками реального декода.

Разобранный пример: дашборд, который говорит «отлично»

Сделаем слепое пятно конкретным на одной сессии. Зритель смотрит 10-минутный (600-секундный) VOD-тайтл. Кодирование – ваша лучшая лестница: каждая версия набирает VMAF 96. Сама сессия идёт так: задержка старта 3 секунды до первого кадра, затем два стойла-ребуферинга по 4 и 2 секунды и пять понижений ABR, пока поезд зрителя проходит сквозь тоннели.

Посчитаем числа доставки, которых оценка картинки не коснулась. Суммарное время стойлов – 4 + 2 = 6 секунд. Доля ребуферинга – время стойлов, делённое на время стойлов-плюс-игры, – это 6 ÷ (6 + 600) = 6 ÷ 606 ≈ 0,99%, по сути порог в 1% из исследования вовлечённости. Применив вывод того исследования, этот зритель на пути к тому, чтобы посмотреть примерно на 5% меньше тайтла, чем зритель без стойлов, – скажем, на 30 секунд меньше из 10-минутного видео, ушедших в спиннер. Отдельно: старт в 3 секунды на секунду превышает порог отказов в 2 секунды, так что по тому же исследованию примерно на 5,8% больше таких зрителей уйдут ещё до начала тайтла. Пять переключений тем временем означают, что картинка видимо смягчилась и снова обострилась пять раз, и каждое – маленькое раздражение, которое VMAF 96 по версии представить не может.

Одна сессия – два вердикта. «Отлично», если читать лестницу кодирования; «теряем время просмотра и терпение», как только измерите сессию. Метрика картинки не солгала о кодировании – её просто не спросили о доставке. (Цифры 5% и 5,8% – это опубликованные эластичности Krishnan-Sitaraman, применённые иллюстративно; ваш контент и аудитория будут другими – измеряйте своё.)

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

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

Фора Софт строит видеософт с 2005 года – стриминг и OTT, WebRTC-конференции, e-learning, телемедицину и видеонаблюдение – и два режима доставки из этой статьи прямо ложатся на эти продукты. WebRTC-конференция или телемедицинский звонок живут на UDP/RTP, поэтому их режим отказа – тайлинг от потери пакетов и фризы-сокрытия, а правильная инструментовка – потери, джиттер и события заморозки у клиента плюс безэталонная проверка декодированной картинки. OTT- или e-learning-приложение VOD живёт на HLS/DASH поверх TCP, поэтому его режим отказа – задержка старта, ребуферинг и переключения ABR, а правильная инструментовка – набор событий CTA-2066, поданный в сессионную оценку в духе P.1203. Мы относимся к доставленному опыту как к отдельной измерительной задаче, отдельной от качества кодирования: метрика картинки по лестнице доказывает, что файл хорош, а сессионно-плеерное QoE доказывает, что зритель получил его хорошо, – и только пара говорит правду. Где артефакт уходит корнями в выбор тракта, лечение со стороны причины живёт на шаг выше – в проектировании доставки и ABR, которым занимается наша стриминг-практика.

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

• Эти артефакты создаёт сеть и плеер, а не кодировщик – поэтому файловая метрика картинки к ним слепа.
• Надёжный транспорт (TCP/QUIC, HLS/DASH) превращает потерю пакетов в стойлы и переключения ABR, не в видимое разрушение.
• Ненадёжный транспорт (UDP/RTP, WebRTC, вещание) превращает нескрытую потерю в тайлинг, что распространяется по GOP.
• У фриза нет неверных пикселей; переключение по версии оценивается хорошо; тайлинга нет в файле – каждый бьёт PSNR/SSIM/VMAF по-своему.
• Измеряйте их сессионными моделями ITU-T P.1203/P.1204, плеерными метриками CTA-2066 и безэталонными проверками декода.
• Доля ребуферинга 1% стоит ~5% времени просмотра; старт сверх 2 с поднимает отказы на ~5,8% за секунду.

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

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