Rtmp что это такое

¶ Стриминг в реальном времени

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

¶ Допустимая задержка

¶ Рабочий процесс

На рисунке ниже показан путь от камеры до зрителя, режиссера (на микшере) и оператора (если камера управляется удаленно через веб-инструменты. Это частный случай, в общем можно назвать больше протоколов и вариантов управления. Но рассмотрим именно его, тем более, что он реализован в МИЭМе.

Viewer does not support full SVG 1.1

Каждый этап задействует свои протоколы. В этот раз рассмотрим получение потоков с источников (здесь это камера) и передачу выходного потока (эфирной программы) на стриминговую платформу. В качестве такой платформы по умолчанию в этом курсе будем рассматривать Youtube, но на его месте может быть и VK, OK, Facebook, Twitch и т.д. Можно запустить и собственный сервер. Обобщенно всё стриминговое производство описывается так:

Viewer does not support full SVG 1.1

¶ RTMP vs RTSP

RTSP — Real-Time Streaming Protocol. 1998

RTMP — Real-Time Messaging Protocol. 2009, но использовался ранее

В нашем частном (!) случае мы рассматриваем в качестве источников RTSP устройства: это камеры, кодеры или программные серверы потоков RTSP.

То есть, RTSP-камеры бесполезны, если мы не можем «достучаться» до них по сети. Например, если такая камера находится в локальной сети, снаружи она доступна только если:

Источник

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 имеет несколько разновидностей:

СОДЕРЖАНИЕ

Основная операция

Шифрование

Сессии RTMP могут быть зашифрованы одним из двух методов:

HTTP-туннелирование

Протокол работает, отправляя команды через URL-адрес POST и сообщения AMF через тело POST. Примером является

для открытия соединения.

Спецификация и патентная лицензия

Патенты и связанные с ними судебные разбирательства

Стефан Рихтер, автор нескольких книг по Flash, в 2008 году отметил, что, хотя Adobe нечетко определяет, какие патенты применяются к RTMP, Патент США 7 246 356, по- видимому, является одним из них.

В 2011 году Adobe подала в суд на Wowza Media Systems, заявив, среди прочего, о нарушении их патентов на RTMP. В 2015 году Adobe и Wowza объявили, что иски были урегулированы и отклонены с предубеждением.

Структура пакета

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

это сгенерирует следующий чанк:

Последний тип (b11) всегда используется в случае агрегированных сообщений, где в приведенном выше примере второе сообщение будет начинаться с идентификатора 0xC3 (b11000011) и будет означать, что все поля заголовка сообщения должны быть получены из сообщения с идентификатор потока 3 (это будет сообщение прямо над ним). Шесть младших битов, образующих идентификатор потока, могут принимать значения от 3 до 63. Некоторые значения имеют особое значение, например 1, обозначающее расширенный формат идентификатора, и в этом случае за ним идут два байта. Значение два предназначено для сообщений низкого уровня, таких как Ping и Set Client Bandwidth.

Следующие байты заголовка RTMP (включая значения в приведенном выше примере пакета) декодируются следующим образом:

Байт идентификатора типа сообщения определяет, содержит ли пакет аудио / видеоданные, удаленный объект или команду. Вот некоторые возможные значения:

Вызов структуры сообщения (0x14, 0x11)

Некоторые из типов сообщений, показанных выше, такие как Ping и Set Client / Server Bandwidth, считаются сообщениями протокола RTMP низкого уровня, которые не используют формат кодирования AMF. С другой стороны, командные сообщения, будь то AMF0 (тип сообщения 0x14) или AMF3 (0x11), используют формат и имеют общую форму, показанную ниже:

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

Структура управляющего сообщения (0x04)

Управляющие сообщения не кодируются AMF. Они начинаются с идентификатора потока 0x02, что подразумевает полный заголовок (тип 0) и имеет тип сообщения 0x04. За заголовком следуют шесть байтов, которые интерпретируются как таковые:

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

Структура сообщения ServerBw / ClientBw (0x05, 0x06)

Это относится к сообщениям, которые связаны с битрейтом восходящего потока клиента и нисходящего потока сервера. Тело состоит из четырех байтов, показывающих значение полосы пропускания с возможным расширением на один байт, который устанавливает тип ограничения. Он может иметь одно из трех возможных значений: жесткий, мягкий или динамический (мягкий или жесткий).

Установить размер блока (0x01)

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

Протокол

Рукопожатие

После установления TCP-соединения сначала устанавливается RTMP-соединение, выполняя рукопожатие посредством обмена тремя пакетами с каждой стороны (также называемых Chunks в официальной документации). В официальной спецификации они обозначаются как C0-2 для пакетов, отправленных клиентом, и S0-2 для стороны сервера соответственно, и их не следует путать с пакетами RTMP, которыми можно обмениваться только после завершения рукопожатия. Эти пакеты имеют собственную структуру, а C1 содержит поле, устанавливающее временную метку «эпохи», но поскольку это может быть установлено на ноль, как это сделано в реализациях сторонних производителей, пакет можно упростить. Клиент инициализирует соединение, отправляя пакет C0 с постоянным значением 0x03, представляющим текущую версию протокола. Он следует прямо с C1, не дожидаясь получения S0 первым, который содержит 1536 байтов, причем первые четыре представляют временную метку эпохи, вторые четыре все равны 0, а остальные являются случайными (и которые могут быть установлены на 0 в третьей стороне. реализации). C2 и S2 являются эхо-сигналом S1 и C1 соответственно, за исключением того, что вторые четыре байта являются временем получения соответствующего сообщения (вместо 0). После получения C2 и S2 рукопожатие считается завершенным.

Соединять

Некоторые из приведенных выше значений сериализованы в свойства универсального объекта Action-script, который затем передается прослушивателю событий NetConnection. clientId Установит номер для сессии, которая началась в связи. Кодировка объекта должна соответствовать ранее установленному значению.

Проиграть видео

Чтобы запустить видеопоток, клиент отправляет вызов createStream, за которым следует сообщение ping, за которым следует вызов play с именем файла в качестве аргумента. Затем сервер ответит серией команд onStatus, за которыми следуют видеоданные, инкапсулированные в сообщениях RTMP.

После установления соединения медиафайлы отправляются путем инкапсуляции содержимого тегов FLV в сообщения RTMP типа 8 и 9 для аудио и видео соответственно.

HTTP-туннелирование (RTMPT)

Это относится к версии протокола с туннелированием HTTP. Он обменивается данными через порт 80 и передает данные AMF внутри запроса и ответов HTTP POST. Последовательность подключения следующая:

У первого запроса есть /fcs/ident2 путь, и правильным ответом является ошибка 404 Not Found. Затем клиент отправляет запрос / open / 1, в котором сервер должен ответить сообщением 200 ok, добавив случайное число, которое будет использоваться в качестве идентификатора сеанса для указанного сообщения. В этом примере в теле ответа возвращается 1728724019.

Программные реализации

RTMP реализуется на трех этапах:

rtmpdump

Пакеты программного обеспечения rtmpdump доступны в основных репозиториях с открытым исходным кодом (дистрибутивы Linux). К ним относятся интерфейсные приложения «rtmpdump», «rtmpsrv» и «rtmpsuck».

FLVstreamer

Источник