Протокол rtmp что это
Real Time Messaging Protocol
Из Википедии — свободной энциклопедии
Real Time Messaging Protocol (сокращённо англ. RTMP ) проприетарный протокол потоковой передачи данных, в основном используется для передачи потокового видео и аудиопотоков с веб-камер через интернет.
Серверная часть реализована авторами протокола Adobe Inc, во Flash Media Server, стоимость которого, в зависимости от редакции, составляет 995—4500 USD. Модули для сервера должны быть написаны на ActionScript.
Группа энтузиастов реверсировала протокол, и выпустила бесплатную версию сервера Red5. Сервер написан на Java. Модули для сервера должны быть написаны на Java.
В 2009 году Adobe выпустила документ, названный спецификацией RTMP, однако это умышленно неполный документ, направленный на сдерживание развития альтернативных серверов. Для прочтения этого документа необходимо согласиться с лицензионным соглашением, которое требует создания RTMP сервера только по спецификации от Adobe без каких-либо отступлений. В этой спецификации указаны намеренно неверные данные, так, например, для включения на Flash Player декодера H.264 требуется криптографически подписать хендшейк, а в спецификации написано, что обязательно надо заполнять произвольными данными. Таким образом, приняв условия лицензии на спецификацию, разработчик лишается возможности реализовать полноценный RTMP сервер.
Также существует не вполне совместимый, но соблюдающий большую часть спецификаций протокола RTMP проект HaxeVideo, реализованный Russell Weir на специализированном языке HaXe для серверной виртуальной машины NekoVM. Распространяется в исходных текстах и отличается низкой ресурсоёмкостью по сравнению с Java-реализациями, а также отсутствием необходимости ставить на сервер как Java, так и другие пакеты.
В мае 2009 года появился Flash Media Server написанный на языке Python (FMSPy) — RTMP-сервер приложений на Adobe Flash/Flex/Air. На данный момент проект перестал разрабатываться (автор предлагает «подобрать» его любому желающему [1] ) и представляет собой что-то похожее на Adobe Flash Media Server, но с гораздо меньшими возможностями. FMSPy — проект с открытым исходным кодом и распространяется по лицензии MIT.
С августа 2009 до января 2012 года в активной OpenSource-разработке находится проект Erlyvideo — RTMP-сервер на языке Erlang. По функциональности близок к Wowza, умеет забирать видео по RTSP, раздавать на iPhone. В сентябре 2012 года был удалён с GitHub и продолжил разрабатываться на проприетарной коммерческой основе.
В 2012 году был разработан nginx-rtmp-module — модуль поддержки протокола RTMP для сервера nginx. Модуль написан на C и отличается высокой производительностью и простотой настройки. Поддерживает live-вещание, ретрансляции, запись FLV, HTTP вызовы и т.д. Распространяется по лицензии BSD.
Какой Протокол Стриминга Лучше для Вас: RTMP или RTSP
Содержание
Сравним протоколы потоковой передачи RTMP и RTSP. Расскажем, как они работают, какие у каждого плюсы и минусы. Подскажем, как выбрать в вашем случае.
Если вы хотите запустить платформу для трансляции видео с минимальной задержкой, у вас будет весьма ограниченное количество протоколов потоковой передачи данных для решения этой задачи. При этом если в качестве канала передачи видеопотока вы хотите использовать интернет, выбор будет еще меньше, поскольку вам нужно будет преодолеть ряд трудностей, например — джиттер, лаги или потеря пакетов. В этой статье мы сравним два таких протокола связи — RTMP и RTSP, опишем их преимущества с недостатками, а также дадим некоторые рекомендации по выбору наиболее подходящего для вас варианта.
Что такое протокол связи
Задержка при потоковой передаче данных посредством популярных протоколов связи. Источник
Прежде всего стоит уточнить, что и RTMP, и RTSP — это протоколы потоковой передачи данных, что означает, что они представляют собой наборы определенных соглашений интерфейса логического уровня, определяющих метод передачи видео, аудио и других типов данных между различными платформами, системами или устройствами. Эти правила нужны, чтобы задать стандарт передачи информации и обработки ошибок, что нужно для нормальной работы любой видеотрансляции.
Если сравнить видео, которые нужно отправить зрителям, с автомобилем, то протокол потоковой передачи — это правила дорожного движения и сама дорога, по которой автомобиль перемещается из одного места в другое. Если дорога хорошая, машина без проблем доедет до своей цели. Если же на дороге будут ухабы и ямы, то движение займет больше времени и машина может получить повреждения.
С видеоданными все так же: если протокол хороший, видеосигнал доберется до зрителя с минимальной задержкой и будет высокого качества. Если же протокол плохо реализован или не соответствует задаче, то видео на экране зрителя может «сыпаться», часто прерываться для подзагрузки, содержать артефакты, вовсе не грузиться или аудио- и видеосигналы будут рассинхронизированы.
Различные протоколы потоковой передачи данных ориентированы на разные аспекты потока (задачи). Обычно их делят на протоколы с адаптивным битрейтом, которые нацелены на уменьшение задержек и буферов для видеопотока, и те, что направлены на максимальное сокращение задержки, что позволяет передавать видеосигнал зрителям практически в реальном времени — live streaming.
RTMP и RTSP — это, пожалуй, два наиболее распространенных протокола, ориентированных на стриминг видео с минимальной задержкой. И хотя они созданы для достижения схожих целей, при пристальном сравнении между ними легко обнаружить существенные различия, которые важно знать.
Что такое RTMP и как он работает
Протокол обмена сообщениями в реальном времени, или RTMP — это стандартизированный протокол для передачи мультимедийных данных через интернет. Данная технология была разработана Macromedia (в настоящее время принадлежит Adobe), и изначально она использовалась для передачи данных между RTMP-сервером и Flash-плеером на устройстве пользователя. Сейчас Flash больше не используется из-за проблем с безопасностью, но RTMP все еще популярен.
Как протокол связи технология RTMP нацелена на обеспечение стабильной и плавной передачи увеличивающихся объемов данных, необходимых для передачи и приема видео в реальном времени. Что достигается посредством фрагментирования потока данных на небольшие одинаковые части (по умолчанию составляют 64 байта для аудиоданных и 128 байтов для видеоданных) и их последовательную передачу на принимающее устройство, которое затем снова собирает их в видеопоток.
После того как Flash устарел в 2020 году (Google и другие крупные игроки полностью прекратили поддержку Adobe Flash Player), RTMP стал использоваться в качестве протокола с открытым исходным кодом для вклада первой мили (передачи от кодировщика к сетевому видеохосту). Именно таким образом RTMP сейчас использует Facebook, YouTube, Periscope и большинство других платформ.
Сейчас RTMP существует в 5 вариантах:
Как работает потоковая передача RTMP
Как правило, прямая видеотрансляция работает следующим образом: камера снимает видео (или видеокарта захватывает экран) и отправляет его на хост или сервер видеоплатформы через кодировщик (этот этап обычно называют «первой милей»). Затем сервер или видеоплатформа обрабатывает этот поток и передает его дальше через сеть доставки контента (CDN) для распространения видеопотока на устройства пользователей (это «последняя миля»). Когда еще работал Flash, оба эти этапа проходили посредством RTMP, но с тех пор, как Flash устарел, RTMP больше не работает на «последней миле». С этого момента поток должен перехватить другой протокол связи (HLS, MPEG-DASH, CMAF или WebRTC).
На диаграмме показаны четыре отдельных этапа в цепочке доставки видео в реальном времени. Первый этап обычно называют «первой милей» (передача видео от камеры до сервера), а четвертый — «последней милей» (видео доставляется на экран пользователя, например телевизор). Источник
Однако на первой миле RTMP по-прежнему актуален, поскольку он отлично справляется с обеспечением стабильного и плавного видеопотока между источником видео и RTMP-сервером за счет разделения больших объемов данных на маленькие блоки и их передачу через несколько виртуальных каналов. При этом RTMP также открывает постоянное соединение между источником потока и сервером, позволяя протоколу выступать в качестве носителя для доставки пакетов данных.
Преимущества и недостатки RTMP
Что такое RTSP и как он работает
Для обеспечения плавной и согласованной потоковой передачи данных RTSP использует два других сетевых протокола связи — TCP для выдачи и приема команд управления (например, запроса на воспроизведение или остановку) и UDP (протокол пользовательских датаграмм) для доставки аудио, видео и данных. Благодаря этому клиент может начать воспроизводить RTSP-поток во время загрузки потока.
Хотят RTSP можно использовать как для прямых трансляций, так и для передачи видео по запросу, сейчас его обычно используют на последней миле для передачи видеопотока с облака в проигрыватель устройства пользователя, поскольку данный протокол позволяет зрителю воспроизводить, приостанавливать и перематывать видео. Кроме того, RTSP также популярен в системах, где нужно передать видеосигнал с камер по IP, например с IP-камер или камер видеонаблюдения.
Как работает потоковая передача RTSP
Схема передачи видео через RTSP. Источник
Как протокол связи RTSP работает следующим образом. Когда пользователь (программа, приложение или камера) хочет передать видеосигнал с удаленного источника, пользовательское устройство отправляет RTSP-запрос на специальный сервер (или платформу потокового видео), чтобы определить доступные параметры, такие как воспроизведение, пауза, перемотка и запись. Затем сервер возвращает на устройство сигнал со списком запросов, которые он может принимать через RTSP.
Как только устройство (плеер) узнает список команд и как сделать запрос, он передает запрос описания видеоконтента на сервер потоковой передачи, и сервер отвечает описанием этого мультимедиа. Дальше устройство отправляет запрос на загрузку, а сервер отвечает информацией о транспортном механизме, и дальше инициируется процесс потоковой передачи видео через указанный механизм.
Так как RTSP зависит от выделенного сервера и полагается на RTP, данный протокол не поддерживает шифрование видеоконтента или повторную передачу потерянных пакетов. Кроме того, RTSP не совместим с HTTP, следовательно, он не позволяет напрямую воспроизводить видеопоток в веб-браузере. Для этого нужно конвертировать видеопоток через специальный промежуточный сервер.
Преимущества и недостатки RTSP
Технические характеристики RTMP vs RTSP
Какой протокол лучше для вас
IP-камеры → RTSP. Практически все IP-камеры поддерживают RTSP, что обусловлено тем, что IP-камеры существовали задолго до создания протокола RTMP. И поскольку RTSP был (и остается) достаточно простым и эффективным инструментом для передачи видеосигнала, нет необходимости что-то менять.
В связке RTSP и IP-камеры, сама IP-камера действует как RTSP-сервер. Это означает, что для подключения видеокамеры к серверу IP-камеры и трансляции видео необходимо запустить RTSP-клиент, например, посредством Restreamer Red5 Pro. Данный плагин позволяет подключиться к потоку в качестве клиента и перенаправить его на другие конечные точки, поддерживающие Red5 Pro (браузер, работающий с WebRTC).
IoT-устройства → RTSP или RTMP. Датчики, дроны, роботы, машины и другие устройства Интернета вещей могут выиграть от возможности транслировать видео в реальном времени. Поскольку такая трансляция не только покажет, что «видит» IoT-устройство, но и позволит управлять им в реальном времени. Благо, в большинство этих устройств изначально встроено программное обеспечение с поддержкой RTSP. Однако некоторые производители, такие как DJI, предпочитают RTMP.
Red5 Pro Mobile SDK → RTSP. Обычно мобильные устройства не поддерживают RTSP. Однако его можно легко добавить с помощью Red5 Pro Mobile SDK, который использует RTSP для трансляции видеоконтента в реальном времени на мобильные устройства и обратно через приложение Red5 Pro. Таким образом можно создавать как отдельные соединения источник-зритель, так и вести большое количество трансляций к большому количеству зрителей (подписчиков стримера).
YouTube, Twitch, Facebook → RTMP. Несмотря на отказ от Flash Media Player, RTMP до сих пор используется в качестве протокола приема во многих сторонних потоковых сервисах и приложениях, например в YouTube Live, Twitch и Facebook. В Zoom также встроена поддерживает вывод видео потока по RTMP.
Старый аппаратный кодировщик → RTMP. Многие аппаратные кодировщики видео (особенно это актуально для старых устройств) принимают только RTMP-потоки. Если ваша задача / проект требует использования такого кодировщика, то выбор между RTMP и RTSP для вас будет очевиден.
Заключение
Споры о том, какой протокол потоковой передачи лучше — RTMP или RTSP, продолжаются уже больше двадцати лет, и, похоже, им не будет конца, пока один из протоколов не устареет окончательно. Что, скорее всего, случится еще нескоро из-за резкого роста числа влогеров, стримеров и прочих энтузиастов live-трансляций.
Правда, если подумать, вам не обязательно выбирать между одним из этих протоколов потокового видео. Выбрав надежного технического партнера, такого как компания-разработчик Merehead, вы можете разработать решение, которое вберет в себе лучшее этих двух протоколов и обойдет их недостатки. Кастомная разработка потребует немного больше времени и ресурсов, чем готовые решения, но в долгосрочной перспективе она все равно будет более выгодной.
Протокол rtmp что это
Просьба оставлена не автоподтверждённым участником, который не имеет права на переименование страниц и считает необходимость такого действия, в данном случае, очевидным без предварительного обсуждения. На странице обсуждения может быть пояснение.
Real Time Messaging Protocol (сокращённо англ. RTMP ) проприетарный протокол потоковой передачи данных, в основном используется для передачи потокового видео и аудиопотоков с веб-камер через интернет.
Серверная часть реализована авторами протокола Adobe Inc, во Flash Media Server, стоимость которого, в зависимости от редакции, составляет 995-4500 USD. Модули для сервера должны быть написаны на ActionScript.
Существуют недорогие аналоги протокола, например, Wowza Media Server. Модули для сервера должны быть написаны на Java.
Группа энтузиастов реверсировала протокол, и выпустила бесплатную версию сервера Red5. Сервер написан на Java. Модули для сервера должны быть написаны на Java.
В 2009 году Adobe выпустила документ, названный спецификацией RTMP, однако это умышленно неполный документ, направленный на сдерживание развития альтернативных серверов. Для прочтения этого документа необходимо согласиться с лицензионным соглашением, которое требует создания RTMP сервера только по спецификации от Adobe без каких-либо отступлений. В этой спецификации указаны намеренно неверные данные, так, например, для включения на Flash Player декодера H.264 требуется криптографически подписать хендшейк, а в спецификации написано, что обязательно надо заполнять произвольными данными. Таким образом, приняв условия лицензии на спецификацию, разработчик лишается возможности реализовать полноценный RTMP сервер.
Также существует не вполне совместимый, но соблюдающий большую часть спецификаций протокола RTMP проект HaxeVideo, реализованный Russell Weir на специализированном языке HaXe для серверной виртуальной машины NekoVM. Распространяется в исходных текстах и отличается низкой ресурсоёмкостью по сравнению с Java-реализациями, а также отсутствием необходимости ставить на сервер как Java, так и другие пакеты.
С августа 2009 в активной разработке находится проект Erlyvideo — RTMP-сервер на языке Erlang. Сервер сейчас по функциональности близок к Wowza, умеет забирать видео по RTSP, раздавать на iPhone. Распространяется по лицензии GPL
Протоколы RTMP и SRT: сравнение задержки по времени и скорости передачи.
Компания Haivision подготовила большое сравнение протоколов для передачи видео rtmp и srt. Мы публикуем эту статью в оригинале. Будет крайне полезно знать всем, кто занимается онлайн-трансляциями и телемостами.
Введение
Для тех, кто хочет организовать трансляцию видео в режиме LIVE через публичный интернет с малой временной задержкой, существует весьма ограниченно число интернет-протоколов, из которых можно сделать выбор. Это особенно актуально, если использовать публичный интернет в качестве линии передачи данных, так как с его использованием возникают ряд серьезных трудностей, которые необходимо преодолеть, например – потеря пакетов данных или джиттер. В этом обзоре мы проведем сравнение и оценку двух наиболее популярных протоколов передачи данных через интернет – это RTMP и SRT протоколы.
Протокол потоковой передачи данных RTMP (Real-Time Messaging Protocol) – это хорошо продуманный и зарекомендовавший себя на практике протокол потоковой передачи данных с устоявшейся репутацией (особенно в области надежности), благодаря возможности ретрансляции пакетов данных на основе протокола TCP (Transmission Control Protocol) и настраиваемым буфером данных.
Протокол потоковой передачи данных SRT (Secure Reliable Transport Protocol) – это протокол с открытым исходным кодом, впервые разработанным компанией Haivision, который использует интеллектуальный механизм повторной передачи пакетов данных на основе UDP-протокола (User Datagram Protocol) совместно с AES-256 шифрованием.
В этом обзоре мы проведем исследование, как протокол SRT функционирует в реальных условиях в публичном интернете по сравнению с RTMP протоколом. Мы рассмотрим следующие вопросы: какой размер буфера требуется, какая задержка возникает при передаче данных и есть ли предел пропускной способности сети, которая вам может потребоваться. Мы также ответим на вопрос – как далеко можно транслировать видео в масштабах всего земного шара без искажения изображения и звука.
Сравнение задержки по времени при передаче данных с использованием протоколов RTMP и SRT
Сперва давайте рассмотрим сквозную задержку по времени, которая возникает при передаче данных от источника к приемнику видео. Сквозная задержка – это общее количество времени, которое занимает прохождение одного кадра видео от видеокамеры к экрану. Существует множество факторов, которые влияют на задержку при передаче данных и зависят от пути прохождения данных и количества этапов обработки видео. Хотя по отдельности эти задержки могут быть минимальными, в совокупности они играют значительную роль. Эти задержки включают в себя: задержку при кодировании, декодировании, линию передачи данных (интернет, спутник, радио, оптоволокно и т.д.), источники видео (камеры, видеоплееры) и устройства отображения – дисплеи и экраны.
Рисунок 1: Составные части из которых складывается сквозная задержка при передаче данных
Основной целью данного обзора является исследование влияния обоих протоколов – RTMP и SRT на величину сквозной задержки при передаче данных. Для достижения сопоставимых и объективных результатов в исследовании были использованы одни и те же устройства с одинаковыми настройками, единственное что менялось – это переключение между протоколами RTMP и SRT. В некоторых случаях, однако, конфигурацию пришлось изменять с целью обеспечения стабильного потока RTMP- данных, более подробно об этом будет объяснено далее.
Тестовая система
На следующем рисунке показана тестовая система, по которой проводилось исследование.
Рисунок 2 – Обзор тестовой системы (все компоненты)
Тестовая система специально была разработана в простом исполнении, чтобы эксперимент легко можно было повторить без специального дополнительного тестового оборудования. Неподвижная камера использовалась для захвата изображения двух рядом стоящих экранов, отображающих фотографию видеокадра и тайм-кода. Один из экранов был подключен напрямую к источнику, а другой – к выходу декодера, так чтобы можно было четко видеть сквозную задержку прохождения данных в направлении туда и обратно. Для того чтобы получить точный результат с помощью тестовой системы, источник и получатель данных должны находиться в одном и том же месте. Важно отметить, что для целей теста мы учитывали путь прохождения данных туда и обратно при определении сквозной задержки. Который включает в себя: кодирование видео сигнала, время необходимое потоку данных, чтобы дойти до определенного места назначения и вернуться обратно к месту отправки, декодирование видео сигнала и, наконец, задержка отображения на дисплее, буферизация данных в задействованных серверах, программных проигрывателях или аппаратных декодерах.
Источник
В качестве источника видеосигнала использовался видеорегистратор Blackmagic Hyperdeck Shuttle, непосредственно передающий данные на первый экран, при этом параллельно использовались энкодеры Haivision KB и Makito X. Видеосигнал передавался со встроенным тайм кодом, позволяющим идентифицировать каждый отдельный видеокадр. Видео воспроизводилось в разрешении 720p с 60 кадрами в секунду. Каждый отдельный кадр видео отображался в течение 16,67 миллисекунд.
Экраны
Чтобы была возможность получить фотографию, на которой непосредственно отображалось время, необходимое для кодирования, потоковой передачи и декодирования видео, использовалось несколько экранов. Чтобы быть уверенными, что экраны не отличаются друг от друга по временной задержке, все дисплеи были подключены к источнику видео параллельно, после чего была сделана пробная фотография. Все экраны показали одинаковый кадр в один и тот же момент времени. Этот тест был повторен с обоими экранами, подключенными в этот раз к ноутбуку, чтобы убедиться, что дисплей ноутбука не является более медленным или быстрым по временной задержке, чем используемые экраны.
Рисунок 3: Рядом стоящие экраны отображают видео напрямую с камеры и выходное видео с декодера (цифры на рисунке – временной код / задержка по времени)
Видео энкодер
Кодирование исходного видеосигнала осуществлялось с помощью энкодера Haivision KB (версия программного обеспечения 5.4), который способен генерировать RTMP и SRT- потоки видеоданных параллельно. Оба исходящих потока видеоданных имели одинаковые характеристики аудио и видео потоков. Различие в уровне битрейта были обусловлены индивидуальными издержками протоколов RTMP и SRT при формировании потока данных.
В ходе тестирования были использованы следующие настройки энкодера:
Общее значение битрейта исходящего потока составляло примерно 3 Мбит/с, включая издержки протоколов.
Дополнительно также использовались энкодер и декодер серии Makito X (версия программного обеспечения 5.4). Это устройства с аппаратным ускорением, которые обеспечивают значительно меньшую задержку сигнала по сравнению с программно реализованными энкодерами и декодерами. При этом, в энкодере и декодере Makito X использовались те же настройки, что и в программном энкодере серии KB.
Видео декодер
Поскольку возможность простого повторения эксперимента была ключевым фактором, в качестве программного декодера использовался видеоплеер VLC Player, один из наиболее распространенных видеоплееров как в корпоративном, так и в домашнем использовании. Чрезвычайно популярный и универсальный видеоплеер VLC Player декодирует множество форматов видео, включая RTMP и SRT потоки данных.
В нашем тесте использовался VLC Player со стандартными настройками. Стандартный уровень кэша в 250 миллисекунд работал в большинстве тестов, но в некоторых случаях его приходилось менять. Более подробно об этом можно прочитать в разделе: Временные метки, кэш и буферы.
Сервер Wowza
В качестве конечного места назначения для потоков RTMP использовался сервер Wowza Streaming Engine (Версия 4.7.5 – сборка 21763). Сервер Wowza Streaming Engine был размещен на объектах AWS, расположенных в тех же центрах обработки данных AWS, что и сетевые шлюзы Haivision Media Gateways, которые выступали в качестве конечного места назначения для потоков SRT. Декодер (VLC) принимал RTMP поток данных обратно в исходном месте из этого конкретного сервера.
Wowza Streaming Engine также поддерживает SRT протокол, но на момент тестирования в нем использовалась очень старая версия протокола, которая не обеспечивает весь потенциал текущей версии SRT протокола. Кроме того, во время тестирования в сервисе Streaming Cloud от Wowza не было реализации SRT протокола.
Время передачи данных туда и обратно Round Trip Time (RTT) до сервера Wowza и до шлюза Haivision Media Gateway, размещенного в одном и том же центре обработки данных AWS, никогда не отличалось более чем на 2 миллисекунды. В большинстве тестов общее время передачи данных RTT был одинаковым.
Сервер Haivision Media Gateway
Подобно RTMP потокам, в качестве конечной точки для SRT потоков использовался сетевой шлюз Haivision Media Gateway (версия 3.0.1), размещенный на объектах AWS.
В рамках системы AWS, сетевой шлюз Haivision Media Gateway доступен как программное обеспечение, а также как дополнительная услуга и может быть запущен в дата-центрах AWS по вашему выбору.
Вход и выход для SRT потоков были сконфигурированы как SRT порты с определенным буфером задержки. Размер этого буфера зависит от времени передачи данных RTT до места назначения. Более подробную информацию об этом можно найти в разделе Временные метки, Кэш и Буферы.
Интернет соединение
Интернет соединение было установлено с помощью DSL-модема Fritzbox 7590 со скоростью 100 Мбит/с для входящих данных и 42 Мбит/с – для исходящих. Параметры соединения постоянно отслеживались, чтобы гарантировать отсутствие влияния других приложений на перегрузку линии связи.
Временные метки, кэш и буферы
Рисунок 4: Характеристики входного сигнала не соответствуют характеристикам передачи по сети
Основное различие между RTMP и SRT протоколами заключается в отсутствии временных меток в заголовках пакетов данных в RTMP протоколе. RTMP протокол содержит только временные метки фактического потока данных в соответствии с его частотой кадров. Отдельные пакеты не содержат эту информацию, поэтому получатель RTMP данных должен отправлять каждый полученный пакет в течение фиксированного интервала времени в процессе декодирования. Чтобы сгладить разницу во времени необходимую для перемещения отдельных пакетов данных, требуются большие объемы буферов данных.
SRT протокол, с другой стороны, включает временные метки для каждого отдельного пакета данных. Это позволяет воссоздать характеристики сигнала на стороне приемника и значительно снижает потребность в буферизации. Другими словами, поток битов данных, покидающий приемник выглядит точно так же как поток, поступающий в SRT-отправитель.
Рисунок 5: Восстановление характеристик сигнала на стороне приемника SRT потока
Другим существенным отличием между RTMP и SRT протоколами является реализация повторной передачи пакетов данных. RTMP протокол основан на TCP протоколе, который основан на подтверждениях о приеме данных, отправленных получателем. Однако эти подтверждения (ACK) не уходят отправителю немедленно, чтобы экономить обратный трафик и поддерживать его на низком уровне. Только после того, как определенная последовательность пакетов данных будет получена, отчет о подтверждениях (ACK) или отрицательных подтверждениях (NACK) будет отправлен обратно. Если в этой последовательности будут потерянные пакеты данных, тогда полная последовательность пакетов данных (до последнего ACK) будет передана повторно.
С другой стороны, SRT протокол может идентифицировать отдельный потерянный пакет данных по его порядковому номеру. Если разница порядковых номеров больше чем один пакет, запускается повторная передача этого пакета. В данном случае только этот конкретный пакет данных отправляется снова, чтобы задержка по времени и издержки были минимальными. Согласно форуму Wowza Forums размер буфера рассчитывается следующим образом:
«Большой объем буфера отправки и буфера приема обеспечит лучшую пропускную способность в соединениях, где наблюдается большая задержка по времени (с высоким временем пинга). Уровень возможной пропускной способности соединения в байтах/секунду должен быть меньше отношения размера буфера ко времени прохождения данных туда и обратно (buffer size/RTT). Размер буфера определяет какое количество данных может быть отправлено до того момента, когда отправляющая сторона должна остановиться и дождаться ответа от принимающей стороны. Размер, используемый для соединения будет меньше размера буфера отправки у отправителя или буфера приема у получателя. Как правило, большинство современных клиентов используют автоматические настройки, поэтому буфер отправки на сервере Wowza может ограничивать скорость соединения для соединений с высоким уровнем задержки. По умолчанию Wowza использует значение в 65000 байтов для буфера отправки, которое является оптимальным средним значением.
Это обеспечит следующие показатели производительности:
65000 байт / 50 мс (RTT) = 1300000 байт/сек = 10.4 Мбит/с
65000 / 100 мс = 5.2 Мбит/с
65000 / 200 мс = 2.6 Мбит/с
Как видите, чем дальше находится клиентский видеоплеер, тем меньшая пропускная способность передачи потока видеоданных будет у вашего сервера. Если ваш видеоплеер расположен не очень далеко, настройки по умолчанию должны хорошо подойти как для потока данных, так и для видеоплеера, которые вы описали. Но вы можете серьезно ограничить пропускную способность, если установите ей слишком низкое значение.
Настройки с низкой задержкой предназначены для тех случаев, когда видеоплеер находится очень близко к серверу или уровень битрейта у потока данных очень низкий.
16000 байт / 50 мс (RTT) = 320000 байт/сек = 2.56 Мбит/с
16000 / 100 мс = 1.28 Мбит/с
16000 / 200 мс = 640 Кбит/с
Размеры принимающих буферов на сервере Wowza обычно влияют только на потоковую передачу видео в режиме LIVE, поэтому их следует настроить таким образом, чтобы ваши энкодеры имели достаточный запас по пропускной способности. Если вы установите слишком большие размеры буферов, вы можете столкнуться с проблемами, когда возникнет перегрузка, поскольку серверу потребуется больше времени, чтобы обнаружить и внести коррективы для преодоления возникшей ситуации. По этой причине вам не следует устанавливать эти значения слишком большими. Если вы приблизительно знаете, как далеко находятся ваши клиентские видеоплееры и источник видео, вам будет лучше использовать ручные настройки ».
В заключение: если вы не знаете, как далеко вы находитесь от точки приема (с точки зрения времени прохождения данных туда и обратно RTT), и вы не уверены в характеристиках вашего соединения – используйте SRT протокол.
В проведенных тестах там где это было возможно использовался размер буфера данных по умолчанию – 65 000 байт. Однако при отправке потока данных в Австралию, где время прохождения данных туда и обратно составляет 360 мс, размер буфера был увеличен до 260 000 байт с целью достижения стабильности передаваемого потока данных
Результаты теста на задержку по времени
Протоколы RTMP и SRT сравнение задержки по времени и времени прохождения данных RTT
Рисунок 6: Результаты теста на определение задержки по времени при передачи данных туда и обратно
Как и ожидалось, чем больше расстояние проходят данные до места назначения, тем больше величина сквозной задержки. Важно отметить, что эти числа являются абсолютными значениями, которые включают в себя задержку при кодировании, передаче данных, декодировании и в устройствах отображения. Следует отметить, что значение задержки указано при передаче данных в оба направления – туда и обратно, например из Германии в Австралию и обратно в Германию.
Таблица 2: Результаты теста на определение задержки по времени
Результаты теста на задержку по времени в детальном рассмотрении
Рисунок 7: Программное кодирование / декодирование – тестовая система с программным энкодером KB и декодером VLC
Чем дальше от вас находится место назначения, тем больше времени потребуется потоку данных, чтобы туда добраться. Таким образом, неудивительно, что передача данных с одной стороны земного шара на другую, в данном случае – из Германии в Австралии, заняла больше всего времени.
Германия – Сидней – Германия
Чтобы обеспечить доставку стабильного потока видео и аудио в Сидней из Германии с помощью RTMP протокола, размер буфера приемника на сервере Wowza Streaming Engine пришлось увеличить до 260 000 байтов. Это в четыре раза больше, чем его объем по умолчанию – 65 000 байтов. Так как в основе теста лежала передача данных туда и обратно, принимающий буфер VLC Player также пришлось увеличить с 250 мс (значение по умолчанию) до 2000 мс. Ниже этих значений качество передаваемого потока значительно ухудшалось из-за аудио и видео артефактов или даже не воспроизводилось вообще.
Германия – Калифорния – Германия
Хотя время прохождения потоком данных пути в Калифорнию туда и обратно было приблизительно равно половине такого же времени при передаче данных в Австралию, не только это время влияет на итоговую величину задержку. Поток данных обратно в Германию казалось испытывал сильный джиттер, что привело к отклонению доставки индивидуальных пакетов данных во времени. Хотя передача данных из Германии в Калифорнию работала без перебоев с использованием размера буфера по умолчанию – 65 000 байт, обратный путь потребовал увеличение буферизации до 650 мс в проигрывателе VLC Player.
Германия – Вирджиния – Германия
Несколько удивительно, результаты теста показали, что время передачи данных до места назначения в Вирджинии было всего немного большим (менее 3 кадров или 50 мс) чем до Калифорнии, несмотря на то, что географически на карте это явно более короткое расстояние от Германии. Отсюда можно сделать вывод, что кратчайший географический путь не всегда может быть самым быстрым. Данные перемещаются со скоростью света между дата-центрами и их маршрутизаторами.
В зависимости от использования пропускной способности каналов передачи данных, ваш видеосигнал может не всегда проходить по кратчайшему интернет-пути, но быстрее, чем по прямому географическому маршруту. Хотя время передачи данных до места назначения было незначительно выше, чем в калифорнийском тесте, связь была более стабильной с меньшим джиттером и позволяла использовать меньшие объемы буферов для RTMP потоков. В этом случае видеопоток был стабильным со стандартными значениями по умолчанию – объемом буфера в 65000 байт на сервере Wowza Streaming Engine и 250 мс для проигрывателя VLC Player.
Тюрингия – Франкфурт – Тюрингия
В тесте при отправке потока данных из Тюрингии в Германии в датацентр AWS во Франкфурте, время передачи данных до места назначения и обратно (RTT) составило всего 17 мс. Задержка по времени при передаче RTMP данных туда и обратно не сильно уменьшилась по сравнению с результатами для Вирджинии или Калифорнии. Однако протокол SRT смог выиграть более одной секунды при меньшем значении времени передачи данных до пункта назначения (RTT) по сравнению с местоположениями в США.
В этих тестах, SRT протокол был в 2,5-3,2 раза быстрее по сравнению с RTMP протоколом
Рисунок 8: Результаты теста на определение задержки по времени при передаче данных туда и обратно с использованием программного энкодера и декодера
Сравнение аппаратного и программного кодирования
Рисунок 9: Тестовая система с использованием аппаратных энкодеров и декодеров Makito X
До сих пор мы исследовали программное кодирование и декодирование, и даже самые быстрые результаты, достигнутые с помощью SRT протокола были все еще выше 1,5 секунд. Для случаев, когда задержка по времени является критическим параметром, 1,5 секунды намного превышает желаемое порогового значение при взаимодействии разнонаправленных потоков данных, например при организации прямых трансляций двусторонних интервью
Задержка заметна во время прямой трансляции новостей, например когда репортер в США дает интервью европейскому телеканалу с использованием спутниковой линии связи. Любые задержки между заданным вопросом и предоставленным ответом всегда заметны. Как правило, интервьюируемые предварительно обучаются и часто знают задаваемый вопрос заранее, поэтому они начнут отвечать еще до того, как другая сторона закончит задавать вопрос. Однако с задержкой в 1,5 секунды задержка будет чрезвычайно высокой.
Хотя SRT протокол помогает значительно снизить задержку при передаче данных, аппаратные энкодеры и декодеры, такие как Haivision Makito X Series, также способны ускорить процессы кодирования и декодирования видео. В следующей таблице показаны результаты теста на определение задержки по времени при передаче данных и кодировании с помощью программного энкодера Haivision KB и видеоплеера VLC Player (передача данных по RTMP и SRT протоколам) по сравнению с аппаратным энкодером и декодером Haivision Makito X (передача данных по SRT протоколу).
Результаты с использованием энкодера и декодера Makito X с SRT протоколом показывают существенную разницу. Двусторонняя сквозная задержка в Австралию и обратно уменьшается с 9,6 секунды до 1,6 секунды при использовании выделенного аппаратного кодирования и декодирования. В Германии результат составляет всего 333 миллисекунды для SRT протокола, в то время как для RTMP протокола в программном исполнении требуется 4,1 секунды. Это в 12 раз быстрее и может рассматриваться как сверхнизкая задержка по времени.
Сравнение максимальной скорости передачи потоков по протоколу RTMP и SRT
Результаты теста показывают, что SRT протокол оказывает существенное влияние на снижение задержки по времени при передаче видео. Но как насчет его влияния на качество видео? Простой способ улучшить качество видео и аудио – просто увеличить скорость потоков видео (битрейт). Но каково значение максимальной скорости при передаче потоков на большие расстояния и как далеко вы можете передать видеопоток с высокой скоростью?
Тестовая система для определении максимальной скорости потоков
Рисунок 11: Тестовая система для определения максимальной скорости потоков
Чтобы протестировать скорость передачи потоков, мы выбрали место с отличным интернет-соединением – Microsoft Production Studios в Редмонде, штат Вашингтон. Следующий крупный интернет-узел находится всего в 2 шагах, и все подключенные устройства имели скорость соединения 1 Гбит/с с интернетом.
Учитывая, что сохранение низкого значения задержки являлось ключевым фокусом тестирования, настройки буфера оставались неизменными при увеличении скорости передачи во время тестов. Размеры буфера были протестированы при скорости 2 Мбит/с. Как только поток стал стабильным, тесты проводились с использованием скоростей 1, 2, 6, 10 и 20 Мбит/с.
Поток видео с энкодера Haivision KB 5.4 был отправлен на сетевой шлюз Haivision Media Gateway в центр обработки данных AWS в Калифорнии и Северной Вирджинии в США, во Франкфурт в Германии и в Сидней. Чтобы оценить качество видео, поток был отправлен обратно в Редмонд по SRT протоколу и воспроизведен на телевизионной приставке Haivision Play 2000 Set Top Box.
Результаты теста на определение максимальной скорости потока
Результаты теста убедительны. SRT протокол не испытывал проблем с потоковой передачей до 20 Мбит/с в любой регион мира. RTMP протокол хорошо работал когда отправитель и получатель находились на одном континенте, в данном случае в Северной Америке. Из Редмонда можно было отправлять потоки видео со скоростью до 20 Мбит/с по протоколу RTMP в Калифорнию или Вирджинию. Однако потоковая передача видео в Европу и Австралию была невозможна при скорости передачи выше 2 Мбит/с. С SRT протоколом были бы возможны даже более высокие скорости, но поскольку RTMP поток уже вышел из строя на больших расстояниях при более низком уровне битрейта, скорость в 20 Мбит/с была хорошим верхним пределом для этого теста.
RTMP И SRT – Как далеко можно передать видео через Интернет?
Рисунок 12: Результаты теста на скорость передачи потоков
Заключение
С точки зрения сквозной задержки по времени и максимальной скорости потоков (битрейта), SRT протокол намного превосходит RTMP. Хотя эти тесты могли быть проведены также и в лабораторной среде с использованием инструментов для моделирования ситуации с потерей пакетов данных и большим джиттером, мы намеренно решили выполнять их в реальных условиях с помощью публичного интернета. Реальные условия трудно воспроизвести в лаборатории, и они всегда будут приблизительными.
Заглядывая в будущее, в скором времени на горизонте появится новая инновация от Haivision – SRT Hub, которая предложит альтернативу потоковой передаче видео через публичный интернет. SRT Hub, работающий на базе SRT протокола, представляет собой облачный сервис маршрутизации, который использует масштабируемость и охват глобальной сети Microsoft Azure. Это сведет к минимуму количество переходных транзитных участков при передаче потоков видео через публичный интернет, что в свою очередь приведет к еще большему снижению задержки по времени.
p.s. Именно протокол SRT мы используем для проведения телемостов и онлайн-трансляций.
update. Источник материала – Сообщество Avstream, которым мы выражаем безграничный респект 🙂