Видео тормозит даже с CDN: где искать проблему от первого запроса до плеера

CDN подключен, видео раздается через распределенную сеть, нагрузка на основной сервер снизилась, но часть пользователей все равно жалуется: ролик долго запускается, посреди просмотра появляется индикатор загрузки, качество внезапно падает до 480p или проблема возникает только у определенного оператора связи. В такой ситуации легко сделать вывод, что CDN «не справляется», хотя между нажатием Play и появлением кадра на экране участвует несколько независимых компонентов, и каждый из них способен добавить свою задержку.

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

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

После команды на воспроизведение плееру обычно нужно получить или проверить доступ к контенту, загрузить манифест потока, выбрать начальный вариант качества, запросить первые медиасегменты, накопить достаточный объем данных в буфере и только затем декодировать первый кадр.

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

Системы видеоаналитики именно поэтому разделяют разные этапы запуска. Например, один сервис может определять время запуска видео как промежуток от команды на воспроизведение до появления первого движущегося кадра, а другой дополнительно учитывать загрузку страницы и инициализацию самого плеера. Если страница перегружена JavaScript, рекламными модулями или сторонними сервисами, пользователь может ждать видео еще до того, как CDN вообще получит первый медиазапрос.

Если после запуска видео проходит несколько секунд, но затем ролик воспроизводится стабильно и без остановок, начинать диагностику со средней скорости CDN обычно рано.

Здесь полезнее разложить время старта на этапы.

Сначала стоит определить, насколько быстро плеер вообще готов к работе. На тяжелой веб-странице инициализацию могут задерживать скрипты, реклама, система управления согласием на cookies или другие компоненты интерфейса. Затем нужно посмотреть время получения манифеста HLS или MPEG-DASH – небольшого файла, который описывает доступные варианты потока и расположение сегментов. После этого можно измерить запрос первого медиасегмента и момент появления изображения.

Для HTTP-запросов полезен TTFB (Time to First Byte, время до получения первого байта ответа). Если манифест или первый сегмент долго не начинают приходить, проблема может находиться в серверной обработке запроса, авторизации, сетевом пути или источнике данных. Если ответ начинается быстро, но сам сегмент загружается долго, уже стоит смотреть фактическую пропускную способность соединения и размер выбранного варианта видео.

Отдельный случай – это защищенный контент. Когда перед воспроизведением необходимо запросить DRM-лицензию, проверить токен или получить рекламный ролик, каждый дополнительный внешний запрос может участвовать в общей задержке. CDN в этот момент способен исправно отдавать медиаданные, но зритель еще не имеет возможности начать воспроизведение.

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

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

Такое поведение связано уже с другой частью процесса.

Плеер загружает медиаданные немного вперед и хранит их в буфере. Пока новые данные поступают достаточно быстро относительно скорости их воспроизведения, зритель ничего не замечает. Когда запас заканчивается, начинается повторная буферизация или «rebuffering».

Поэтому здесь важно сравнивать не абстрактную «скорость Интернета», а скорость получения медиаданных с битрейтом конкретного варианта видео.

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

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

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

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

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

Адаптивное потоковое видео обычно содержит несколько вариантов одного ролика, например, 360p, 480p, 720p и 1080p с разными битрейтами. ABR (Adaptive Bitrate, адаптивное изменение битрейта) позволяет плееру выбирать между ними в зависимости от доступной пропускной способности и состояния буфера.

Подробнее вы можете узнать из статьи: HTML5-плеер для сайта

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

Одна из причин – это неудачно построенная лестница битрейтов. Представим, что сервис предлагает 720p на 2 Мбит/с, а следующий вариант 1080p сразу требует 7 Мбит/с. Для пользователя с устойчивыми 5 Мбит/с хорошего промежуточного варианта просто нет: 720p работает с большим запасом, а 1080p оказывается слишком тяжелым. Плеер может пробовать перейти наверх, быстро терять буфер и возвращаться обратно.

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

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

Вот здесь уже стоит проверить кэш CDN и исходный узел.

Если популярные медиасегменты постоянно запрашиваются пользователями, они точно должны появиться на узлах CDN высока. Редкий контент может отсутствовать в кэше, и первому запросу придется пройти до источника.

Механику cache hit и cache miss мы подробно разбирали в отдельном материале PlatformCraft об устройстве видеоплатформы и CDN, поэтому только скажем, что если задержка систематически коррелирует с «холодным» контентом, то нужно сравнить время ответа при попадании в кэш и при обращении к источнику.

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

Один miss кэша обычно не создает катастрофы. Но если большое количество зрителей одновременно запрашивает еще не закэшированный контент (например, сразу после публикации премьеры), то нагрузка, которую обычно принимает распределенная CDN-инфраструктура, частично перемещается к источнику, и его производительность становится заметной уже для всей аудитории.

Это один из самых показательных случаев, потому что средние показатели платформы могут выглядеть практически идеально.

Пусть 95% аудитории получает видео нормально, но пользователи определенного оператора в одном регионе регулярно сталкиваются с долгим стартом и повторной буферизацией. Средняя по стране метрика сгладит проблему настолько, что на общем графике она может почти исчезнуть. Поэтому качественную диагностику видео нужно уметь разбивать как минимум по географии, CDN, устройству и сети пользователя.

Для сети удобно использовать ASN (Autonomous System Number, номер автономной системы), который позволяет группировать пользователей по сетевой инфраструктуре оператора. Современные системы видеоаналитики позволяют сопоставлять показатели запуска и повторной буферизации с ASN, регионом, конкретным CDN, операционной системой и плеером.

Подробнее читайте в статье: Multi-CDN: раздача контента по всему миру без точек отказа

Если проблема устойчиво привязана к одному оператору, причиной может оказаться конкретный сетевой маршрут, взаимодействие сетей между собой или точка присутствия PoP (Point of Presence, точка присутствия), через которую идет пользовательский трафик по CDN.

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

В PC-Media используется несколько CDN-операторов и собственный балансировщик нагрузки, который позволяет распределять трафик между сетями; такой подход особенно полезен именно для ситуаций, когда качество доставки ухудшается не глобально, а на отдельном направлении.

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

Проблемой может стать:

• поддержка кодека,
• профиль кодирования,
• производительность декодера,
• особенности браузера,
• DRM или реализация самого плеера.

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

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

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

Для потокового видео CDN обычно раздает не один огромный файл, а последовательность небольших медиасегментов.

Их продолжительность влияет сразу на несколько характеристик системы:

• частоту HTTP-запросов,
• скорость переключения между вариантами качества,
• объем данных, который плеер получает за один запрос,
• структуру манифеста,
• поведение live-потока.

Универсальной продолжительности для всех систем нет. В актуальной спецификации Apple для обычного HLS рекомендуется целевая продолжительность сегмента около шести секунд, а каждый видеосегмент должен начинаться с независимого IDR-кадра, с которого декодирование можно начать без предыдущих кадров. Для Low-Latency HLS используются дополнительные частичные сегменты, для которых Apple рекомендует уже существенно меньшую длительность.

Чересчур частая сегментация увеличивает количество запросов и объектов, которые должны обработать плеер, CDN и серверная инфраструктура. А слишком крупные сегменты делают переключения качества менее гибкими и увеличивают объем данных, связанный с одним запросом.

Есть и более грубая техническая ошибка: фактический сегмент может оказаться длиннее значения, указанного в EXT-X-TARGETDURATION. RFC 8216 предупреждает, что нарушение требований к длительности сегментов способно приводить к проблемам воспроизведения.

Поэтому при странных проблемах, воспроизводимых на одном и том же контенте независимо от пользователя, нужно проверить не только сеть, но и сам HLS/DASH-пакет: длительность сегментов, точки ключевых кадров, корректность манифеста и синхронизацию вариантов качества.

Файл .m3u8 или .mpd обычно занимает несравнимо меньше медиасегментов, поэтому его размер редко становится основной причиной проблем. Зато без него плеер не знает, какой поток запрашивать дальше.

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

В live-сценариях к этому добавляется необходимость регулярно обновлять playlist, чтобы плеер узнавал о новых сегментах, поэтому для прямой трансляции важно смотреть не только скорость загрузки самих медиаданных, но и стабильность обновления манифеста. Если первый запрос к .m3u8 занимает две секунды, оптимизация скорости последующих сегментов сама по себе не вернет эти две секунды зрителю.

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

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

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

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

Для полноценной картины достаточно начать с нескольких показателей, каждый из которых отвечает на конкретный вопрос:

Среднего значения для части этих метрик недостаточно. Если у девятнадцати пользователей видео запускается за секунду, а у двадцатого за десять, то среднее еще может выглядеть приемлемо, хотя 5% аудитории регулярно получают плохой опыт.

Поэтому полезно смотреть перцентили:

• P50 показывает типичное значение,
• P95 показывает границу, хуже которой находится примерно 5% измерений.

Такой разрез лучше показывает «хвост» проблемных просмотров, который легко теряется в среднем значении. После этого данные нужно разрезать по CDN, региону, ASN, устройству, операционной системе, типу потока и конкретному видео. Современные системы видеоаналитики позволяют связывать качество воспроизведения с CDN, сетью пользователя и конкретным клиентским окружением.

Эта таблица полезнее попытки определить «хорошую скорость CDN» одной цифрой, потому что сначала сужает область поиска и только затем позволяет разбирать конкретный компонент. Потому что одинаковое «торможение» имеет разные причины.

Для первого расследования необязательно сразу внедрять большую систему мониторинга.

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

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

Логи плеера покажут выбранный вариант качества, переключения ABR и ошибки воспроизведения.

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

Следующий уровень – клиентская видеоаналитика, которая автоматически собирает события самого плеера и позволяет видеть реальный опыт пользователей. Серверная статистика CDN и клиентская статистика воспроизведения отвечают на разные вопросы: CDN знает, сколько данных было доставлено, а плеер знает, сколько из них пользователь действительно посмотрел и сколько времени ждал. Даже эти две величины могут не совпадать, поскольку плеер загружает часть видео вперед, а пользователь способен закрыть страницу раньше.

Для диагностики особенно неудобна архитектура, в которой хранение, транскодирование, CDN и плеер существуют как полностью независимые сервисы: каждый компонент показывает собственные метрики, а поиск проблемы превращается в сопоставление нескольких журналов и временных шкал.

PC-Media объединяет хранение, обработку и доставку видео, а для раздачи использует несколько CDN-операторов и балансировщик нагрузки. Такая архитектура дает возможность перераспределять трафик при деградации одного направления и рассматривать доставку как часть всей медиасистемы, а не как отдельный последний этап.

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

Как локализовать проблему показано на следующей схеме.

Почему видео может тормозить, если подключен CDN?

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

Что проверить, если видео долго запускается?

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

Почему видео сначала работает нормально, а потом начинает останавливаться?

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

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

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

Как понять, что проблема находится именно в CDN?

Полезно сравнить время и ошибки получения медиасегментов по разным CDN, регионам и операторам связи. Если ухудшение привязано к определенной сети доставки или конкретному направлению, а остальные показатели остаются стабильными, вероятность проблемы на уровне CDN или маршрута становится значительно выше.

Что такое время старта видео?

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

Какие метрики важнее всего для качества видео?

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