Протокол rtsp что это простыми словами
Как получить RTSP поток с IP-камеры
Установка IP камеры — удобный способ получения картинки в любом месте, где присутствует подключение к интернету. Но для работы с видеопотоком необходим соответствующий инструментарий. Существуют различные варианты поддерживаемых IP камерами протоколов трансляции, и один из самых удобных среди них — RTSP.
Что такое RTSP
Аббревиатура расшифровывается как Real Time Streaming Protocol, или потоковый протокол реального времени. Это решение прикладного уровня для работающих с мультимедийным контентом систем. Оно позволяет удаленно контролировать поток информации с медиасервера (которым может выступать IP камера), отправлять команды управления этим потоком. Также, если на сервере хранятся файлы записей, RTSP обеспечивает к ним доступ.
Сжатие в рамках RTSP не выполняется. Транспортные протоколы и способ инкапсуляции передаваемой информации он тоже не устанавливает. Упрощенно процесс выглядит следующим образом:
По умолчанию сервер RTSP работает на порту 544. Захват видео и звука можно выполнять с помощью таких программ, как плееры VLC или Windows Media Player, и иных клиентов с поддержкой протокола. Существуют также веб-приложения и программные решения для трансляции потока в интернет (например, стриминга на YouTube).
Как получить поток RTSP с камеры
Чтобы просматривать видео и захватывать звук посредством этой технологии, необходима поддержка RTSP на стороне камеры. Этот протокол поддерживают многие образцы имеющихся на рынке устройств, но в документации возможность описана не всегда.
Если поддержка заявлена, то в инструкции будут прописаны настройки для доступа к трансляции. Они представляют собой ссылку для подключения в следующем формате:
Здесь rtsp — указание на протокол подключения, addr — IP-адрес камеры. Через двоеточие указан порт. Последний может отличаться, если в настройках указан отличный от «дефолтного».
Перед выполнением дальнейших инструкций рекомендуем прочитать как узнать IP камеры видеонаблюдения.
Далее следуют user и password — логин пользователя и пароль для подключения (их может и не быть). После них указываются дополнительные параметры, который у разных камер могут отличаться.
Как узнать RTSP адрес
Ссылка может находиться в документации или явно указываться в веб-интерфейсе устройства. Если известно, что камера точно поддерживает RTSP, но параметры нигде явно не указаны, их придется выяснять:
Для последнего потребуется ПО Onvif Device Manager, компьютер под управлением Windows и сама камера.
Важно: она и ПК должны находиться в одной сети.
Device Manager умеет конфигурировать видеосервер, захватывать видео и так далее, но самая важная функция этой программы в данном случае — WS-Discovery, обнаружение устройств в сети.
Когда вы скачали и поставили программу, нужно сделать следующее:
Смотрим видео через RTSP
Самый простой способ получить rtsp поток с ip камеры — использовать проигрыватель VLC. В нем достаточно пройти в пункт меню «Медиа — Открыть URL…», перейти в появившемся диалоге на вкладку «Сеть» и вставить в строку сетевого адреса rtsp-ссылку.
Для стриминга в интернет, существуют различные способы. Один из самых доступных — использовать связку VLC и программы OBS Studio, это бесплатное и достаточно простого решения.
Существуют также онлайн-сервисы вывода изображения в интернет, например, webcam.io, и прочие. Спецификации протокола открыты, поэтому специалисты могут написать и собственный проигрыватель RTSP.
Где купить IP-видеокамеру
Видео по теме
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
RTSP (Real Time Streaming Protocol)
Протокол (RTSP) дает возможность клиенту запрашивать живые или предварительно записанные потоки с мультимедийных серверов, подобно тому, как HTTP позволяет клиентам выдавать запросы к Web-cepверам. Фактически RTSP перенял большую часть своего синтаксиса и семантики от НТТР/1.1, поскольку формалыю оба протокола выполняют схожие функции. Сходство подчеркивает общий характер многих реализованных в HTTP концепций. Однако протоколы имеют ряд ключевых отличий, которые связаны с уникальными требованиями для мультимедийных потоков и ограниченностью возможностей НТТР/1.1 по передаче мультимедийных данных.
Содержание
Управляющие команды протокола
По синтаксису и операциям протокол RTSP похож на HTTP. Однако между протоколами RTSP и HTTP есть ряд существенных различий. Одно из основных заключается в том, что в первом и сервер, и клиент способны генерировать запросы. Например, видеосервер может послать запрос для установки параметров воспроизведения определенного видеопотока. Далее, протоколом RTSP предусматривается, что управление состоянием или связью должен осуществлять сервер, тогда как HTTP вообще никакого отношения к этому не имеет. Наконец, в RTSP данные могут передаваться вне основной полосы (out-of-band) другими протоколами, например RTP, что невозможно в случае HTTP. RTSP-сообщения посылаются отдельно от мультимедийного потока. Для них используется соединение по специальному порту, по умолчанию с номером 554.
Запрос на сервер посылается в текстовом виде в формате: «метод абсолютный_адрес контент версия_протокола«. Вместе с запросом могут быть переданы дополнительные служебные поля (на новых строчках запроса).
Пример запроса: «PLAY rtsp://server/path/test.mpg RTSP/1.0«
Options
Возвращает список поддерживаемых методов (OPTIONS, DESCRIBE и т.д.)
Describe
Запрос описания контента, описывает каждый трек в формате SDP
Setup
Запрос установки соединений и транспорта для потоков.
Teardown
Record
Запрос на записывание контента сервером
GET_PARAMETER
Запрос GET_PARAMETER извлекает значение параметра, заданного в URI.
Русские Блоги
Подробный протокол rtsp
Подробный протокол rtsp
1 Обзор
1.1 Введение в RTSP
RTSP (протокол потоковой передачи в реальном времени), протокол потоковой передачи в реальном времени, является одной из систем протоколов TCP / IP. Уровень приложения Протокол, стандарт IETF RFC, представленный Колумбийским университетом, Netscape и RealNetworks. Протокол определяет, как приложения типа «один ко многим» могут эффективно передавать мультимедийные данные по IP-сети. RTSP архитектурно превосходит RTP и RTCP, и он использует TCP или RTP завершают передачу данных.
Стек протоколов службы потокового мультимедиа
Его синтаксис и работа аналогичны HTTP 1.1, но он не особо подчеркивает синхронизацию времени, поэтому может допускать задержки в сети.
HTTP по сравнению с RTSP, * HTTP передает HTML. HTTP-запрос отправляется клиентом, а сервер отвечает * RTSP передает мультимедийные данные. При использовании RTSP и клиент, и сервер могут отправлять Запрос, т.е. RTSP может быть Двусторонний оф.
Как упоминалось ранее, позволяя одновременное управление запросами нескольких потоковых данных (многоадресная передача), помимо сокращения использования сети на стороне сервера, он также поддерживает многосторонние видеоконференции (видеоконференции). Поскольку он совместим с HTTP1. Режим работы 1 аналогичен, поэтому функция кеширования прокси-сервера
также применима к RTSP, а поскольку RTSP имеет функцию перенаправления, сервер, предоставляющий услугу, может переключаться в соответствии с реальной ситуацией загрузки, чтобы избежать чрезмерной нагрузки. Нагрузка сосредоточена на одном сервере, что вызывает задержку.
Этот протокол используется в модели C / S. Это текстовый протокол, используемый для установления и согласования сеансов потоковой передачи в реальном времени между клиентом и сервером.
Поддерживаются следующие операции протокола: (1) Извлечение мультимедиа с сервера мультимедиа: пользователи могут отправлять описание презентации через HTTP или другие методы. Если презентация является многоадресной, презентация включает Адрес многоадресной рассылки и порт непрерывного носителя. Если презентация отправляется пользователю только через одноадресную рассылку, пользователь должен предоставить адрес назначения для безопасности. (2) Медиа-сервер приглашает принять участие в конференции: медиа-сервер может быть приглашен для участия в текущей конференции или воспроизведения Медиа, или запись части, или всего этого. Этот режим очень полезен в распределенных образовательных приложениях. Несколько участников собрания могут по очереди нажать кнопку дистанционного управления. (3) Добавить носитель в готовую лекцию: если сервер сообщает пользователю, что он доступен Дополнительный медиа-контент особенно полезен для живых лекций. Как и в HTTP / 1.1, запросы RTSP могут обрабатываться прокси, каналом и кешем.
1.2 Особенности договора
2 Детали соглашения
2.1 Типичный процесс взаимодействия с rtsp
C означает клиент rtsp, S означает сервер rtsp
Вышеупомянутый процесс является стандартным и удобным процессом rtsp, но фактические требования не обязательно являются пошаговыми. Среди них шаги 3 и 4 обязательны!
Первый шаг, если сервер и клиент согласны с тем, какие методы доступны, запрос опции можно пропустить.
Второй шаг: если у нас есть другие способы получить информацию описания инициализации носителя (например, HTTP-запрос и т. д.), нам не нужно выполнять его с помощью запроса описания в rtsp.
На пятом шаге вы можете решить, нужен ли он, в соответствии с требованиями системы.
2.2 Формат сообщения RTSP
2.3 Определение метода
Некоторые конструкции брандмауэра и другие среды могут требовать от сервера вставки методов RTSP и потоковых данных. Поскольку вставка усложнит работу клиента и сервера и увеличит дополнительные накладные расходы, этого следует избегать, если в этом нет необходимости. Сделать. Вставить двоичные данные можно только тогда, когда RTSP передается через TCP. Потоковые данные (например, пакеты RTP) используют символ ASCII ‘ ʹПакет, За ним следует однобайтовый идентификатор канала., Далее следует длина инкапсулированных двоичных данных, Двухбайтовое целое число. Потоковое видео отслеживается, Нет CRLF, Но включая заголовок протокола высокого уровня. КаждыйБлок содержит блок данных протокола высокого уровня.
Если для передачи выбран RTP, информация RTCP также вставляется сервером через TCP-соединение. По умолчанию пакеты RTCP отправляются по первому доступному каналу выше, чем канал RTP. Клиент может Явно запрашивайте пакеты RTCP на другом канале. Это можно сделать, указав заголовок передачи для вставки двух каналов в параметр. Когда два или более потоков пересекаются, для получения синхронизации требуется RTCP. Более того, это когда сеть Настройками нужно управлять через TCP-соединения. Это обеспечивает удобный способ через RTP / RTCP и, когда это возможно, передает через UDP.
2.4 Определение заголовка сообщения
Заголовок сообщения определяется следующим образом. Описание таблицы:
Общий анализ заголовка:
2.5 Код состояния
Код состояния стандартного сообщения RTSP (указывается в первой строке ответного сообщения)
3 Примеры часто используемых методов в rtsp
В этом разделе объясняется типичный процесс взаимодействия, описанный выше.
Цель состоит в том, чтобы получить доступные методы, предоставляемые сервером:
Информация об ответе сервера включает некоторые предоставленные методы, например:
C инициирует запрос DESCRIBE к S, чтобы получить информацию описания сеанса (SDP):
Сервер отвечает некоторой описательной информацией (sdp) для этого сеанса:
Клиент напоминает серверу о необходимости установить сеанс и определяет режим передачи:
Информация об ответе сервера:
Клиент отправляет запрос на воспроизведение:
Информация об ответе сервера:
Клиент инициирует запрос на отключение:
Вышеупомянутые методы являются наиболее часто используемыми в интерактивном процессе, и есть другие важные методы, такие как get/set_parameter,pause,redirect и многое другое
4 Обзор протокола SDP
4.1 Введение
Он использует различные соответствующие транспортные протоколы, включая протокол уведомления о сеансе (SAP), протокол инициации сеанса (SIP), протокол потоковой передачи в реальном времени (RTSP), электронную почту с расширенным протоколом MIME и гипертекст. Протокол передачи (HTTP).
Протокол SDP также является текстовым протоколом, поэтому может быть обеспечена масштабируемость протокола, и он имеет широкий спектр приложений. SDP не поддерживает согласование содержимого сеанса или кодирование мультимедиа, поэтому он используется только для описания мультимедийной информации в потоковом мультимедиа. Согласование среды передачи должно быть реализовано с помощью RTSP.
4.2 Формат протокола SDP
4.3 Примеры протокола SDP
Формат тела сообщения:
v=0// Банк указывает версию договора
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4// строка содержит параметры, относящиеся к владельцу сеанса
s=SDP Seminar// Указываем заголовок этого разговора или название разговора
i=A Seminar on the session description protocol// Описание сеанса
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps// URI сеанса, через который вы можете узнать больше о сеансе
[email protected] (Mark Handley)// EMIAL адрес лица, ответственного за сеанс
c=IN IP4 224.2.17.12/127// Строка C содержит информацию о соединении, установленном для мультимедийного сеанса, которая указывает IP-адрес, используемый настоящим медиапотоком
t=2873397496 2873404696// указывает время начала и время окончания сеанса
m=audio 3458 RTP/AVP 0 96 97// строка m также называется строкой мультимедиа, которая описывает тип мультимедиа и другую информацию, поддерживаемую отправителем.
m=video 3400 RTP/AVP 98 99// Строка m также называется строкой мультимедиа, которая описывает типы мультимедиа и другую информацию, поддерживаемую отправителем
a=rtpmap:98 MPV
a=rtpmap:99 H.261
Как готовить RTSP на сайте в 2020 году, или почему кабаны не успеют убежать
RTSP — это простой сигнальный протокол, который уже много лет не могут ничем заменить, и надо признать, что не особо стараются.
Скажем, есть у нас IP камера с поддержкой RTSP. Всякий, кто щупал трафик акула-кабелем, расскажет, что там сначала идет DESCRIBE, потом PLAY, и вот полился трафик напрямую по RTP или завернутый в тот же TCP канал.
Типичная схема установки RTSP соединения выглядит так:
Понятно, что для браузеров поддержка RTSP протокола избыточна и нужна как собаке пятая нога, поэтому браузеры не спешат ее массово внедрять и вряд ли когда-то к этому придут. С другой стороны, браузеры могли бы создавать прямые TCP соединения, и это бы решило задачу, но тут все упирается в безопасность — где вы видели браузер, который дает скрипту напрямую использовать транспортные протоколы?
Но люди требуют потока в “любом браузере без установки дополнительного ПО”, а стартаперы пишут на своих сайтах “вам ничего не надо устанавливать — работает во всех браузерах из коробки”, когда хотят показать стрим с IP камеры.
В этой статье мы разберемся как этого достичь. А так как на дворе круглая цифра, придадим статье актуальности и навесим лейбл 2020, тем более, что так оно и есть.
Итак, какие технологии отображения видео на веб-странице нужно забыть в 2020 году? Flash в браузере. Он умер. Его больше нет — вычеркиваем.
Три годных способа
Инструменты, которые дадут смотреть видеопоток в браузере сегодня, это:
Что не так с WebRTC
Два слова: ресурсоемкий и сложный.
Ну какая же ресурсоемкость? — отмахнетесь вы, ведь сегодня процессоры мощные, память дешевая, в чем проблема? Ну, во-первых, это принудительное шифрование всего трафика даже если вам это не требуется. Во-вторых, WebRTC — сложная двухсторонняя связь и обмен фидбэками о качестве канала между пиром и пиром (в данном случае, между пиром и сервером) — в каждый момент времени рассчитывается битрейт, отслеживаются потери пакетов, принимаются решения по их досылке, и вокруг этого всего рассчитывается синхронизация аудио и видео, так называемый lipsync, чтобы губы спикера не расходились с его словами. Все эти вычисления, а также входящий на сервер трафик аллоцируют и освобождают гигабайты оперативной памяти в реальном времени и, если что-то пойдет не так, 256-гигабайтный сервер с 48 ядрами CPU легко уйдет в штопор несмотря на все гигагерцы, нанометры и DDR 10 на борту.
Получается стрельба по воробьям из искандера. Нам надо высосать всего лишь RTSP поток и показать его, а WebRTC говорит: да, вперед, но придется за это заплатить.
Чем хорош WebRTC
Задержка. Она действительно низкая. Если вы готовы заплатить производительностью и сложностью за низкую задержку, WebRTC — самый подходящий вариант.
Чем хорош HLS
Два слова: работает везде
HLS — это медленный вездеход в мире отображения Live-контента. Везде работает благодаря двум вещам: HTTP-транспорту и протекции Apple. Действительно, HTTP-протокол вездесущ, я чувствую его присутствие, даже когда пишу эти строки. Поэтому, где бы вы ни были и за каким бы древним планшетом ни серфили, HLS (HTTP Live Streaming) до вас доберется и доставит видео на ваш экран, будьте уверены.
И все бы хорошо, но.
Чем плох HLS
Задержка. Есть, например, проекты видеонаблюдения за стройкой. Объект строится годами, а в это время несчастная камера днем и ночью, 24 часа в сутки снимает строительную площадку. Это пример того, где не нужна низкая задержка.
Другой пример — кабаны. Реальные кабаны. Фермеры штата Огайо страдают от нашествия диких кабанов, которые как саранча поедают и вытаптывают урожай, угрожая тем самым финансовому благополучию хозяйства. Предприимчивые стартаперы запустили систему видеонаблюдения с RTSP-камер, которая в реальном времени наблюдает за угодьями и опускает ловушку при нашествии непрошенных гостей. В данном случае низкая задержка критична и, при использовании HLS (с задержкой 15 секунд), кабаны убегут до того, как ловушка будет активирована.
Еще пример: видео-презентации, в которых вам демонстрируют товар и ожидают оперативного ответа. В случае большой задержки, вам покажут товар в камеру, потом спросят “ну как?” и это дойдет только через 15 секунд. За 15 секунд сигнал может 12 раз сгонять до луны и обратно. Нет, такая задержка нам не нужна. Она больше похожа на показ предзаписанного видео, чем на Live. Но ничего удивительного нет, HLS так и работает: он пишет куски видео на диск или в память сервера, а плеер скачивает записанные куски. В результате и получается HTTP Live, который совсем не Live.
Почему так происходит? Повсеместная распространенность протокола HTTP и его простота выливаются в итоге в тормознутость — ну не предназначен HTTP был изначально для быстрого скачивания и отображения тысяч крупных кусков видео (HLS сегментов). Они, конечно, скачиваются и играются с хорошим качеством, но очень медленно — пока скачаются, пока сбуферизуются, пойдут на декодер, пройдут те самые 15 секунд и больше.
Здесь надо отметить, что Apple осенью 2019 анонсировала HLS Low Latency, но это уже другая история. Будем смотреть, что получилось, более детально позже. А у нас в запасе есть еще MSE.
Чем хорош MSE
Media Source Extension — это нативная поддержка воспроизведения пакетного видео в браузере. Можно сказать, нативный плеер для H.264 и AAC, которому можно скармливать сегменты видео и который не привязан к транспортному протоколу в отличии от HLS. По этой причине транспорт можно выбрать по протоколу Websockets. Иными словами, сегменты уже не скачиваются по древней технологии Request-Response (HTTP), а весело льются через Websockets соединение — почти прямой TCP канал. Это здорово помогает с уменьшением задержек, которые могут снижаться до 3-5 секунд. Задержка не супер, но подходящая для большинства проектов, не требующих жесткого реального времени. Сложность и ресурсоемкость тоже относительно невысокая — открывается TCP канал и по нему льются почти те же HLS сегменты, которые собираются плеером и помещаются на воспроизведение.
Чем плох MSE
Работает не везде. Как и WebRTC, проникновение в браузеры меньше. Особенно в непроигрывании MSE замешаны айфоны (iOS), что делает MSE малопригодным в качестве единственного решения для какого-либо стартапа.
Полностью доступен в браузерах: Edge, Firefox, Chrome, Safari, Android Browser, Opera Mobile, Chrome для Android, Firefox для Android, UC Browser для Android
В iOS Safari ограниченная поддержка MSE появилась совсем недавно, начиная с 13 версии iOS.
RTSP нога
Мы обсудили доставку по направлению видеосервер > браузер. Кроме этого, потребуются еще две вещи:
1) Доставить видео от IP камеры до сервера.
2) Конвертировать полученное видео в один из вышеописанных форматов / протоколов.
Здесь на сцену выходит серверная часть.
ТаТам… Web Call Server 5 (для знакомых просто WCS). Кто-то должен получить RTSP трафик, правильно депакетизировать видео, конвертировать его в WebRTC, HLS или MSE, желательно без пережатия транскодером, и выдать в сторону браузера в приличном, не испорченном артефактами и фризами виде.
Задача, на первый взгляд, несложная, но за ней скрывается столько подводных камней, китайских камер и нюансов конвертации, что жуть. В общем, не без хаков, но это работает, и работает хорошо. В продакшене.
Схема доставки
В итоге вырисовывается целостная схема доставки RTSP контента с конвертацией на промежуточном сервере.
Один из самых частых запросов наших индийских коллег “А можно? Напрямую без сервера?”. Нет, нельзя — нужна серверная часть, которая будет делать эту работу. В облаке, на железке, на corei7 на балконе, но без нее никак.
Вернемся к нашему 2020 году
Итак, рецепт приготовления RTSP в браузере:
Разложить на веб-странице.
Нет, еще не все
У пытливых нейронов обязательно возникнет вопрос “Как? Ну как это сделать? Как это будет выглядеть в браузере?”. Вашему вниманию представляется минимальный WebRTC плеер, сделанный на коленке:
1) Подключаем к web-странице основной API скрипт flashphoner.js и скрипт my_player.js который создадим чуть позже.
2) Инициализируем API в теле web-страницы
3) Кидаем на страницу div, который будет контейнером для видео. Укажем ему размеры и границу.
4) Добавляем кнопку Play, нажатие по которой будет инициировать коннект к серверу и начинать воспроизведение
5) Теперь создаем скрипт my_player.js – который будет содержать основной код нашего плеера. Описываем константы и переменные
6) Инициализируем API при загрузке HTML страницы
7) Подключаемся к WCS серверу через WebSocket. Что бы все работало правильно замените «wss://demo.flashphoner.com» на адрес своего WCS
8) Далее передаем два параметра: name и display: name — RTSP URL проигрываемого потока. display — элемент myVideo, в который будет смонтирован наш плеер. Здесь также укажите URL нужного вам потока, вместо нашего.
Сохраняем файлы и пробуем запустить плеер. Играет ваш RTSP поток?