что такое 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-камеры бесполезны, если мы не можем «достучаться» до них по сети. Например, если такая камера находится в локальной сети, снаружи она доступна только если:
Запускаем свой RTMP сервер для стриминга
Иногда YouTube или Twitch не подходят как стриминговая платформа — скажем, если вы пилите портал с вебинарами или контентом 18+, нарушаете авторские права или хотите максимально отгородить свою трансляцию от остального интернета. У них есть много альтернатив как в виде сервисов (те же минусы, недостаток контроля и непредсказуемая политика), так и в виде self-hosted решений. Проблема опенсорсных стриминговых проектов в том, что все они начинаются с крохотной связки из пары технологий, а затем отчаянно пытаются вырасти в сервис, добавляя сложные веб-интерфейсы, чаты, библиотеки стримов и в конечном счёте отдаляясь от исходной цели: дать миру инструмент, который по понятному мануалу позволит запустить свой сервер трансляций. Что с ним будет дальше, в какие системы будет встроена эта картинка — это только ваше личное дело, а самописный аналог твича с лагающими и отваливающимися сервисами и периодически валящимся билдом не нужен никому, кроме его разработчиков. Поэтому в этой статье мы разберём минимальную цепочку действий для запуска своего RTMP-сервера с плеером.
Структура
Здесь всё просто: за приём и кодировку потока из OBS отвечает RTMP модуль Nginx’a. Сконвертированный поток он выставляет наружу, где его подбирает HLS (HTTP Live Streaming) клиент в браузере и выдаёт уже готовую картинку в плеере.
Установка
При выборе сервера упор стоит обратить внимание на процессор. Я взял эпичный сервер с двумя ядрами и пробовал наращивать битрейт, чтобы определить граничные условия — на 11-12k нагрузка стала болтаться в районе 96-100%, так что для обработки действительно тяжёлого потока лучше взять мощности с запасом:
Нам понадобится Docker для установки контейнеризованного nginx-rtmp с FFmpeg и любой веб-сервер (включая тот же Nginx) для раздачи страницы с плеером. Я ставил на Ubuntu 20.04:
Запускаем контейнер c проброшенными портами:
Затем в OBS на клиенте указываем наш сервер с произвольным ключом потока (ключ = индентификатор стрима):
Теперь можно запустить трансляцию и удостовериться что поток пошёл, например, в демке hls.js или в любом другом плеере HLS.
Осталось настроить сервер. В nginx.conf укажите путь до вашей страницы:
В index.html просто скопипастим код из примера hls.js:
Теперь на 8080 порту нашего сервера раздаётся жутковатый мультик про зайца:
Остаётся только изменить путь на http://server_ip:8080/live/stream-key.m3u8 и идти смотреть трансляцию!
Нагрузку в реальном времени можно проверять командой docker stats:
Заключение
Размещая стриминговый клиент на своём сервере важно помнить, что весь трафик со всех зрителей будет проходить прямо через него — значит, если одновременный онлайн у вас будет больше 1-2 человек, стоит изучать способы распределения нагрузки (ведь транскодирвоание ощутимо давит и на CPU). Для запуска полноценного кластера есть энтерпрайзное (но опенсорсное) решение — SRS aka Simple Realtime Server (GitHub, 10k звёзд, огромная вики, сложная архитектура). В него стоит вникать, если вам стримы нужны для решения настоящих задач, а не чтобы поиграться с приватным видеопотоком.
На правах рекламы
Серверы в аренду для любых задач — это про наши эпичные! Все серверы защищены от DDoS-атак, автоматическая установка множества ОС или использование своего образа ISO. Лучше один раз попробовать!
Трансляция RTMP видеопотока из Live Encoder на WebRTC
HTTP протоколы доставки видеоконтента, такие как HLS и DASH давно потеснили Flash в нише воспроизведения онлайн-видео контента в браузерах.
Тем не менее, изначально флэшовый протокол RTMP, остается одним из самых популярных способов доставки Live видео от источника видео до сервера ретранслятора. RTMP продолжают использовать такие сервисы, как Facebook Live, Youtube Live, и другие, где требуется вещать живое видео и проводить трансляции. Таким образом, несмотря на предсказания и констатации скорой кончины Flash, протокол RTMP все еще на коне и не уступает своих позиций в нише видеотрансляций.
Для захвата видео с камер, с последующей кодировкой в RTMP создано много хардварных и софтверных решений — коробок, которые подключаются к одной или нескольким камерам, обрабатывают полученные видеосигналы и отправляют полученную картинку по RTMP на удаленный сервер или сервис для дальнейшей ретрансляции. Классическая схема трансляции выглядит так:
Недостатком такой схемы можно назвать только задержку в видеотрансляции, которая может быть около 30 секунд. Если же вместо HLS и DASH использовать Adobe Flash Player и RTMP, то снова возвращаемся к Flash плагину, который находится, мягко говоря, не в авангарде современных средств отображения онлайн видео.
WebRTC
Решение, позволяющее отыграть поток без плагинов и с минимальной задержкой — это WebRTC и конвертация RTMP в WebRTC на стороне сервера решает задачу воспроизведения потока на большом числе устройств и браузеров.
Однако здесь следует понимать, что WebRTC — это технология, заточенная под реалтайм. В отличие, например от того же HTTP (HLS), где просто отдаются сегменты по протоколу HTTP, WebRTC работает гораздо сложнее и использует плотный обмен данными между отправителем и получателем трафика, с использованием RTCP-фидбеков, контролем полосы пропускания и таргетированием задержки.
Поэтому прежде чем включать WebRTC для простого воспроизведения потока, нужно ответить на один простой вопрос: требуется ли в проекте доставки видео низкая задержка. И если низкая задержка не требуется, то есть смысл рассмотреть другие технологии доставки, такие HLS и DASH чтобы избежать оверхеда с WebRTC.
Для максимальной совместимости с другими устройствами и сохранения возможности раздачи на HLS, необходимо выбрать правильные кодеки. Как правило, RTMP кодеры поддерживают H.264 видео кодек и AAC аудио кодек. Эта комбинация достаточно стандартная и встречается очень часто.
WebRTC в браузерах не поддерживает кодек AAC, поэтому придется транскодировать AAC в Opus или AAC в G.711. Транскодинг в Opus дает лучшее качество и позволяет, при желании, выкрутить его еще выше с помощью настроек. Поэтому если и транскодить, то предпочтительно делать это в Opus.
Так как мы используем H.264 при получении видеопотока сервером и при его воспроизведении с WebRTC-устройств, то транскодинга здесь не требуется, а требуется депакетизация полученного по RTMP видео с последующей пакетизацией в SRTP (WebRTC). Процесс ре-пакетизации, очевидно отнимает меньше процессорного времени чем транскодинг, что позволяет обслужить больше входящих потоков.
Однако, не все устройства поддерживают H.264. Например браузер Chrome под Android не везде дает использовать этот кодек. В этом случае включится полноценный транскодинг в WebRTC кодек VP8 и схема будет выглядеть так:
Транскодинг на стороне сервера предъявляет серьезные требования к CPU, поэтому нужно быть готовым заложить около 1 ядра сервера, при необходимости транскодинга потока высокого разрешения, например 720p
Кодеры
Профессиональные коробочки вроде такой стоят хороших денег и требуются для профессионального вещания 24×7 и серьезных бизнес-задач:
Для вещания более простых мероприятий подойдут софтверные решения, одним из которых является бесплатный Live Media Encoder от Adobe.
Версия кодера для Mac OS имеет поддержку кодеков H.264 и AAC. Поэтому если использовать Live Media Encoder на Mac, он может в каком-то смысле стать заменой хардварного кодера или платного софта, позволяющего вещать RTMP в сеть с теми же кодеками.
Тестирование
Для начала убедимся, что поток доступен и играет по RTMP. Если с воспроизведением по RTMP все в порядке и поток на месте, подключаемся к нему по WebRTC.
Процесс стриминга видеопотока на сервер называется публикация (publishing) и требует как минимум:
Если адрес сервера правильный, есть доступ к камере, то при нажатии кнопки Start, кодер должен получить соединение с сервером по протоколу RTMP и начать публикацию видеопотока по указанному адресу и с указанным именем stream2229.
Теперь нужно забрать видеопоток с сервера по RTMP. Для этого будем использовать простое Flash-приложение Flash Streaming, которое также доступно по этой ссылке. Это обычная флэшка (swf-файл), которая располагается на web-странице и выполняется в Adobe Flash Player. Поэтому убедитесь, что Flash Player установлен и доступен в вашей системе для этого теста.
Здесь требуется ввести те же данные: адрес RTMP потока и его имя. В результате получаем видео на веб-странице. Его играет Flash Player.
Далее, вспоминаем, что нашей целью было протестировать воспроизведение с помощью WebRTC, и воспроизведение во Flash было лишь промежуточным тестом, подтверждающим работу RTMP кодера и сервера трансляции.
Для теста просто заберем видеопоток WebRTC плеером. Этот плеер не требует указания RTMP-адреса, так как для подключения к серверу используется протокол Websockets и адрес будет таким: wss://192.168.88.59:8443
wss — это вебсокеты через SSL
192.168.88.59 — адрес WebRTC сервера
8443 — порт сервера для протокола Websockets SSL
После того, как в качестве имени потока указали stream2229, нажимаем Play и получаем картинку уже по WebRTC.
Здесь нужно отметить, что несмотря на то, что подключение к серверу произошло по Websockets и порт указан 8443, видеотрафик пойдет не через это соединение. Для видео будут открыты специальные UDP порты на стороне браузера и на стороне сервера и именно через эти открытые UDP порты будет осуществляться передача видео. Через Websockets же будут переданы простые команды воспроизведения, статусы, а также конфигурация кодеков и другой важной для WebRTC информации.
Чтобы посмотреть как заходит WebRTC видеотрафик, используем браузер Google Chrome и во время воспроизведения открываем chrome://webrtc-internals
Графики показывают, что битрейт принимаемого видеопотока составляет около 600 kbps, фрейм рейт 28-30 FPS.
Следующие графики дают информацию о количестве потерянных UDP пакетов (50), о скорости приема пакетов в секунду, о разрешении видеопотока 640×480, о джиттере и времени декодирования.
Таким образом, мы протестировали воспроизведение RTMP видеопотока, отправленного с Adobe Live Media Encoder на HTML5 — странице в браузере с поддержкой WebRTC и не использовали дополнительных браузерных плагинов. Тестирование проходило с сервером Web Call Server 5, который поддерживает входящие RTMP потоки с последующей раздачей по RTMP, WebRTC и другим протоколам.
Код страницы — WebRTC плеера
Минимальный код плеера для встраивания в веб-страницу выглядит так
Этот код опирается на файл API flashphoner.js, который доступен в сборке Web SDK. Сам плеер будет встроен в div-элемент remoteVideo.
Скрипт player.js использует три функции: инициализацию с помощью Flashphoner.init(), создание подключения к серверу с помощью Flashphoner.createSession() и воспроизведение WebRTC видеопотока session.createStream(. ).play().
Статусы соединения с сервером отслеживаются с помощью событий: ESTABLISHED, DISCONNECTED, FAILED.
Статусы видеопотока отслеживаются с помощью событий PLAYING, STOPPED, FAILED.
Таким образом получаем полный контроль над соединением с сервером и статусами видеопотока.
Минимальный код WebRTC плеера доступен для скачивания по этой ссылке и для работы требует установленного WebRTC-сервера Web Call Server 5. Сервер может быть скачан и установлен на Linux-хост https://flashphoner.com/download или же запущен в виде образа на Amazon EC2.
Минимальный код WebRTC плеера в работе
Пример плеера и скриншоты представленные выше, имели некоторые дополнительные стили и скрипты для позиционирования картинки.
В минимальном коде мы ограничились простейшим HTML и урезанным скриптом для максимально быстрого внедрения в страницу сайта. Результат выглядит так:
Этот плеер можно интегрировать в любую веб-страницу сайта или проекта, т.к. он требует лишь включения скрипта API flashphoner.js и одного div-блока под видео на веб-странице.
Сервер, который работает с WebRTC может физически находиться на другой независимой машине, никак не связанной с хостингом веб-проекта.
В итоге, мы описали код WebRTC-плеера и показали как встроить плеер в веб-страницу сайта и развернуть на собственном веб-сервере. Плеер играет WebRTC H.264 видеопоток. Источником потока RTMP является Adobe Live Media Encoder.
Сервер онлайн-вещаний на базе nginx
Введение
Вещатель нужен для передачи видео-потока клиенту. Речь идет либо о живом потоке, либо о вещании записанного видео (VOD, Video-on-demand). Существует большое количество технологий вещания видео. Среди них можно выделить традиционные протоколы, такие как RTMP или MPEG-TS, а также появившиеся в последнее время технологии адаптивного вещания поверх HTTP. К последним относятся HLS (Apple), HDS (Adobe), Smooth Streaming (Microsoft), MPEG-DASH. При выборе технологии основным фактором является ее поддержка на клиентской стороне. Именно поэтому вещание в формате RTMP на текущий момент является одним из самых распространенных. Протокол HLS поддерживается устройствами компании Apple, а также некоторыми версиями Android.
Сборка и настройка nginx-rtmp
После сборки и инсталляции нужно добавить секцию rtmp<> в файл конфигурации nginx.conf. Добавлять ее надо в корень конфига. Например:
Для многих случаев этой простой конфигурации будет достаточно. В ней задается RTMP-приложение с именем myapp. В это приложение мы позже будем публиковать потоки и проигрывать их из него. У каждого потока также будет свое уникальное имя. Стоит отметить один важный нюанс, касающийся приведенной выше конфигурации. Она верна для того случая, когда число воркеров nginx равно единице (как правило, задается в начале nginx.conf).
Чтобы иметь возможность использовать live вещания с бОльшим числом воркеров, нужно указать директиву rtmp_auto_push on (см. раздел «Воркеры и локальная ретрансляция»).
Публикация и проигрывание живого потока
Для публикации и проигрывания видео можно использовать Flash-проигрыватели (JWPlayer, FlowPlayer, Strobe и т.д.). Однако, для вещания серверных потоков и для тестирования часто используют ffmpeg (и ffplay). Начнем вещание тестового файла test.mp4 следующей командой:
Тут надо учесть, что RTMP поддерживает ограниченый набор кодеков, впрочем, такие популярные кодеки, как H264 и AAC, входят в их число. Если кодеки в тестовом файле не совместимы с RTMP, потребуется перекодировка:
Вещать можно как поток из файла, так и из другого источника. Например, если предположить, что по адресу video.example.com/livechannel.ts вещается некий live MPEG-TS поток, то его также можно завернуть в rtmp:
Пример вещания с локальной веб-камеры:
Проиграть поток можно при помощи ffplay следующей командой:
И, наконец, простой пример использования JWPlayer для проигрывания потока из браузера (полностью приведен в директории /test/www модуля):
Видео по запросу
Модуль поддерживает вещание видео-файлов в форматах mp4 и flv. Пример настройки:
При проигрывании, соответственно, надо указывать имена файлов, в остальном все аналогично живому вещанию.
Ретрансляция
При построении распределенных систем важно иметь возможность ретрансляции потоков для балансировки нагрузки
по большому числу серверов. Модуль реализует два типа ретрансляции: push и pull. Первый тип ретрансляции
состоит в передаче на удаленный сервер локально публикуемого потока, а второй — в передаче удаленного
потока на локальный сервер. Пример push ретрансляции:
В момент, когда начинается публикация по адресу rtmp://localhost/myapp/mystream, создается соединение с удаленным сервером и поток mystream публикуется далее на rtmp://cdn.example.com/myapp/mystream. При прекращении локальной публикации, соединение с cdn.example.com автоматически завершается.
Pull-ретрансляции выполняют обратную операцию:
В этом примере при появлении клиента, желающего локально проиграть поток rtmp://localhost/myapp/mystream, будет создано соединение с rtmp://cdn.example.com/myapp/mytstream и удаленный поток будет ретранслирован на локальный сервер, после чего станет доступным всем локальным клиентам. В тот момент, когда не останется ни одного клиента, соединение будет завершено.
Вещание на мобильные устройства (HLS)
Для вещания на устройста iPhone/iPad, а также на новые версии Android, используется протокол HLS (HTTP Live Streaming).
Протокол был разработан компанией Apple и представляет из себя «нарезанный» на куски MPEG-TS/H264/AAC поток, отдаваемый по HTTP. К потоку прилагается плейлист в формате m3u8. Отдавать HTTP nginx умеет отлично. Значит, надо лишь создать и обновлять плейлист и фрагменты HLS-потока, а также следить за удалением старых фрагментов. Для этого существует модуль nginx-rtmp-hls. Он находится в директории hls, однако не собирается по умолчанию т.к. требует библиотеки libavformat, входящей в пакет ffmpeg. Для сборки nginx с поддержкой HLS, надо добавить этот модуль явно при конфигурации:
Так вышло, что некоторое время назад проект ffmpeg был форкнут. И теперь у нас есть два проекта — ffmpeg и avconv, а следовательно, тут же начали возникать проблемы совместимости (вернее, несовместимости) библиотек. Для сборки nginx-rtmp нужен оригинальный ffmpeg. В то же время, некоторые дистрибутивы Linux перешли на использование avconv, который для сборки не подойдет. На этот случай я написал подробную инструкцию.
Для генерации HLS достаточно указать следующие директивы:
Ну и, наконец, в секции http<>, настроить отдачу всего, что связано с HLS:
Теперь публикуем поток mystream в приложение myapp, а в браузере iPhone набираем в строке адреса example.com/hls/mystream.m3u8. Кроме того, поток можно встроить в html тег video:
Отмечу, что для проигрывания на iPhone поток должен быть закодирован в H264 и AAC. Если исходный поток не соответствует этим условиям, необходимо настроить перекодирование.
Перекодирование
При вещании видео часто возникает необходимость перекодирования входящего потока в другое качество, либо другие кодеки. Эта задача по своей сути кардинально отличается от раздачи RTMP и, в отличие от последней, связана с высокими нагрузками на CPU, большим и активным потреблением памяти, часто опирается на использование многопоточности и является потенциально нестабильной. По этой причине она не должна включаться в основной процесс сервера, и в идеале должна выполняться отдельным процессом. Стоит отметить, что прекрасный инструмент для решения этой задачи уже существует — это все тот же ffmpeg. Он поддерживает огромное число кодеков, форматов и фильтров, позволяет использовать множество сторонних библиотек. Вместе с тем, он достаточно прост и активно поддерживается сообществом. Модуль nginx-rtmp предоставляет простой интерфейс для использования ffmpeg. Директива exec позволяет запустить внешнее приложение в момент публикации входящего потока. При завершении публикации приложение также принудительно завершается. Кроме того, поддерживается перезапуск запущенного приложения, если оно внезапно завершилось само.
Воркеры и локальная ретрансляция
Как известно, nginx является однопоточным сервером. Для того, чтобы эффективно использовать все ядра современных процессоров, обычно он запускается в несколько воркеров. Обработка HTTP запросов как правило, происходит независимо друг от друга, и лишь в отдельных случаях (как, например, в случае с кешом), требуется осуществлять доступ к общим данным. Такие данные хранятся в разделяемой памяти.
При живом вещании ситуация иная. Все клиентские соединения, проигрывающие поток, очевидным образом зависят от соединения, публикующего этот поток. Использование разделяемой памяти в данном случае неэффективно, излишне трудоемко, привело бы к синхронизации и большой потере производительности. Поэтому для использования нескольких воркеров был реализован механизм внутренних ретрансляций через UNIX-сокеты. Собственно, такие ретрансляции практически ничем не отличаются от обычных внешних push-ретрансляций. Локальные ретрансляции включаются следующей директивой
Указывать ее надо в корневой секции конфигурационного файла. Отмечу, что локальные ретрансляции нужны только для живых вещаний.
Запись
Часто возникает необходимость записи на диск публикуемых потоков. Модуль позволяет записывать как отдельные данные из потока (аудио, видео, ключевые фреймы) так и поток целиком. Можно установить ограничение на размер файла, а также на число записываемых фреймов. Следующий пример включает запись первых 128К каждого потока.
Запись происходит в формате flv в директорию /tmp/rec.
Управлять записью можно в ручном режиме, включая и отключая ее при помощи http-запроса. Для этого используется control-модуль. Информацию о нем можно найти на сайте проекта.
Авторизация и бизнес-логика
Во многих случаях требуется ввести ограничения или учет операций публикации и проигрывания видео. Это бывает связано с логикой проекта, в котором он используется. Самый частый подобный случай — необходимость авторизации пользователя перед тем, как дать ему доступ к просмотру видео. Чтобы интегрировать бизнес-логику проекта в вещатель, в модуле реализованы HTTP-колбэки, такие как on_publish и on_play. Серверный код получает всю имеющуюся информацию о клиенте, включая его адрес, имя потока, адрес страницы и т.д. Если возвращается HTTP статус 2xx, то колбек считается завершенным успешно и работа клиента продолжается. В противном случае соединение разрывается.
Статистика
В каждый момент времени к вашему серверу могут быть подсоединены тысячи клиентов. Естественно, нужен интерфейс, позвляющий увидеть их список, а также все основные характеристики публикуемых или проигрываемых ими потоков. Причем, важно, чтобы эту информацию можно быть как анализировать визуально, так и обрабатывать программно. Такой интерфейс у модуля nginx-rtmp существует. Чтобы его использовать, необходимо в http-секции nginx.conf прописать следующие директивы.
Директива rtmp_stat включает отдачу XML-документа с полным описанием live-клиентов, публикующих или проигрывающих потоки, списком приложений и серверов. Этот документ удобен для программной обработки, но для визуального анализа совершенно не годится. Чтобы иметь возможность просматривать список клиентов в браузере, директивой rtmp_stat_stylesheet задается относительный путь к таблице стилей XML (stat.xsl). Этот файл лежит в корне проекта. Надо настроить nginx на его раздачу по указанному урлу. Результат можно просматривать в браузере.
Существует возможность явно разрывать клиентские соединения. Для этого используется control-модуль, не описанный в статье.
Простое Интернет-радио
С самого начала статьи я постоянно употреблял слово «видео». Конечно, модуль может вещать не только видео, а также и аудио-потоки. Вот простой пример интернет-радиостанции на bash, вещающей mp3-файлы из /var/music. Этот поток может воспроизводить простой JWPlayer, встроенный в веб-страницу.
Совместимость
Модуль совместим со всем основным софтом, работающим с протоколом RTMP, включая FMS/FMLE, Wowza, Wirecast, протестирован с самыми распространенными флеш-проигрывателями JWPlayer, FlowPlayer, StrobeMediaPlayback, а также отлично работает с ffmpeg/avconv и rtmpdump.
Нагрузки
Модуль использует асинхронную однопоточную модель сервера nginx. Это позволяет добиться высокой производительности. Мы используем модуль на машинах Intel Xeon E5320/E5645 в режиме одного воркера. В этом режиме удается достигнуть максимальной пропускной способности имеющихся сетевых карт — 2Gbps. Пользователи модуля подтверждают сохранение этого же соотношения (2Gbps на ядро) в режиме локальной ретрансляции с несколькими воркерами. Практика показывает, что производительность вещателя обычно упирается в сеть, а не в CPU.
Прямых сравнений с другими продуктами я не проводил, однако, «тяжелые» многопоточные FMS, Wowza и Red5, будучи более функциональными, должны, в силу особенностей реализации, существенно проигрывать моему решению по числу одновременно подсоединенных клиентов и нагрузке на CPU. Это подтверждается многими пользователями, проводившими такие сравнения, в т.ч. в уже упомянутой мной статье.
Заключение
В заключение скажу, что модуль распространяется по лицензии BSD. Он собирается и работает под Linux, FreeBSD и MacOS. В статье описана лишь малая часть функционала nginx-rtmp-module. Желающие могут ознакомиться с проектом по ссылкам, приведенным ниже.