Jump to content

Протокол обмена сообщениями в реальном времени

Протокол обмена сообщениями в реальном времени ( RTMP ) — это протокол связи для потоковой передачи аудио, видео и данных через Интернет. Первоначально разработанный Macromedia как протокол собственный . для потоковой передачи между Flash Player и Flash Communication Server, компания Adobe (которая приобрела Macromedia) выпустила неполную версию спецификации протокола для публичного использования

Протокол RTMP имеет несколько вариантов:

  1. Собственно RTMP, «простой» протокол, который работает поверх протокола управления передачей (TCP) и по умолчанию использует номер порта 1935.
  2. RTMPS, который представляет собой RTMP через соединение Transport Layer Security (TLS/SSL).
  3. RTMPE, который зашифрован по протоколу RTMP с использованием собственного механизма безопасности Adobe. Хотя детали реализации являются собственностью компании, в механизме используются стандартные криптографические примитивы. [1]
  4. RTMPT, который инкапсулируется в HTTP- запросы для прохождения межсетевых экранов . RTMPT часто использует запросы открытого текста на TCP- портах 80 и 443 для обхода большей части фильтрации корпоративного трафика. Инкапсулированный сеанс может содержать в себе простые пакеты RTMP, RTMPS или RTMPE.
  5. 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]

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

[ редактировать ]
Схема пакетов RTMP

Пакеты передаются через 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 байт, и сообщение отправляется только тогда, когда требуется изменение.

Протокол

[ редактировать ]
Схема установления связи RTMP

Рукопожатие

[ редактировать ]

После установления 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 реализуется на трех этапах:

  • Кодер живого видео
  • Сервер потокового мультимедиа в реальном времени и по запросу
  • Живой клиент по требованию

Инструмент командной строки 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 .

Реализации

[ редактировать ]

См. также

[ редактировать ]
  1. ^ «РТМПЭ» . Справка по Adobe Flash Lite 4 . Adobe . Проверено 29 декабря 2013 г.
  2. ^ Jump up to: а б «TheRealTimeWeb.com: Патенты Adobe RTMP» . Realtimeweb.com .
  3. ^ «Использование служб RPC в Flex Data Services 2» . Архивировано из оригинала 3 апреля 2007 года . Проверено 16 апреля 2007 г. {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  4. ^ Х. Пармар, М. Торнбург (ред.) Протокол обмена сообщениями Adobe в реальном времени , Adobe, 21 декабря 2012 г.
  5. ^ «Спецификация протокола обмена сообщениями в реальном времени (RTMP)» . Архивировано из оригинала 21 августа 2014 года . Проверено 8 мая 2014 г.
  6. ^ Лицензия на спецификацию RTMP , опубликовано в апреле 2009 г.
  7. ^ Шумахер-Расмуссен, Эрик (27 мая 2011 г.). «Wowza отрицает обвинения Adobe в нарушении патентных прав» . Streamingmedia.com .
  8. ^ Лоулер, Райан (31 мая 2011 г.). «Wowza отвечает на Adobe в патентном иске Flash» . gigaom.com .
  9. ^ «ADOBE Systems INCORPORATE — № C 11-2243 CW. — 20120907565 — Leagle.com» . leagle.com .
  10. ^ Wowza Media Systems и Adobe Systems урегулируют патентные дела http://www.wowza.com/news/wowza-media-systems-and-adobe-systems-settle-patent-cases
  11. ^ Проект Red5 (2009) Пинг. Доступно по адресу: http://trac.red5.org/wiki/Documentation/Tutorials/Ping . Доступ: 25 декабря 2011 г.
  12. ^ «Обновления: 01.11.2009» . Проверено 1 ноября 2009 г.
  13. ^ Лозбен, Славик (2 февраля 2024 г.). «Улучшение RTMP, FLV с помощью дополнительных видеокодеков и поддержки HDR» . Гитхаб . Проверено 1 апреля 2024 г.
  14. ^ «Поддержка кодека HEVC VP9 AV1 в расширенном формате FLV» . Гитхаб . 2 февраля 2024 г. Проверено 1 апреля 2024 г.
  15. ^ «Включить AV1, HEVC через RTMP на YouTube» . Гитхаб . 25 марта 2023 г. Проверено 1 апреля 2024 г.
  16. ^ «Представляем бета-версию расширенного вещания» . Гитхаб . 8 января 2024 г. Проверено 1 апреля 2024 г.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: c34cc22151773bcac02cf1e4e873165e__1719448860
URL1:https://arc.ask3.ru/arc/aa/c3/5e/c34cc22151773bcac02cf1e4e873165e.html
Заголовок, (Title) документа по адресу, URL1:
Real-Time Messaging Protocol - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)