Skip to content
Все статьи
Стандарты и методика Телеком и WAN

Как мы тестируем QoE видео: старт, остановки и zap time

Alexander Zemskov 4 мин чтения
Как мы тестируем QoE видео: старт, остановки и zap time

Линк проходит тест throughput на полной подписной скорости, а зрители на нем все равно смотрят на крутящийся значок загрузки. Тест throughput шлет ровный поток. Видеоплеер работает иначе: забирает сегмент пачкой, замеряет, сколько длилась загрузка, и по этому выбирает битрейт следующего. Приставка IPTV показывает канал только после того, как обслужен ее IGMP join. Мы оцениваем каждого эмулированного зрителя по тому, что заметил бы человек на диване: секунды до первого кадра, остановки, битрейт, на котором оседает плеер, время переключения канала.

Стенд

Устройство под тестом стоит на пути видео: edge-кэш CDN, BNG или BRAS, домашний CPE, точка доступа Wi-Fi, SD-WAN edge, user plane мобильного ядра или линк WAN с включенными искажениями. Стенд эмулирует зрителей в трех видах. Плееры HLS и DASH запрашивают манифесты и сегменты по HTTPS у origin за устройством и переключают битрейт по уровню буфера и времени загрузки. Приставки подключаются к каналам multicast IPTV и уходят с них через IGMP. Абоненты видеозвонков шлют видео в реальном времени в обе стороны.

Генератор трафика заполняет остаток линка потоками web, VoIP и передачи файлов с весами из вашего профиля трафика. WANemu, сейчас в бете на линках 1G и 10G, добавляет задержку, jitter и потери в каждом направлении, случайные или пачками. Профили плееров, лестница битрейтов и сетка каналов ваши.

Что проверяем

  • Старт: время от запроса воспроизведения до первого кадра, по каждому плееру и перцентилями по зрителям в ваш вечерний пик
  • Остановки: события rebuffering за сессию и их суммарное время, на подъеме нагрузки и на самом пике
  • Битрейт: профиль, на котором оседает каждый плеер, доля сессии на верхнем профиле, как часто он уходит вниз
  • Edge-кэш: время ответа на сегмент, когда зрители одновременно запускают одно live-событие
  • Переключение канала: zap time от IGMP join до нового канала и leave, который останавливает старый, когда переключаются сразу много приставок
  • Качество multicast: MDI по каждому каналу посекундно, delay factor и media loss rate (RFC 4445)
  • Видеозвонки: время замираний, принятая частота кадров, потери и jitter по каждому звонку в обе стороны
  • Искажения: тот же набор с задержкой, jitter и пачечными потерями на линке и с фоновым трафиком, который его заполняет, QoS включен

Что обычно ломается

Полисер с мелким бакетом на BNG или CPE. Плеер забирает каждый сегмент пачкой на скорости линии, полисер отрезает голову пачки, TCP сбрасывает скорость, и сегмент приходит позже, чем позволяет время его воспроизведения. Плеер считает сеть медленной и уходит на профиль ниже. В типичном проекте профиль 50 Мбит/с выдал полную скорость в тесте throughput, а 4K-плеер на нем треть сессии провел на профиль ниже верхнего. Больший burst size вернул его наверх.

IGMP в начале часа. На пустом узле join занимает десятки миллисекунд, и тест переключения с одной приставкой проходит. Когда много приставок переключаются разом, join встают в очередь в control plane, и zap time уходит за секунду. Без fast leave еще хуже: старый канал продолжает идти по абонентской линии, пока не истечет таймер query, два HD-канала делят линию, рассчитанную на один, и MDI показывает потери на обоих.

Потери пачками. Видеозвонок переживает 1 % случайных потерь: FEC и маскировка ошибок их закрывают. Тот же 1 %, пришедший пачками, как на загруженной ячейке Wi-Fi или радиолинке, каждый раз замораживает картинку на доли секунды. На стенде Wi-Fi это видно, когда ячейка заполняется до расчетного числа клиентов, на линке WAN – через пачечные потери по модели Гилберта–Эллиотта. Прогон со случайными потерями того же среднего уровня этого не видит.

Что в отчете

Время старта, остановки и битрейт по каждому плееру, с перцентилями по зрителям. Zap time по каждому каналу против частоты join. Delay factor и media loss rate MDI по каждому каналу посекундно. Время замираний и частота кадров по каждому звонку. Все на одной временной шкале с искажениями и счетчиками устройства, плюс настройки плееров, лестница битрейтов и значения эмулятора, чтобы тот же вечер повторился на следующей прошивке.

С чего начать

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

Автор

Alexander Zemskov

Эксперт по тестированию сетей и безопасности, продажи (19+ лет) | Performance & Load Testing | IXIA | Spirent | Keysight | Xena | Xinertel и другое

Блог

Читайте также

Маршрутизация и коммутация

Как мы тестируем PoE: бюджет мощности, приоритеты и отказ БП

В даташите PoE-коммутатора покупатель читает две строки: «PoE+ на всех 48 портах» и бюджет мощности, например 740 Вт. 48 портов по 30 Вт дают 1440 Вт. Обе строки честные,…

Alexander Zemskov 4 мин чтения
Стандарты и методика

Как мы автоматизируем регрессию сети: каждая сборка и один diff

В release notes новой прошивки написано «исправления ошибок и улучшения производительности». Вторую половину фразы никто не измеряет. Ручная регрессия занимает у инженера…

Alexander Zemskov 4 мин чтения