Изучение потоковой передачи SRT в сетях 4G: ход эксперимента и результаты

Для того чтобы в ходе трансляции увидеть количество потерянных пакетов и джиттер, производится отправка потока с постоянным битрейтом (CBR) 5 Мбит/сек по протоколу UDP в течение двух минут с использованием приложения для тестирования SRT-xtransmit и утилиты SRT-stats-ploting. Отправляющая сторона генерирует полезную нагрузку с целевым битрейтом, создавая поток CBR. Затем полезные данные отправляются по протоколу UDP (стационарное соединение 4G) на удаленный получатель, расположенный в Azure EU West. Аргумент — enable-metrics предписывает генератору полезной нагрузки внедрить в последнюю определенные маркеры, которые получатель может использовать для расчета таких показателей, как потеря пакетов, изменение их порядка, задержка передачи и джиттер.

На рис. 1 показано общее количество полученных, потерянных и полученных не по порядку пакетов. Наблюдается стойкая потеря 1−2 пакетов в секунду. Ситуации временной перегрузки выявляются большей потерей (10 пакетов и более). Потеря одного-двух пакетов в секунду уже может привести к визуальным артефактам при декодировании видеопотока, поэтому для улучшения качества просмотра необходимы механизмы восстановления потерь.

Изменения сквозной задержки представлены на рис. 2. По чистому UDP она относительно стабильна, с областью колебаний около 150 мс и случайными всплесками дополнительных 400 мс. В данном случае сквозная задержка измеряется как разница между системными часами двух одноранговых узлов. Абсолютное значение зависит от того, насколько хорошо синхронизированы часы (они не могут быть синхронизированы со 100% точностью из-за законов физики). Однако изменение значений с течением времени обеспечивает точную оценку изменений сквозной задержки между отправляющим и принимающим приложениями.

Джиттер (RFC 3550) входящих UDP-пакетов также относительно стабилен (рис.3) и составляет около 4 мс, иногда достигая 8 мс, что не приводит к резким изменениям. Декодер будет компенсировать наличие буфера соответствующего временного интервала.

SRT работает поверх UDP с применением методов восстановления пакетов и управления задержкой. По умолчанию основным используемым методом восстановления потерянных пакетов выступает вторичный автоматический запрос (ARQ), который включает повторную передачу. Во время потоковой онлайн-трансляции SRT по умолчанию также пытается сохранить постоянную сквозную задержку между одноранговыми узлами. Показатель задержки настраивается. В пределах сконфигурированной задержки буферизации приемника SRT принять решение о прекращении повторной передачи потерянного пакета может как отправитель, так и получатель. Пакет просто «отбрасывается» (в терминологии SRT) в пользу других.

Одним из основных параметров конфигурации, используемых для управления повторными передачами в SRT, выступает задержка. Её рекомендуемое минимальное значение в 3−4 раза превышает среднее время приема-передачи (RTT). Например, RTT остается постоянным и для того, чтобы пакет достиг получателя, требуется 0,5 x RTT. При потере данных требуется еще один 0,5 x RTT, для информирования отправителя о потере пакета, а также один 0,5 x RTT для повторной передачи потерянного пакета. Перегрузка сети приводит к увеличению RTT, в то время как SRT должен поддерживать постоянную сквозную задержку. Поэтому для повторной передачи пакетов выгоднее использовать завышенные параметры задержки.

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

В описанных ниже экспериментах, используется тестовое приложение SRT‑xtransmit, созданное с помощью SRT v1.5.0 RC0. Версия v1.5.0 имеет улучшения, созданные для управления задержкой и методами контроля перегрузки в режиме онлайн. Поэтому результаты с использованием предыдущих версий SRT могут отличаться.

Задержка буферизации согласовывается и запускается при первом установлении соединения SRT. С этого момента протокол пытается сохранить сквозную задержку и компенсировать изменения RTT.

Для правильной настройки задержки требуется оценка RTT канала (например, с помощью команды «ping», если она доступна).

Альтернативный подход с использованием метрик SRT предполагает запуск 3-минутной потоковой передачи SRT со скоростью 5 Мбит/сек для визуализации изменений RTT в действии. При этом используется статистика SRT, записанная «SRT -xtransmit». Показатель задержки SRT по умолчанию составляет 120 мс. Любое подобранное значение задержки будет верным, поскольку производится только сбор статистики RTT без необходимости восстановления после возможной потери пакетов.

Рис. 4 демонстрирует среднее значение RTT канала, которое составляет около 150 мс. При проведении эксперимента также фиксировались всплески до 300 мс во время коротких периодов перегрузки сети. Если среднее значение приравнивается к 150 мс, то рекомендуемый минимальный показатель задержки SRT от 3 до 4 x RTT не будет надежно покрывать возможные колебания задержки в мобильных сетях, поэтому выбор более высокого значения будет оправдан. Для следующих экспериментов показатели 5xRTT 750 мс (5×150 мс) и 8xRTT 1200 мс выбраны параметрами задержки SRT (задержки буферизации) для сравнения.

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

В тестовом режиме максимальная пропускная способность, определенная провайдером, составляет около 20 Мбит/сек. Это не означает, что поток со скоростью 20 Мбит/сек способен стабильно пересекать сеть. Однако, если скорость отправки периодически достигает 20 Мбит/сек, большая часть пакетов может достичь получателя. Существует множество утилит для зондирования пропускной способности (iperf, ethr и др).

При альтернативном подходе к измерению пропускной способности с помощью SRT для определения фактических границ производится отправка прямого потока 5 Мбит/сек с помощью с увеличением исходного битрейта на 2,5 Мбит/сек каждые 15 секунд. Графики ниже показывают статистику SRT от отправителя и получателя. Прямая трансляция со скоростью 5 Мбит/сек происходит без заметных перегрузок (см. интервал 0−15 секунд на рис. 5−6). Более высокие скорости потоковой передачи 7,5 Мбит/сек и 10 Мбит/сек (15−45 секунд на рис. 5−6) обычно проходят через сеть, но на них часто влияют некоторые заметные потери пакетов и увеличение RTT (побочный индикатор перегрузки в сети, рис. 7). Отправка на скорости 12,5 Мбит/сек (45−60 секунд на рис. 5−6) вызывает заметные перегрузки на пути.

В терминологии SRT «потерянные» пакеты означают потерянные в сети, а «отброшенные» — это невосстановленные потерянные пакеты, которые SRT исключает из трансляции для продолжения работы и согласования с ограничением сквозной задержки.

Максимальный предел пропускной способности (ограничение скорости вывода) SRT устанавливается непосредственно с помощью параметра сокета SRTO_MAXBW. Ограничение также можно установить по-другому, указав входной (исходный) битрейт (см. SRTO_INPUTBW) и разрешенные служебные данные (см. SRTO_OHEADBW) поверх него (MAXBW = INPUTBW x (1 + OHEADBW)). В такой конфигурации входной битрейт может быть либо установлен, либо оценен SRT во время выполнения. Из-за больших различий в RTT и условиях перегрузки в мобильных сетях, высокие значения доступных служебных данных будут способствовать качественной трансляции. Это связано с тем, что возможность кратковременной отправки на более высокой скорости позволяет SRT повторно передавать больше пакетов и пытаться восстановить потерянные пакеты быстрее, как только перегрузка и RTT уменьшатся.

Таким образом, потоковая передача со скоростью 8 Мбит/сек по этой сети становится безопаснее и допускает ретрансляции со скоростью до 10 Мбит/с (25% сверх 8 Мбит/сек). Разрешение более высоких скоростей повторной передачи может привести к собственной перегрузке, резко уменьшая процент пакетов, достигающих декодера (принимающего приложения).

Результаты потоковой SRT-трансляции зависят от выбранной конфигурации.

Тестовый поток в данном случае был отправлен со скоростью 8 Мбит/сек. Максимальная пропускная способность при этом составила 10 Мбит/сек (1 250 000 байт/сек), а задержка буферизации приемника — 750 мс. Результаты такой потоковой передачи представлены на рис. 8−12.

Потери данных внутри канала незначительны, они эффективно восстанавливаются путем повторной передачи потерянных пакетов (см. синие и красные линии на рис. 8−9 для повторно переданных и потерянных пакетов). Такого рода потери уже были показаны для чистой потоковой передачи UDP (см. рис. 1).

Однако наблюдается заметная потеря пакетов внутри канала примерно на 20-й секунде (см. рис. 8−9). Время перегрузки RTT пути увеличилось до 1200 мс (см. рис. 10), превысив настроенную задержку SRT. При таком увеличении RTT пакеты достигают получателя позже заданной задержки. Следовательно, SRT имеет пустой буфер приемника, а время для восстановления потерянного пакета повторной передачей отсутствует. После этого потерянные данные приходят со скоростью 12 Мбит/сек, хотя отправитель не превышал скорости 9 Мбит/сек. Это означает, что эти пакеты были буферизованы в сети и доставлены, как только ресурсы вернулись к пользователю мобильной службой. Для восстановления таких больших потерь задержка SRT должна быть увеличена выше пикового значения RTT. Однако этот тип перегрузки считается редким и возникающие визуальные артефакты после потери могут быть приемлемыми в пользу более низкой сквозной задержки.

Сразу после больших потерь наблюдается всплеск сквозной задержки и джиттера (после SRT) на стороне получателя (см. рис. 11−12). Увеличение задержки происходит из-за того, что пакеты приходят по порядку, хотя и с задержкой, превышающей задержку буферизации. SRT не отбрасывает эти пакеты, поскольку они могут быть доставлены принимающему приложению (например, декодеру) с временными метками источника. В этом случае задача декодера состоит в том, чтобы решить (например, на основе этих меток времени), что делать с задержанными пакетами. Так, видеодекодер может по-прежнему декодировать связанные видеокадры (выступающие эталонными), но либо не представлять их пользователю, либо временно увеличивать частоту кадров, чтобы компенсировать задержку.

Джиттер (рис. 11) колеблется в районе 50 мс, что заметно меньше, чем около 4 мс для чистого UDP (рис. 3). Однако есть заметные небольшие всплески, связанные с увеличением RTT пути. Поскольку RTT увеличивается со 150 мс до 1200 мс (сверх настроенной задержки SRT), сквозная задержка во времени увеличивается примерно на 820 мс.

Наблюдаемое заметное увеличение RTT компенсируется за счет увеличения задержки буферизации SRT до 1200 мс. Результаты потоковой передачи на скорости 8 Мбит/сек с максимальным ограничением пропускной способности, установленным на 10 Мбит, и задержкой буферизации приемника, равной 1200 мс, представлены на рис. 13−17.

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

При статистическом анализе потерянных пакетов отправителя учитываются все события отчетов о потере для пакета, в том числе повторные. На стороне получателя во внимание принимаются только фактические события обнаружения потерь, а не количество отправленных отчетов о потерях. Поэтому эти статистические данные не совпадают на рис. 13 и 14.

Наблюдалось заметное увеличение RTT на 60-й секунде потоковой передачи (см. рис. 15), а приемник фиксировал потерю пакетов. Однако SRT удалось восстановить потерю пакетов и компенсировать увеличение RTT.​

Результаты вышеописанных экспериментов показывают возможности настройки прямой трансляции через SRT в мобильной сети. За счет небольшого увеличения сквозной задержки (5 x RTT или выше) внутри сети будет наблюдаться низкий уровень джиттера на выходе, а также постоянная незначительная потеря пакетов и их возможное переупорядочивание.

Результаты были получены с использованием стационарной точки доступа 4G. В случае нестационарной мобильной точки доступа характеристики сети могут отличаться, а конфигурация SRT потребует изменений в сторону увеличения задержки для того, чтобы справиться с потерей пакетов и удлинением задержек при переключении между мобильными станциями (вышками).