Протокол обмена сообщениями в реальном времени
Протокол обмена сообщениями в реальном времени ( RTMP ) — это протокол связи для потоковой передачи аудио, видео и данных через Интернет. Первоначально разработанный Macromedia как протокол собственный . для потоковой передачи между Flash Player и Flash Communication Server, компания Adobe (которая приобрела Macromedia) выпустила неполную версию спецификации протокола для публичного использования
Протокол RTMP имеет несколько вариантов:
- Собственно RTMP, «простой» протокол, который работает поверх протокола управления передачей (TCP) и по умолчанию использует номер порта 1935.
- RTMPS, который представляет собой RTMP через соединение Transport Layer Security (TLS/SSL).
- RTMPE, который зашифрован по протоколу RTMP с использованием собственного механизма безопасности Adobe. Хотя детали реализации являются собственностью компании, в механизме используются стандартные криптографические примитивы. [1]
- RTMPT, который инкапсулируется в HTTP- запросы для прохождения межсетевых экранов . RTMPT часто использует запросы открытого текста на TCP- портах 80 и 443 для обхода большей части фильтрации корпоративного трафика. Инкапсулированный сеанс может содержать в себе простые пакеты RTMP, RTMPS или RTMPE.
- RTMFP, который представляет собой RTMP через протокол пользовательских датаграмм (UDP) вместо TCP, заменяющий поток фрагментов RTMP. Пакет протоколов Secure Real-Time Media Flow Protocol был разработан Adobe Systems и позволяет конечным пользователям подключаться и общаться напрямую друг с другом (P2P).
Хотя основной мотивацией для RTMP было создание протокола для воспроизведения Flash-видео , он также используется в некоторых других приложениях, таких как Adobe LiveCycle Data Services ES .
Основная операция
[ редактировать ]RTMP — это протокол на основе TCP, который поддерживает постоянные соединения и обеспечивает связь с малой задержкой. Чтобы обеспечить бесперебойную доставку потоков и передать как можно больше информации, потоки разбиваются на фрагменты, а их размер динамически согласовывается между клиентом и сервером. Иногда его оставляют без изменений; размеры фрагментов по умолчанию составляют 64 байта для аудиоданных и 128 байтов для видеоданных и большинства других типов данных. Затем фрагменты из разных потоков могут чередоваться и мультиплексироваться по одному соединению. Таким образом, при более длинных фрагментах данных протокол несет только однобайтовый заголовок на фрагмент, что приводит к очень небольшим накладным расходам . Однако на практике отдельные фрагменты обычно не чередуются. Вместо этого чередование и мультиплексирование выполняются на уровне пакетов, при этом пакеты RTMP по нескольким различным активным каналам чередуются таким образом, чтобы гарантировать, что каждый канал соответствует своей полосе пропускания, задержке и другим требованиям качества обслуживания. Пакеты, чередующиеся таким образом, рассматриваются как неделимые и не чередуются на уровне фрагментов.
RTMP определяет несколько виртуальных каналов, по которым могут отправляться и получаться пакеты и которые работают независимо друг от друга. Например, есть канал для обработки запросов и ответов RPC, канал для данных видеопотока, канал для данных аудиопотока, канал для внеполосных управляющих сообщений (согласование размера фрагмента и т. д.) и так далее. . Во время типичного сеанса RTMP несколько каналов могут быть активны одновременно в любой момент времени. При кодировании данных RTMP генерируется заголовок пакета. Заголовок пакета, помимо прочего, определяет идентификатор канала, по которому он должен быть отправлен, временную метку его создания (при необходимости) и размер полезной нагрузки пакета. Затем за этим заголовком следует фактическое содержимое полезной нагрузки пакета, который перед отправкой по соединению фрагментируется в соответствии с согласованным на данный момент размером фрагмента. Сам заголовок пакета никогда не фрагментируется, и его размер не учитывается при расчете данных в первом фрагменте пакета. Другими словами, фрагментации подвергается только фактическая полезная нагрузка пакета (медиаданные).
На более высоком уровне RTMP инкапсулирует аудиопотоки MP3 или AAC и видео-мультимедийные потоки FLV1 и может выполнять удаленные вызовы процедур (RPC), используя формат сообщения действия . Любые необходимые службы RPC выполняются асинхронно с использованием единой модели запроса/ответа клиент/сервер, поэтому связь в реальном времени не требуется. [ нужны разъяснения ] [2] [3]
Шифрование
[ редактировать ]Сеансы RTMP могут быть зашифрованы одним из двух методов:
- Использование стандартных механизмов TLS/SSL . Базовый сеанс RTMP просто оборачивается внутри обычного сеанса TLS/SSL.
- Использование RTMPE, который оборачивает сеанс RTMP в более легкий уровень шифрования.
HTTP-туннелирование
[ редактировать ]В режиме RTMP Tunneled (RTMPT) данные RTMP инкапсулируются и обмениваются через HTTP , а сообщения от клиента (в данном случае медиаплеера) адресуются на порт 80 (по умолчанию для HTTP) на сервере.
Хотя сообщения в RTMPT больше, чем эквивалентные нетуннелируемые сообщения RTMP из-за заголовков HTTP, RTMPT может облегчить использование RTMP в сценариях, где в противном случае использование нетуннелируемого RTMP было бы невозможно, например, когда клиент находится позади брандмауэр , который блокирует исходящий трафик, отличный от HTTP и HTTPS.
Протокол работает, отправляя команды через URL-адрес POST и сообщения AMF через тело POST. Примером является
POST /open/1 HTTP/1.1
для открытия соединения.
Спецификация и патентная лицензия
[ редактировать ]Adobe выпустила спецификацию протокола версии 1.0 от 21 декабря 2012 года. [4] На целевой веб-странице, ведущей к этой спецификации, отмечается: «Чтобы помочь клиентам, которые хотят защитить свой контент, открытая спецификация RTMP не включает уникальные меры безопасности RTMP от Adobe». [5]
Документ, сопровождающий спецификацию Adobe, предоставляет «неисключительную, безвозмездную, непередаваемую, не подлежащую сублицензированию, персональную, всемирную» патентную лицензию на все реализации протокола с двумя ограничениями: первое запрещает использование для перехвата потоковых данных («любая технология который перехватывает потоковое видео, аудио и/или данные для хранения на любом устройстве или носителе»), а другой запрещает обход «технологических мер по защите аудио, видео и/или данных, включая любые меры безопасности Adobe RTMP». . [6]
Патенты и связанные с ними судебные разбирательства
[ редактировать ]Стефан Рихтер, автор нескольких книг по Flash , отметил в 2008 году, что, хотя Adobe неясно, какие патенты применимы к RTMP, патент США 7 246 356, по-видимому, является одним из них. [2]
В 2011 году Adobe подала в суд на Wowza Media Systems, заявив, среди прочего, о нарушении их патентов RTMP. [7] [8] [9] В 2015 году Adobe и Wowza объявили, что иски урегулированы и отклонены с предубеждением. [10]
Структура пакета
[ редактировать ]Пакеты передаются через TCP-соединение, которое сначала устанавливается между клиентом и сервером. Они содержат заголовок и тело, которое в случае команд подключения и управления кодируется с использованием формата сообщения действия (AMF). Заголовок разделен на базовый заголовок (показанный на диаграмме как отдельный от остальных) и заголовок фрагмента сообщения . Базовый заголовок является единственной постоянной частью пакета и обычно состоит из одного составного байта, где два старших бита — это тип фрагмента ( fmt в спецификации), а остальные образуют идентификатор потока. В зависимости от значения первого некоторые поля заголовка сообщения могут быть опущены, а их значение получено из предыдущих пакетов, тогда как в зависимости от значения последнего базовый заголовок может быть расширен одним или двумя дополнительными байтами (как в случай диаграммы, имеющей всего три байта (c)). Если значение остальных шести бит базового заголовка (BH) (наименее значимого) равно 0, тогда BH составляет два байта и представляет идентификатор потока от 64 до 319 (64+255); если значение равно 1, то BH составляет три байта (последние два байта закодированы как 16-битный Little Endian) и представляет собой идентификатор потока от 64 до 65599 (64+65535); если значение равно 2, то BH составляет один байт и зарезервирован для сообщений и команд управления протоколом низкого уровня. Заголовок сообщения фрагмента содержит метаданные, такие как размер сообщения (измеряется в байтах), Разница временной метки и тип сообщения . Это последнее значение представляет собой один байт и определяет, является ли пакет аудио, видео, командным пакетом или пакетом RTMP «низкого уровня», например RTMP Ping.
Ниже показан пример, зафиксированный, когда флэш-клиент выполняет следующий код:
var stream:NetStream = new NetStream(connectionObject);
это создаст следующий чанк:
Шестнадцатеричный код | ASCII-код |
---|---|
03 00 0B 68 00 00 19 14 00 00 00 00 02 00 0C 63 72 65 61 74 65 53 74 72 65 61 6D 00 40 00 00 00 00 00 00 00 05
|
␃ ␀ @ I ␀ ␀ ␙ ␔ ␀ ␀ ␀ ␀ ␂ ␀ ␌ c r e a t e S t r e a m ␀ @ ␀ ␀ ␀ ␀ ␀ ␀ ␀ ␅
|
Пакет начинается с базового заголовка , состоящего из одного байта (0x03), где два старших бита (b 00 000011) определяют тип заголовка фрагмента, равный 0, а остальные (b00 000011 ) определяют идентификатор потока фрагмента, равный 3. Четыре возможных значения типа заголовка и их значение:
- b00 = 12-байтовый заголовок (полный заголовок).
- b01 = 8 байт – аналогично типу b00, без учета идентификатора сообщения (4 последних байта).
- b10 = 4 байта — включены базовый заголовок и временная метка (3 байта).
- b11 = 1 байт – включается только базовый заголовок.
Последний тип (b11) всегда используется в случае агрегированных сообщений, где в приведенном выше примере второе сообщение начинается с идентификатора 0xC3 (b11000011) и означает, что все поля заголовка сообщения должны быть получены из сообщения с идентификатор потока, равный 3 (это будет сообщение прямо над ним). Шесть младших битов, образующих идентификатор потока, могут принимать значения от 3 до 63. Некоторые значения имеют особое значение, например 1, обозначающее расширенный формат идентификатора, и в этом случае за ним следуют два байта. Значение два предназначено для сообщений низкого уровня, таких как Ping и Set Client Bandwidth.
Следующие байты заголовка RTMP (включая значения в приведенном выше примере пакета) декодируются следующим образом:
- байт №1 (0x03) = тип заголовка чанка.
- байты № 2–4 (0x000b68) = дельта метки времени.
- байты № 5–7 (0x000019) = длина пакета — в данном случае это 0x000019 = 25 байт.
- байт № 8 (0x14) = идентификатор типа сообщения — 0x14 (20) определяет командное сообщение в кодировке AMF0.
- байты № 9–12 (0x00000000) = идентификатор потока сообщений. Это в прямом порядке.
Байт идентификатора типа сообщения определяет, содержит ли пакет аудио/видео данные, удаленный объект или команду. Некоторые возможные значения:
- 0x01 = сообщение установки размера пакета.
- 0x02 = Прервать.
- 0x03 = Подтверждение.
- 0x04 = Управляющее сообщение.
- 0x05 = Пропускная способность сервера
- 0x06 = Пропускная способность клиента.
- 0x07 = Виртуальное управление.
- 0x08 = аудиопакет.
- 0x09 = Видеопакет.
- 0x0F = данные расширены.
- 0x10 = Контейнер расширен.
- 0x11 = расширенная команда (команда типа AMF3).
- 0x12 = Данные (Вызов (информация onMetaData отправляется как таковая)).
- 0x13 = Контейнер.
- 0x14 = Команда (команда типа AMF0).
- 0x15 = UDP
- 0x16 = совокупный
- 0x17 = Присутствует
После заголовка 0x02 обозначает строку размером 0x000C и значениями 0x63, 0x72...0x6D (команда «createStream»). После этого у нас есть 0x00 (число), которое является идентификатором транзакции со значением 2.0. Последний байт — 0x05 (ноль), что означает отсутствие аргументов.
Структура сообщения вызова (0x14, 0x11)
[ редактировать ]Некоторые из типов сообщений, показанных выше, таких как Ping и Set Client/Server Bandwidth, считаются сообщениями протокола RTMP низкого уровня, которые не используют формат кодирования AMF. С другой стороны, командные сообщения, будь то AMF0 (тип сообщения 0x14) или AMF3 (0x11), используют формат и имеют общую форму, показанную ниже:
(String) <Command Name> (Number) <Transaction Id> (Mixed) <Argument> ex. Null, String, Object: {key1:value1, key2:value2 ... }
Идентификатор транзакции используется для команд, на которые может быть получен ответ. Значением может быть либо строка, как в примере выше, либо один или несколько объектов, каждый из которых состоит из набора пар ключ/значение, где ключи всегда кодируются как строки, а значения могут быть любым типом данных AMF, включая сложные типы, такие как массивы.
Структура управляющего сообщения (0x04)
[ редактировать ]Управляющие сообщения не кодируются в формате AMF. Они начинаются с идентификатора потока 0x02, что подразумевает полный заголовок (тип 0), и имеют тип сообщения 0x04. За заголовком следуют шесть байтов, которые интерпретируются следующим образом:
- #0-1 – Тип управления.
- #2-3 — Второй параметр (имеет значение для определенных типов управления)
- № 4-5 — Третий параметр (тот же)
Первые два байта тела сообщения определяют тип Ping, который, очевидно, может [11] принять шесть возможных значений.
- Тип 0 — Очистить поток: отправляется, когда соединение установлено, и не несет дополнительных данных.
- Тип 1 — Очистить буфер.
- Тип 2 – Сухой поток.
- Тип 3 — буферное время клиента. Третий параметр содержит значение в миллисекундах.
- Тип 4 — Сбросить поток.
- Тип 6 — Пинг клиента с сервера. Второй параметр — текущее время.
- Тип 7 — ответ Pong от клиента. Второй параметр — это время, когда клиент получает пинг.
- Тип 8 — UDP-запрос.
- Тип 9 — UDP-ответ.
- Тип 10 — Ограничение пропускной способности.
- Тип 11 — Пропускная способность.
- Тип 12 — Полоса пропускания дроссельной заслонки.
- Тип 13 — Поток создан.
- Тип 14 — поток удален.
- Тип 15 — Установить доступ для чтения.
- Тип 16 — установите доступ для записи.
- Тип 17 — Мета-запрос потока.
- Тип 18 — мета-ответ потока.
- Введите 19 — Получить границу сегмента.
- Тип 20 — Установить границу сегмента.
- Тип 21 — при отключении.
- Тип 22 — Установить критическую ссылку.
- Тип 23 – Отключить.
- Тип 24 — Обновление хеша.
- Тип 25 — Тайм-аут хеширования.
- Тип 26 — Хэш-запрос.
- Тип 27 — Хэш-ответ.
- Введите 28 — проверьте пропускную способность.
- Введите 29 — установите доступ к аудиосэмплам.
- Введите 30 — установите доступ к образцам видео.
- Тип 31 — Начало дроссельной заслонки.
- Тип 32 — Дроссельная часть.
- Тип 33 — Уведомление DRM.
- Тип 34 — Синхронизация RTMFP.
- Тип 35 — Запрос IHello.
- Тип 36 — Переслать привет.
- Тип 37 — перенаправить IHello.
- Тип 38 — Уведомить EOF.
- Введите 39 — Прокси-продолжение.
- Тип 40 — удаление прокси вверх по течению.
- Тип 41 — набор сообщений поддержки активности RTMFP.
- Тип 46 — сегмент не найден.
Pong — это название ответа на Ping, значения которого указаны выше.
Структура сообщения ServerBw/ClientBw (0x05, 0x06)
[ редактировать ]Это относится к сообщениям, которые связаны со скоростью передачи данных в восходящем потоке клиента и нисходящем потоке сервера. Тело состоит из четырех байтов, показывающих значение пропускной способности, с возможным расширением на один байт, который устанавливает тип ограничения. Он может иметь одно из трех возможных значений: жесткое, мягкое или динамическое (мягкое или жесткое).
Установить размер чанка (0x01)
[ редактировать ]Значение, полученное в четырех байтах тела. Существует значение по умолчанию — 128 байт, и сообщение отправляется только тогда, когда требуется изменение.
Протокол
[ редактировать ]Рукопожатие
[ редактировать ]После установления TCP-соединения сначала устанавливается RTMP-соединение, выполняющее рукопожатие посредством обмена тремя пакетами с каждой стороны (в официальной документации также называемыми чанками). В официальной спецификации они обозначаются как C0-2 для пакетов, отправленных клиентом, и S0-2 для серверной стороны соответственно, и их не следует путать с пакетами RTMP, которыми можно обмениваться только после завершения установления связи. Эти пакеты имеют собственную структуру, и C1 содержит поле, устанавливающее временную метку «эпохи», но поскольку ее можно установить в ноль, как это делается в сторонних реализациях, пакет можно упростить. Клиент инициализирует соединение, отправляя пакет C0 с постоянным значением 0x03, представляющим текущую версию протокола. Далее следует прямо с C1, не дожидаясь получения первым S0, который содержит 1536 байт, причем первые четыре представляют временную метку эпохи, все вторые четыре равны 0, а остальные являются случайными (и которые могут быть установлены на 0 в сторонних программах). реализации). C2 и S2 являются эхом S1 и C1 соответственно, за исключением того, что вторые четыре байта обозначают время получения соответствующего сообщения (вместо 0). После получения C2 и S2 рукопожатие считается завершенным.
Соединять
[ редактировать ]На этом этапе клиент и сервер могут согласовать соединение путем обмена сообщениями в кодировке AMF . К ним относятся пары «ключ-значение», которые относятся к переменным, необходимым для установления соединения. Пример сообщения от клиента:
(Invoke) "connect"
(Transaction ID) 1.0
(Object1) { app: "sample", flashVer: "MAC 10,2,153,2", swfUrl: null,
tcUrl: "rtmpt://127.0.0.1/sample ", fpad: false,
capabilities: 9947.75 , audioCodecs: 3191, videoCodecs: 252,
videoFunction: 1 , pageUrl: null, objectEncoding: 3.0 }
Flash Media Server и другие реализации используют концепцию «приложения» для концептуального определения контейнера для аудио/видео и другого контента, реализованного как папка в корне сервера, содержащая медиафайлы для потоковой передачи. Первая переменная содержит имя этого приложения как «образец», которое представляет собой имя, предоставленное сервером Wowza для тестирования. flashVer
строка такая же, как и возвращаемая Action-скриптом getversion()
функция. audioCodec
и videoCodec
кодируются как двойные , и их значение можно найти в исходной спецификации. То же самое верно и для videoFunction
переменная, которая в данном случае является интуитивно понятной константой SUPPORT_VID_CLIENT_SEEK. Особый интерес представляет objectEncoding
который будет определять, будет ли остальная часть связи использовать расширенный формат AMF3 или нет. Поскольку версия 3 является текущей версией по умолчанию, флэш-клиенту необходимо явно указать в коде сценария действий использовать AMF0, если это будет запрошено. Затем сервер отвечает последовательностью сообщений ServerBW, ClientBW и SetPacketSize, за которыми, наконец, следует Invoke с примером сообщения.
(Invoke) "_result"
(transaction ID) 1.0
(Object1) { fmsVer: "FMS/3,5,5,2004", capabilities: 31.0, mode: 1.0 }
(Object2) { level: "status", code: "NetConnection.Connect.Success",
description: "Connection succeeded",
data: (array) { version: "3,5,5,2004" },
clientId: 1728724019, objectEncoding: 3.0 }
Некоторые приведенные выше значения сериализуются в свойства универсального объекта Action-script, который затем передается прослушивателю событий NetConnection. clientId
установит номер сеанса, который будет запущен при соединении. Кодировка объекта должна соответствовать ранее установленному значению.
Воспроизвести видео
[ редактировать ]Чтобы запустить видеопоток, клиент отправляет вызов «createStream», за которым следует сообщение ping, за которым следует вызов «play» с именем файла в качестве аргумента. Затем сервер ответит серией команд «onStatus», за которыми следуют видеоданные, инкапсулированные в сообщениях RTMP.
После установления соединения мультимедийные данные отправляются путем инкапсуляции содержимого тегов FLV в сообщения RTMP типа 8 и 9 для аудио и видео соответственно.
HTTP-туннелирование (RTMPT)
[ редактировать ]Это относится к туннелированной версии протокола HTTP. Он обменивается данными через порт 80 и передает данные AMF внутри запросов и ответов HTTP POST. Последовательность подключения следующая:
POST /fcs/ident2 HTTP/1.1
Content-Type: application/x-fcs\r\n
HTTP/1.0 404 Not Found
POST /open/1 HTTP/1.1
Content-Type: application/x-fcs\r\n
HTTP/1.1 200 OK
Content-Type: application/x-fcs\r\n
1728724019
Первый запрос имеет /fcs/ident2
путь, а правильный ответ — ошибка 404 Not Found. Затем клиент отправляет запрос /open/1, на который сервер должен ответить 200 ok, добавив случайное число, которое будет использоваться в качестве идентификатора сеанса для указанного соединения. В этом примере в теле ответа возвращается 1728724019.
POST /idle/1728724019/0 HTTP/1.1
HTTP/1.1 200 OK
0x01
Отныне, /idle/<session id>/<sequence #>
— это запрос опроса, в котором идентификатор сеанса был сгенерирован и возвращен с сервера, а последовательность представляет собой просто число, которое увеличивается на единицу для каждого запроса. Соответствующим ответом является 200 OK с целым числом, возвращаемым в теле, обозначающим время интервала. Данные AMF передаются через /send/<session id>/<sequence #>
Реализации программного обеспечения
[ редактировать ]RTMP реализуется на трех этапах:
- Кодер живого видео
- Сервер потокового мультимедиа в реальном времени и по запросу
- Живой клиент по требованию
rtmpdump
[ редактировать ]Инструмент командной строки RTMP-клиента с открытым исходным кодом rtmpdump предназначен для воспроизведения или сохранения на диск полного потока RTMP, включая протокол RTMPE, который Adobe использует для шифрования. RTMPdump работает в Linux, Android, Solaris, Mac OS X и большинстве других операционных систем, основанных на Unix, а также в Microsoft Windows. Первоначально поддерживая все версии 32-битной Windows, включая Windows 98, начиная с версии 2.2 программное обеспечение будет работать только в Windows XP и выше (хотя более ранние версии остаются полностью функциональными).
Пакеты программного обеспечения rtmpdump доступны в основных репозиториях с открытым исходным кодом (дистрибутивах Linux). К ним относятся интерфейсные приложения «rtmpdump», «rtmpsrv» и «rtmpsuck».
Разработка RTMPdump была возобновлена в октябре 2009 года за пределами США, на сайте MPlayer . [12] Текущая версия отличается значительно улучшенной функциональностью и была переписана с учетом преимуществ языка программирования C. В частности, основной функционал был встроен в библиотеку (librtmp), которую легко могут использовать другие приложения. Разработчики RTMPdump также написали поддержку librtmp для MPlayer , FFmpeg , XBMC , cURL , VLC и ряда других проектов программного обеспечения с открытым исходным кодом. Использование librtmp обеспечивает этим проектам полную поддержку RTMP во всех его вариантах без каких-либо дополнительных усилий по разработке.
FLVстример
[ редактировать ]FLVstreamer — это форк RTMPdump без кода, который, по утверждению Adobe, нарушает DMCA в США. Это было разработано в ответ на попытку Adobe в 2008 году подавить RTMPdump. FLVstreamer — это RTMP-клиент, который сохраняет поток аудио- или видеоконтента с любого RTMP-сервера на диск, если для потока не включено шифрование (RTMPE).
Расширенный RTMP
[ редактировать ]Контейнер флэш-видео в RTMP в большинстве реализаций ограничен кодеком H264 . По этой причине организация программного обеспечения Veovera, включая Adobe , Google и Veriskope, опубликовала расширенную спецификацию RTMP, [13] который добавляет поддержку кодеков VP9 , H265 и AV1 в контейнере Flash Video FLV .
Реализации
[ редактировать ]- ffmpeg (начиная с версии 6.1) [14]
- ПРИМЕЧАНИЕ Студия 29.1 [15]
- YouTube (бета-версия, те же параметры загрузки, что и у h264)
- Твич [16]
См. также
[ редактировать ]- Безопасный надежный транспорт (SRT)
- Надежная потоковая передача данных через Интернет (RIST)
- ВебRTC
- Информация о защищенной потоковой передаче о RTMPS и RTMPE
- Видео по запросу (VoD)
- Расширения медиа-источников (MSE)
- Вебсокет
Ссылки
[ редактировать ]- ^ «РТМПЭ» . Справка по Adobe Flash Lite 4 . Adobe . Проверено 29 декабря 2013 г.
- ^ Jump up to: а б «TheRealTimeWeb.com: Патенты Adobe RTMP» . Realtimeweb.com .
- ^ «Использование служб RPC в Flex Data Services 2» . Архивировано из оригинала 3 апреля 2007 года . Проверено 16 апреля 2007 г.
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ Х. Пармар, М. Торнбург (ред.) Протокол обмена сообщениями Adobe в реальном времени , Adobe, 21 декабря 2012 г.
- ^ «Спецификация протокола обмена сообщениями в реальном времени (RTMP)» . Архивировано из оригинала 21 августа 2014 года . Проверено 8 мая 2014 г.
- ^ Лицензия на спецификацию RTMP , опубликовано в апреле 2009 г.
- ^ Шумахер-Расмуссен, Эрик (27 мая 2011 г.). «Wowza отрицает обвинения Adobe в нарушении патентных прав» . Streamingmedia.com .
- ^ Лоулер, Райан (31 мая 2011 г.). «Wowza отвечает на Adobe в патентном иске Flash» . gigaom.com .
- ^ «ADOBE Systems INCORPORATE — № C 11-2243 CW. — 20120907565 — Leagle.com» . leagle.com .
- ^ Wowza Media Systems и Adobe Systems урегулируют патентные дела http://www.wowza.com/news/wowza-media-systems-and-adobe-systems-settle-patent-cases
- ^ Проект Red5 (2009) Пинг. Доступно по адресу: http://trac.red5.org/wiki/Documentation/Tutorials/Ping . Доступ: 25 декабря 2011 г.
- ^ «Обновления: 01.11.2009» . Проверено 1 ноября 2009 г.
- ^ Лозбен, Славик (2 февраля 2024 г.). «Улучшение RTMP, FLV с помощью дополнительных видеокодеков и поддержки HDR» . Гитхаб . Проверено 1 апреля 2024 г.
- ^ «Поддержка кодека HEVC VP9 AV1 в расширенном формате FLV» . Гитхаб . 2 февраля 2024 г. Проверено 1 апреля 2024 г.
- ^ «Включить AV1, HEVC через RTMP на YouTube» . Гитхаб . 25 марта 2023 г. Проверено 1 апреля 2024 г.
- ^ «Представляем бета-версию расширенного вещания» . Гитхаб . 8 января 2024 г. Проверено 1 апреля 2024 г.