В чем разница между RTSP, RTMP, HLS?
В чем разница между RTSP, RTMP, HLS ? Надо получить видео поток без минимальной задержки. Приложение под android, а на android как знаю с RTMP проблемы. Но есть RTSP и HLS.
Отслеживать
задан 2 ноя 2016 в 13:18
721 6 6 серебряных знаков 19 19 бронзовых знаков
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Разница RTMP/RTSP/HLC в спецификациях интерфейсов, по сути одно и тоже, ТОЛЬКО В ПРОФИЛЬ.
RTMP — это перекодированный с RTSP поток во Flash Media .
HLC — это http обвертка UDP потока.
Рекомендую использовать HLC , так как он более адаптивен. RTSP спецификацию не меняли лет 5-6. Много косяков, рассчитан больше не стриминг, нежели upload .
Протоколы для стриминга: SRT, RTMP, HLS, WebRTS. Что это, зачем и как работает?
Все мы знаем, причем на собственном опыте, что большинство из нас (пользователей интернета) редко проводят хотя бы один день без просмотра потокового видео. Рост популярности именно такого потребительского поведения в отношении контента связан с доступностью протоколов потоковой передачи видео (или стримингового видео).
Протоколы стримингового видео — это специальные стандартизированные правила и методы, которые разбивают видеофайлы на более мелкие части, чтобы затем их можно было доставить конечному пользователю для повторной сборки и просмотра.
Файлы должны быть сжаты для транспортировки, этот процесс достигается с помощью «кодека», например, такого, как самый распространенный H.264. Прежде чем можно будет передать файлы, их еще нужно сохранить в «контейнерном формате», таком как .mp4 или .avi. Источником видеофайла может быть непосредственно камера транслирующего пользователя в случае прямой трансляции или статические файлы в случае видео по запросу (VoD).
Развитие протоколов стримингового видео
Так как спрос на потоковое видео только растет, в том числе благодаря увеличению проникновения интернета, количество платформ потокового видео тоже увеличивается. В 1990-х годах потоковая передача в основном ограничивалась трансляциями спортивных мероприятий, в 2000-х технология начала набирать обороты, благодаря потоковой передаче на основе Flash и RTMP. Затем в 2010-х появились YouTube, Netflix и другие платформы. Прямая трансляция, как формат, действительно зародилась в середине 2010-х, а вскоре после этого были запущены Periscope и Facebook Live. Сегодня рынок потокового видео является весьма оживленным, благодаря многочисленным платформам, компаниям-провайдерам и способам использования, включая live-аудио, потоковое воспроизведение фильмов и игр. Наряду с этими разработками также расширились возможности протоколов потоковой передачи видео.
Какие протоколы потокового видео самые популярные?
На сегодняшний день существует несколько протоколов потоковой передачи видео. Некоторые из них можно назвать устаревшими стандартами, но они тем не менее, все еще применяются. Другие, напротив, быстро развиваются, в первую очередь благодаря открытому исходному коду. Некоторые из протоколов довольно свежие, и им потребуется время, чтобы получить широкое распространение, но именно они имеют большой потенциал для формирования паттерна получения потокового видео в будущем. Не все протоколы поддерживают одни и те же кодеки. Ниже рассмотрим наиболее распространенных из них.
HTTP Live Streaming (HLS)
На сегодняшний день HLS является наиболее часто используемым протоколом для потоковой передачи. Первоначально он был выпущен Apple в 2009 году в рамках борьбы с форматом Flash в iPhone. Этот протокол совместим с широким спектром устройств, от десктоп-браузеров, смарт-телевизоров, телевизионных приставок, мобильных устройств на Android и iOS до видеоплееров на основе HTML5. Естественно, это позволяет стриминговым компаниям охватить максимально широкую аудиторию. LS также поддерживает потоковую передачу с адаптивным битрейтом. Это технология, которая позволяет динамически доставлять видео, чтобы обеспечить наилучшее качество видео для конечных пользователей. Единственным серьезным недостатком протокола HLS можно назвать связанную с ним большую задержку. Под задержкой понимается время, необходимое доставляемому контенту для перемещения от источника к месту запроса и обратно, особенно если передаются большие объемы данных.
Динамическая адаптивная потоковая передача через HTTP (MPEG-DASH)
MPEG-DASH — один из последних протоколов потоковой передачи, разработанный Moving Pictures Expert Group (MPEG) в качестве альтернативы стандарту HLS. Это стандарт с открытым исходным кодом, который можно настроить для любого аудио- или видеокодека. Как и HLS, MPEG-DASH поддерживает потоковую передачу с адаптивным битрейтом, позволяя зрителям получать видео самого высокого качества, в зависимости от уровня, который может поддерживать их сеть.
WebRTC — тоже проект с открытым исходным кодом, целью которого является доставка потоковой передачи с откликом в реальном времени. Первоначально разработанный исключительно для чат-приложений с использованием VoIP, он стал популярен в приложениях видеочатов и конференций после того, как его купил Google. Некоторые из наиболее распространенных сегодня потребительских приложений, такие как Google Meet, Discord, Houseparty, Gotomeeting, WhatsApp и Messenger, используют именно протокол WebRTC. Что делает WebRTC уникальным, так это то, что он базируется на потоковой передаче пирингового типа. Такой способ можно назвать предпочтительным решением, если для потоковой передачи необходима малая задержка.
Надежность и безопасность передачи (SRT)
SRT — еще один протокол с открытым исходным кодом, разработанный поставщиком технологий потоковой передачи Haivision. Этот протокол является предпочтительным для членов SRT Alliance: группы компаний, в которую входят поставщики технологий и телекоммуникаций. Основными преимуществами, которыми славится SRT, можно назвать безопасность, надежность, высокий уровень совместимости и потоковая передача с малой задержкой. SRT может передавать потоковое видео высокого качества, даже если сетевые условия нестабильны. Он также не зависит от одного кодека, что позволяет использовать его с любыми аудио- и видеокодеками.
Протокол для обмена сообщениями в реальном времени (RTMP)
RTMP — это протокол, который уже многим известен. Он был разработан Macromedia (ныне известной как Adobe) для передачи аудио- и видеофайлов между потоковым сервером и Adobe Flash Player. Но с постепенным отказом от Flash в 2020 году его использование стало меньше связано с доставкой видео-контента, и больше для загрузки прямых трансляций на платформу через кодировщики с поддержкой RTMP. Это означает, что видеопоток от кодировщика отправляется на платформу потоковой передачи по протоколу RTMP, а затем доставляется конечному пользователю по обычному протоколу HLS.
Стриминговый протокол для работы в реальном времени (RTSP)
RTSP — еще один устаревший протокол, который был разработан для индустрии развлечений и в основном используется для установления и управления мультимедийными сеансами между конечными точками. Хотя он похож на протокол HLS, сам по себе он не помогает передавать потоковые данные в реальном времени. Для выполнения своих задач потоковой передачи серверы RTSP должны работать вместе с RTP и другими протоколами. Хотя он поддерживает потоковую передачу с малой задержкой, проблемой может быть несовместимость с большинством распространенных устройств и браузеров. Можно воспринимать его, как протокол, который способен доставлять потоковую передачу с малой задержкой избранной группе небольшой аудитории с выделенного сервера. Из-за того, что большинство IP-камер по-прежнему поддерживают RTSP, он по-прежнему остается стандартом, используемым в системах слежения и видеонаблюдения.
Что следует учитывать при выборе протокола потоковой передачи видео?
Выбор протокола потоковой передачи видео зависит от определенных факторов, которые могут оказаться важными для нужд вашего бизнеса. Вы можете захотеть охватить как можно более широкую аудиторию или свести к минимуму уровень задержки. Конечно, нужно обращать внимание на безопасность и конфиденциальность потоков. Ниже приводится примерное руководство о том, как сделать выбор на основе этих факторов.
- Конфиденциальность и безопасность Если самой главной задачей является обеспечение целости и сохранности стримов на пути к конечному пользователю, стоит использовать протокол, обеспечивающий функции безопасности. Большинство протоколов, включая широко используемый стандарт HLS, обеспечивают безопасную потоковую передачу, но SRT — это протокол с лучшими в своем классе функциями безопасности и конфиденциальности.
- Совместимость Если есть задача охватить как можно более широкую аудиторию потоковым контентом, подойдет протокол, совместимый с большинством устройств, платформ и браузеров. HLS — пожалуй, лучший вариант в этом случае. Его можно даже выбрать протоколом в качестве решения по умолчанию, если возникают какие-то сомнения.
- Задержка HLS обеспечивает самый широкий охват для потоковой передачи, но создает большую задержку в процессе передачи. RTMP обеспечивает потоки с низкой задержкой, но не совместим с видеоплеерами HTML5. SRT поддерживает потоки с низкой задержкой, а WebRTC обеспечивает задержку в реальном времени. Если выбирать один из этих вариантов, стоит обратить внимание, что под угрозой может оказаться охват аудитории, поскольку эти протоколы не так широко поддерживаются в среде потоковых технологий. Если вы не можете пойти на компромисс ни в охвате, ни в задержке, один из вариантов выхода в такой ситуации — использование протокола HLS. Таким образом, Вы принимаете решение в пользу ускорения мультимедиа контента и сможете обеспечить потоковую передачу со сверхнизкой задержкой.
- Адаптивный битрейт Как обсуждалось ранее, адаптивный битрейт позволяет обеспечить наилучшее возможное качество видео с учетом возможностей сети, устройства и программного обеспечения конечного пользователя. HLS и MPEG-DASH — это протоколы, которые поддерживают эту функцию. Если у вас в планах разработка собственной видеоплатформы, необходимо заранее учесть расходы, связанные с инфраструктурой, транскодированием, доставкой и воспроизведением контента. В таком случае стоит рассмотреть облачную систему управления контентом VoD или универсальное решение для потоковой передачи в реальном времени, которое объединяет прием, управление, обработку, публикацию и другие аспекты потоковой передачи видео на одной платформе.
Весь необходимый функционал доступен в нашем личном кабинете. Зарегистрируйтесь для проведения теста или обратитесь к менеджеру для получения дополнительной консультации.
¶ Стриминг в реальном времени
То, что показывает YouTube в прямых трансляциях — это не совсем реальное время. Достаточно посмотреть трансляцию какого-нибудь футбольного матча и его интернет-версию: гол в интернете случается на полминуты-минуту позже. Это HLS, HDS, MPEG-DASH — способы доставки потоков для массовой аудитории с заметной буферизацией и поверх протокола HTTP, то есть, без существенных отличий от обычных веб-страниц.
Но видеопроизводство и доставка контента требуют передачи если не в реальном времени, как в аналоговом телевидении, то хотя бы с допустимой задержкой.
¶ Допустимая задержка
- В телефонии принято считать реальным временем задержку 200 мс . Считается, что задержки меньше этого значения человек не замечает.
- В телевидении режиссер будет негодовать, если рассинхронизация между потоками будет превышать 1 кадр . При 25 кадрах в секнду это 40 мс . Рассинхронизация изображения и звука в 2-3 кадра — это плохо, но возможно, большую задержку увидит даже нетренированный зритель.
- В IP видео общепризнанных ориентиров нет, но ни 40, ни 120, ни 200 мс для технологий, работающих поверх обычных компьютерных сетей, недостижимы в общем случае. Нам придется работать с задержками 250-500 мс . Такие задержки доставки потоков дают IP-камеры RTSP. Но и на видеовыходе они тоже дают задержку — большинство цифровых камер в принципе работают не совсем в реальном времени.
¶ Рабочий процесс
На рисунке ниже показан путь от камеры до зрителя, режиссера (на микшере) и оператора (если камера управляется удаленно через веб-инструменты. Это частный случай, в общем можно назвать больше протоколов и вариантов управления. Но рассмотрим именно его, тем более, что он реализован в МИЭМе.
Потоковый
микшер
Стример
Стриминговая платформа
Пользователь
Оператор в
веб / мобильном приложении
Медиасервер
RTSP камера
Viewer does not support full SVG 1.1
Каждый этап задействует свои протоколы. В этот раз рассмотрим получение потоков с источников (здесь это камера) и передачу выходного потока (эфирной программы) на стриминговую платформу. В качестве такой платформы по умолчанию в этом курсе будем рассматривать Youtube, но на его месте может быть и VK, OK, Facebook, Twitch и т.д. Можно запустить и собственный сервер. Обобщенно всё стриминговое производство описывается так:
Contribution
Distribution
Processing
Viewer does not support full SVG 1.1
- Capture — создать потоки на источниках (камерах, кодерах)
- Contribution — собрать потоки с источников, доставить их в микшер
- Processing — обработка, линейный монтаж, титрование, кодирование для стриминга, управление источниками
- Distribution — отправить выходной поток (программу) на платформу, с нее раздать зрителям.
- Consuming — получение зрителями потоков со стриминговой платформы.
¶ RTMP vs RTSP
RTSP — Real-Time Streaming Protocol. 1998
RTMP — Real-Time Messaging Protocol. 2009, но использовался ранее
В нашем частном (!) случае мы рассматриваем в качестве источников RTSP устройства: это камеры, кодеры или программные серверы потоков RTSP.
¶ RTSP:
- Протокол включает в себя два протокола: медиаданные передаются по RTP, а команды по RTCP.
- Сервером выступает источник медиа, к нему подключаются клиенты-«зрители».
- Поток может быть защищен, обычно логин и пароль берутся из пользовательских данных на устройстве (камере, кодере).
- Передача потока происходит по запросу клиента. По аналогии с видеоплеером с пультом управления: зритель подает команду, плеер выполняет указанное действие.
- Источник в таком случае должен быть доступен по IP. То есть, нужно иметь «белый адрес» в сети.
- Порт по умолчанию для RTSP: 554, может быть и TCP, и UDP.
- Обычно у RTSP устройств работает автообнаружение в локальной сети в пределах своего сегмента. Используется Web Service Discovery, а для этого требуется multicast.
- Устройства RTSP обеспечивают минимальную задержку доставки потоков среди всех рассматриваемых протоколов. Быстрее работает только захват веб-камер или сигналов от HDMI/SDI устройств, но оба эти случая не относятся к работе с сетевыми потоками от источников.
То есть, RTSP-камеры бесполезны, если мы не можем «достучаться» до них по сети. Например, если такая камера находится в локальной сети, снаружи она доступна только если:
- На NAT проброшен порт. Если таких камер несколько, то пробросить придется несколько разных портов.
- Вы подключаетесь в VPN и образуете тоннель в эту локальную сеть.
Пример бесполезности работы с RTSP камерой: вы можете поставить соответствующее приложение на ваш смартфон, но работать с такой камерой вы сможете только внутри локальной сети. Например, постримить народные гуляния с улицы не получится — у вас нет прямого IP адреса в сети мобильного оператора.
Как все-таки решить задачу стриминга RTSP из общественных сетей: Если подключиться к VPN, то ваш поток можно будет увидеть на микшере — у смартфона будет прямой адрес и даже в локальной сети.
Зачем может понадобиться RTSP стриминг, если любая стриминговая платформа предлагает приложения RTMP-стриминга без всяких VPN? Дело в том, что отправить поток — это половина дела. Нужно его ещё принять. Если вы используете известные платформы, то туда вы отправите, а принять этот же поток для монтажа на микшере уже не сможете. Если даже поставить свой сервер RTMP, вы получите задержку от двух секунд, причем, эта задержка может меняться по ходу трансляции из-за накапливающихся ошибок и других помех.
¶ RTMP
Этот протокол изначально был закрытым проприетарным протоколом Adobe Flash-медиасервера. Здесь важно не путать Flash как технологию графики и анимации в браузерах и Flash Video (FLV), которое по сей день применяется для доставки видеопотоков.
Flash-анимацию официально похоронили в 2020, причём, хоронили почти 10 лет, начиная с мобильных устройств, где с ней было особенно много проблем.
В 2009 году Adobe опубликовала спецификацию протокола, но хитро — она была неполная. Существуют разные серверы, в т.ч. модуль для прокси-сервера NGINX, с ним имеет смысл познакомиться, если хотите работать со стримингом.
Что нужно знать про RTMP:
- Сервером в RTMP является получатель потока. И сервер ничего не знает о том, кто на него посылает поток. Просто есть адрес сервера, имя потока и, по желанию, логин и пароль. Если эти данные скомпрометированы, то передавать на ваш канал могут другие источники — это потенциальная опасность. Сервер по умолчанию работает на порту 1935.
- Клиент при этом может не иметь прямого адреса и потому не возникает проблем со стримингом со смартфона из любой сети.
- Внутри своей экосистемы Flash видео работало весьма быстро: задержки не превышали задержку междугородней сотовой связи (она, конечно, больше 200 мс). Но при работе с веб-плеерами или микшерами задержки редко бывают меньше двух секунд.
- Структура Flash Video не гарантирует одинаковую длительность кадров. Синхронизация потоков там возможна только по стечению обстоятельств. То есть, для однокамерной съёмки без надобности в обратной связи этот способ передачи потоков подходит, но не для многокамерной съемки или передачи, требующей диалогового формата.
Виды получения видео в браузере
7 способов отобразить видео с RTSP IP-камеры на веб-странице и 2 в мобильном приложении
Блог компании Flashphoner, Разработка веб-сайтов, Разработка мобильных приложений, Разработка под Android, Разработка под iOS
Содержание
В этой статье покажем 7 технологически разных способов отображения видеопотока с IP-камеры с поддержкой RTSP на web-странице браузера.
Браузеры, как правило, не поддерживают RTSP, поэтому поток будет конвертироваться для браузера через промежуточный сервер.
RTMP протокол браузеры не поддерживают, но его поддерживает старый добрый Flash Player, который работает неплохо, хоть и не во всех браузерах, и может отобразить видеопоток.
Код плеера в этом случае будет построен на Action Script 3 и выглядеть примерно так:
var nc:NetConnection = nc.connect(«rtmp://192.168.88.59/live»,obj);
var subscribeStream:NetStream = new NetStream(nc);
subscribeStream.play(«rtsp://192.168.88.5/live.sdp»);
rtmp://192.168.88.59/live — это адрес промежуточного сервера, который заберет RTSP видеопоток с камеры и конвертирует его в RTMP
Немного избыточный вариант кода плеера на Flex и AS3 доступен здесь.
Выглядит это так:
Способ 2 — RTMP с оберткой HTML5
Желающих кодить на Action Script 3 все меньше. Специально для этого придуман способ с HTML5 оберткой, которая позволяет управлять RTMP-плеером из JavaScript. В этом случае флэшка подгружается на HTML-страницу только для того чтобы отобразить картинку и выдать в динамики звук.
Полный код плеера находится здесь. А выглядит это так:
Способ 3 — RTMFP
Протокол RTMFP также работает внутри флэш плеера. Разница с RTMP в том, что RTMFP работает поверх протокола UDP и тем самым является более пригодным для получения трансляции с низкой задержкой.
Код плеера на AS3 в этом случае полностью идентичен используемому в RTMP, добавлена одна буква F в строке протокола подключения к серверу.
var nc:NetConnection = nc.connect(«rtmfp://192.168.88.59/live»,obj);
var subscribeStream:NetStream = new NetStream(nc);
subscribeStream.play(«rtsp://192.168.88.5/live.sdp»);
Для порядка дадим скриншот с RTMFP
Способ 4 — RTMFP c оберткой HTML5
Этот способ идентичен пункту 2, с той разницей, что мы при инициализации в JavaScript устанавливаем RTMFP протокол для использования в нижележащей флэшке (swf-объекте).
Способ 5 — WebRTC
В данном случае Flash не используется совсем и видеопоток проигрывается средствами самого браузера, без использования сторонних плагинов. Это работает и в Android Chrome и Android Firefox — мобильных браузерах, где Flash не установлен. WebRTC дает самую низкую задержку — менее 0.5 секунды.
Код плеера тот же:
Автоматически определяется поддержка WebRTC, и если поддерживается то поток играет по WebRTC.
Способ 6 — Websockets
WebRTC и Flash не покрывают все браузеры и платформы. Например, в браузере iOS Safari эти технологии не поддерживаются.
На iOS Safari можно доставить видеопоток по транспорту Websocket (TCP соединению между браузером и сервером). В этот туннель можно завернуть сконвертированный с RTSP видеопоток. После того, как бинарные данные придут их можно декодировать с помощью JavaScript и отрисовать на Canvas HTML5-элементе.
Именно этим занимается Websocket — плеер при работе в браузере iOS Safari, а его код снаружи выглядит также:
Это чем-то похоже на подход с флэшкой, когда под HTML5 лежит swf-элемент. В данном случае, под HTML5-страницей лежит не swf-объект, а JavaScript-приложение, которое тянет данные по вебсокетам, декодирует и отрисовывает на Canvas в нескольких потоках.
Так выглядит RTSP поток на Canvas в браузере iOS Safari
При конвертации RTSP в HLS, видеопоток разбивается на сегменты, которые благополучно скачиваются с сервера и отображаются в HLS-плеере.
В качестве HLS-плеера мы используем video.js. Код плеера можно скачать здесь.
Как выглядит плеер:
Способ 8 — Android приложение, WebRTC
Приложение забирает поток с сервера по WebRTC. Задача сервера в этом случае — сконвертировать RTSP в WebRTC и скормить мобильному приложению.
Java-код плеера для Android находится здесь и выглядит так:
SessionOptions sessionOptions = new SessionOptions(«wss://192.168.88.59:8443»);
Session session = Flashphoner.createSession(sessionOptions);
StreamOptions streamOptions = new StreamOptions(«rtsp://192.168.88.5/live.sdp»);
Stream playStream = session.createStream(streamOptions);
playStream.play();
Тестовое мобильное приложение плеера можно установить из Google Play, а исходники приложения скачать здесь.
Так выглядит воспроизведение RTSP потока по WebRTC на планшете Asus под Android: