Обзор: тестируем временную задержку и максимальную скорость передачи RTMP и SRT протоколов

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

Разработанный компанией Haivision протокол SRT отличается исходным кодом открытого типа, использует интеллектуальный механизм, основанный на повторной пакетной передаче данных, базирующейся на протоколе UDP при совместной работе с шифрованием AES-256.

Сквозная задержка характеризуется общим количеством времени, необходимым для трансляции одного видеокадра от камеры к экрану.

Задержка зависит от пути прохождения данных, числа этапов обработки видео, включает следующие виды: задержку при кодировании/декодировании, источники видео (видеоплееры, камеры), отображающие устройства (экраны, дисплеи), линию передачи данных (оптоволокно, интернет, спутник, радио и т. д.)

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

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

Источником сигнала выступал Blackmagic Hyperdeck Shuttle — видеорегистратор, транслировавший данные на первый экран с параллельным применением энкодеров Haivision KB, Makito X. Трансляция происходила при участии встроенного тайм-кода для идентификации каждого отдельного видеокадра. Разрешение видео составляло 720p, кадры воспроизводились со скоростью 60/сек.

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

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

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

Как декодер использовался универсальный распространенный видеоплеер VLC Player, способный декодировать множество видеоформатов, включая SRT, RTMP.

Wowza Streaming Engine — сервер, размещенный на AWS-объектах, выступил конечной точкой назначения для RTMP-потоков при использовании сетевых шлюзов Haivision Media Gateways. VLC-декодер принимал данные RTMP обратно в исходном месте из этого определенного сервера. Отличие времени передачи данных до сервера, шлюза и в обратном направлении составило менее 2 м/сек. Большинство тестов показало одинаковое время трансляции.

Для потоков SRT конечной точкой передачи также стал размещенный на AWS- объектах сетевой шлюз Haivision Media Gateway, доступный как программное обеспечение или дополнительная опция.

Вход, выход для потоков SRT были настроены как порты SRT, обладающие конкретным буфером задержки, размер которого зависит от времени, затраченного на передачу RTT-данных до точки назначения.

DSL-модем Fritzbox 7590 обеспечивал соединение с интернетом, скорость входящих данных составила 100 Мбит/с, исходящих — 42 Мбит/с. Постоянное отслеживание параметров соединения гарантировало отсутствие влияния сторонних приложений на перегруженность линии связи.

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

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

По умолчанию сервер Wowza устанавливает для буфера отправки оптимальный средний показатель 65 000 байт (с возможным увеличением при необходимости). Размеры принимающих буферов влияют на потоковую онлайн-передачу видео, поэтому их настройка производится так, чтобы у энкодеров был сформирован запас пропускной способности. Однако не стоит устанавливать слишком большие значения, поскольку значительные объемы буферов могут привести к перегрузке сервера.

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

Другое важное отличие между двумя вышеописанными типами протоколов — осуществление повторной трансляции пакетов данных. RTMP работает на базе протокола TCP, который основан на подтвержденном отправленном получателем приеме данных. Но подтверждения (для экономии обратного трафика) не уходят отправителю сразу. Это происходит только после получения конкретной последовательности пакетов данных. Если в ней окажутся утерянные пакеты, то их полная последовательная серия будет передана повторно.

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

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

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

Для обеспечения доставки стабильного аудио-, видеопотока в Сидней из Германии с использованием протокола RTMP размер буфера приемника на сервере Worza был увеличен до 260 000 байтов, а принимающий буфер VLC Player — до 2000 м/сек (при стандартном значении 250 м/сек). Ниже этих значений качество потока данных ухудшалось или видео не воспроизводилось совсем.

Трансляция данных из Германии в Калифорнию бесперебойно работала с участием размера буфера 65 000 байт, однако в обратном направлении происходил джиттер, что вызвало временную задержку пакетов данных. Поэтому для VLC Player буферизация была увеличена до 650 м/сек.

Результаты теста показали, что видеосигнал не всегда проходит по самому короткому интернет-пути. Это зависит от мощности, производительности каналов передачи данных. В отличие от вышеописанного «калифорнийского» тестирования связь была стабильнее, отличалась меньшим джиттером, хотя время передачи данных до точки назначения было примерно одинаковым, что позволило применять меньшие объемы буферов для потоков RTMP.

Время передачи данных из Тюрингии во Франкфурт и обратно составило 17 сек. Временная задержка была сравнима с результатами для Калифорнии и Вирджинии, но при меньшем значении затраченного времени SRT-протокол выиграл более 1 сек по сравнению с локациями в США.

Проведенные тесты показали, что протокол SRT оказался быстрее RTMP в 2.5−3.2 раза.

Аппаратные энкодеры, декодеры также могу ускорять процессы кодирования / декодирования видео.

Проведенное тестирование для определения временной задержки позволило сравнить результаты использования Haivision KB и VLC Player (протоколы RTMP, SRT) с показателями Haivision Makito X (SRT).

SRT-протокол при совместной работе с энкодером Makito X по показателям значительно превышает RTMP. Например, прямая и обратно сквозная задержка в Австралию снижалась с 9.6 до 1.6 сек, а в Германии результат оказался в 12 раз выше и показал 333 м/сек (сверхнизкая задержка) для SRT по сравнению с 4.1 сек для RTMP.

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

Для тестирования скорости потоковой передачи было выбрано местоположение, где отмечался высокий уровень соединения с интернетом — Microsoft Production Studios, расположенной в Редмонде, штат Вашингтон. Скорость интернет-соединения всех подключенных устройств составляла 1 Гб.

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

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

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

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