В современном мире видео является наиболее популярным форматом контента, и существует множество протоколов для его потоковой передачи в сети. В данной статье мы рассмотрим различные протоколы потоковой передачи видео, такие как RTSP, RTMP и HLS, и их особенности.
RTSP (Real-Time Streaming Protocol) — это протокол потоковой передачи мультимедийных данных в режиме реального времени. Он предназначен для управления передачей мультимедийного контента, включая видео и аудио. RTSP обеспечивает быстрое начало воспроизведения за счет разделения потока на различные части, такие как аудио и видео, и позволяет выбирать источник и тип потока. RTSP также поддерживает функцию «паузы», что позволяет приостановить поток и возобновить его позже. Однако RTSP не является самостоятельным протоколом потоковой передачи и требует дополнительных протоколов для передачи данных.
RTMP (Real-Time Messaging Protocol) — это протокол потоковой передачи видео в режиме реального времени, разработанный компанией Adobe. В отличие от RTSP, RTMP является самодостаточным протоколом и обеспечивает передачу видео и аудио данных. Он обеспечивает более стабильную передачу данных благодаря использованию контрольных механизмов для проверки целостности и сохранности данных. RTMP также поддерживает функцию стриминга, позволяя непрерывную передачу видео в режиме реального времени. Однако RTMP имеет некоторые ограничения, такие как низкая скорость передачи данных и неподдержка адаптивной потоковой передачи видео.
Как создать HLS RTMP сервер. Как сделать собственный стрим сервер
HLS (HTTP Live Streaming) — это протокол потоковой передачи видео, разработанный компанией Apple. Он основан на протоколе HTTP и обеспечивает передачу видео и аудио данных через интернет. Одной из главных особенностей HLS является его способность адаптивной потоковой передачи, что позволяет автоматически регулировать качество видео в зависимости от скорости интернет-соединения пользователя. HLS также поддерживает механизм кэширования, который позволяет загружать небольшие фрагменты видео для немедленного воспроизведения. Однако HLS имеет некоторые ограничения, такие как задержка воспроизведения из-за наличия буфера.
В заключение, RTSP, RTMP и HLS — это различные протоколы для потоковой передачи видео. RTSP является протоколом управления передачей данных и требует дополнительных протоколов для передачи данных. RTMP является самодостаточным протоколом, но имеет некоторые ограничения в скорости передачи данных и поддержке адаптивной потоковой передачи. HLS является протоколом на основе HTTP, который обеспечивает адаптивную потоковую передачу и имеет механизм кэширования для более быстрого воспроизведения. Каждый из этих протоколов имеет свои преимущества и ограничения, и выбор протокола зависит от конкретных требований и условий использования.
Источник: qaa-engineer.ru
NGINX + nginx-rtmp-module — трансляция видео с веб-сервера
Свой собственный рестриминговый RTMP сервер с конвертацией RTMP SRT UDP MPEG DASH HLS
Обновлено: 28.09.2018 Опубликовано: 02.03.2017
Вещание видео будет осуществляться с помощью модуля для nginx — nginx-rtmp-module.
Для этого необходимо собрать веб-сервер nginx из исходников, включив вышеназванный модуль.
Сборка NGINX + nginx-rtmp-module
Для удобства работы с nginx, сначала мы установим его из пакетов, хотя бы, чтобы создались скрипты автозапуска.
Установка nginx и пакетов для сборки
Ubuntu:
apt-get install nginx libpcre++-dev libssl-dev libxslt1-dev libgd2-xpm-dev libgeoip-dev
CentOS:
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1
yum install nginx pcre-devel openssl-devel
Сборка из исходников
Смотрим версию установленного пакета:
Теперь переходим по ссылке https://nginx.org/download и копируем ссылку на установленную версию nginx (архив tar.gz). В моем случае, это была версия 1.10.0.
* обратите внимание, что в данном списке версии идут не по порядку — ориентируйтесь по дате (средняя колонка).
Распаковываем исходник nginx и модуль:
tar xzf nginx-1.10.0.tar.gz
tar xzf master.tar.gz
И переходим в распакованный каталог nginx:
Смотрим, с какими опциями собран уже установленный nginx:
Копируем текст, который идет после configure arguments:
Теперь конфигурируем nginx со скопированными опциями + —add-module=../nginx-rtmp-module-master. Получиться что-то на вроде:
./configure —with-cc-opt=’-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2′ —with-ld-opt=’-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now’ —prefix=/usr/share/nginx —conf-path=/etc/nginx/nginx.conf —http-log-path=/var/log/nginx/access.log —error-log-path=/var/log/nginx/error.log —lock-path=/var/lock/nginx.lock —pid-path=/run/nginx.pid —http-client-body-temp-path=/var/lib/nginx/body —http-fastcgi-temp-path=/var/lib/nginx/fastcgi —http-proxy-temp-path=/var/lib/nginx/proxy —http-scgi-temp-path=/var/lib/nginx/scgi —http-uwsgi-temp-path=/var/lib/nginx/uwsgi —with-debug —with-pcre-jit —with-ipv6 —with-http_ssl_module —with-http_stub_status_module —with-http_realip_module —with-http_auth_request_module —with-http_addition_module —with-http_dav_module —with-http_geoip_module —with-http_gunzip_module —with-http_gzip_static_module —with-http_image_filter_module —with-http_v2_module —with-http_sub_module —with-http_xslt_module —with-stream —with-stream_ssl_module —with-mail —with-mail_ssl_module —with-threads —add-module=../nginx-rtmp-module-master
Источник: www.dmosk.ru
SRT. Что это такое и зачем.
Как вы понимаете, в процессе стриминга участвуют три стороны: Publisher, Server и Viewers. Это определяет два участка, на которых много лет назад преобладал RTMP. Во многом, благодаря популярности Flash-технологии на десктопах. 
Со временем, когда произошёл отказ от Flash и потребление контента сместилось в сторону мобайла, ситуация изменилась. В наши дни, если рассматривать участок от сервера к зрителю, то можно однозначно сказать — RTMP на этом участке уже не используется. Его сменил протокол HLS, детище компании Apple, и ряд менее распространённых протоколов, но с той же общей идеей: шлёпать маленькие файлики (секунд 3–10) и посылать их зрителю.
Но на участке Publisher → Server протокол RTMP до сих пор не сдаёт свои позиции и является монополистом. Если вы хотите стримить на Facebook, YouTube или Twitch вы должны использовать RTMP. В силу этого и производители стриминг софта, и железа тоже вынуждены поддерживать RTMP. Тем более, никакой другой альтернативы никто особо и не предлагал.
ПРИМЕЧАНИЕ: некоторые платформы могут принимать на вход HLS/DASH. Но этот путь особо не популярен, потому что любой “фрагментарный” протокол — это несколько секунд (!) задержки уже в начале пути.
Что-же не устраивает в RTMP ?
Замечу, что Adobe (владелец протокола RTMP) перестала его развивать в тот момент, когда похоронила технологию Flash, а было это достаточно давно.
За это время успели появиться новые кодеки (h265, av1), и возможно скоро появятся ещё.
Вы, наверное, читали обзоры кодеков, где говорят что кодек .h265 может дать выигрыш 25–50%! То есть вместо 5Mbs вам достаточно интернет-канала условно в 3Mbs. Согласитесь, это здорово! Особенно, если вам нужно передать сигнал по LTE.
Увы, но использовать даже h265 внутри RTMP не получится. Пожалуй, это и есть основная претензия к RTMP — он не подходит для новых кодеков.
ПРИМЕЧАНИЕ: наверное, некоторые скажут: «эй, китайские энкодеры пишут что могут h265 в RTMP!» Могут, но это уже какой-то не официальный диалект RTMP, и понять его может только сервер от того же китайца.
Кто раньше встал, того и тапки
Конечно, команды разных размеров по всему миру делали свои протоколы. Например, понятно, что у LiveU есть свой крутой протокол, да ещё и с поддержкой бондинга. Но именно компания Haivision подсуетилась, особенно в маркетинговой части, и первой подарила публике замену для RTMP. Протокол назвали SRT. Грамотный маркетинг, в частности ставка на open-source, сделал своё дело, и SRT набирает популярность.
SRT: особо интересные моменты
SRT — это “codec agnostic” протокол. То есть ему без разницы что там за кодек внутри передаётся. Передать h264, h265, av1 — нет проблем.
SRT основан на UDP (а RTMP основан на TCP), что позволило «затюнинговать» его под современные реалии
// UDP-хейтерам этот момент я раскрою в следующем посте
В SRT есть режимы “можно терять данные”(по умолчанию) и “ничего не терять” (по аналогии с TCP).
Есть режим пробивки файрвола, когда нет выделенного IP (см ниже).
Режим “можно терять данные“ стоит по умолчанию, и рекомендован для Live-streaming’а с низкой задержкой. Конечно, SRT будет в рамках дозволенного интервала времени пытаться переслать потерянные данные.
Кстати, это время как раз регулируется параметром Latency который присутствует во многих SRT-энкодерах. И по умолчанию он стоит в 120ms. То есть, если пакет данных потерялся, система пытается его снова послать и снова, и на всё есть 120ms, потом он снимается с обработки.
На практике, при большом проценте потерь, это выглядит как артефакты на картинке. Если говорить про отличие от RTMP в этом вопросе, то в SRT вы сами определяете степень компромисса между “скорость доставки” и “качество доставки”.
Режим «ничего не терять» предназначен в SRT для передачи файлов, где потеря одного байта может поломать весь файл. В энкодерах для стриминга вряд ли вы встретите такую опцию.
Также стоит отметить, что протокол активно развивается в рамках open-source, и уже есть обсуждения как добавить в протокол бондинг.
SRT ходит сквозь файрвол? Бывает…
Надо сказать, что для UDP (на котором построен SRT) есть старый метод пробивки файрвола, которым пользовался ещё Скайп, когда был p2p.
Утрировано звучит так: если два гнома подбегут к разделяющей их стене к одной точке и одновременно (!) ударят по одному и тому же кирпичу, то тогда есть шанс пробить дырку.
В SRT это назвали “рандеву режимом”, и при настройке его обоим участникам нужно знать внешний IP друг-друга (по сути это координаты “точки” в которую надо бить), и ещё согласовать время “удара”. То есть нужно решить проблему согласования. Делать это “ручками” можно, но не тривиально.
Кстати, продукты категории SRT-cloud от разных производителей как раз и снимают эту боль с вас: поскольку все стороны используют единое ПО, то они могут автоматически договориться по каким-то своим протоколам через центральный сервер, и тогда будет возможность пробивать файрвол уже методом SRT и дальше общаться напрямую.
Моё личное мнение: ручная настройка рандеву нетривиальна. Лучше веровать в ipv6. Кстати, видел, что МТС выдаёт ipv6 для LTE без проблем (в отличие от ipv4) и, насколько я знаю, там нет проблем с фильтрацией трафика.
Ну и кто победит?
Технически SRT конечно уделывает RTMP. Вопрос в том, пойдёт ли SRT в массы или так и останется профессиональной вещью. Нужно сказать, что крупные платформы Facebook и YouTube как то не замечены в гребле в сторону SRT. Поэтому производители всяких массовых стрим-железок типа экшен-камер, дронов, накамерных стримеров, так и будут плодить RTMP-железки, ведь юзерам нужно стримить на эти платформы. И особого резона внедрять SRT им пока нет.
В общем, время покажет.
Источник: garaninapps.com