Ртсп поток как настроить

Как получить 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, но параметры нигде явно не указаны, их придется выяснять:

1. На сайте разработчика.
2. Запросить напрямую у производителя или поставщика. Как правило, по запросу они такую информацию предоставляют, с этим нет проблем даже у китайских вендоров с AliExpress.
3. Распознать камеру с помощью протокола ONVIF, который поддерживается практически всеми моделями.

Для последнего потребуется ПО Onvif Device Manager, компьютер под управлением Windows и сама камера.

Важно: она и ПК должны находиться в одной сети.

Device Manager умеет конфигурировать видеосервер, захватывать видео и так далее, но самая важная функция этой программы в данном случае — WS-Discovery, обнаружение устройств в сети.

Когда вы скачали и поставили программу, нужно сделать следующее:

• запустить ее и нажать внизу кнопку Refresh. Начнется процесс поиска;
• когда камера обнаружится, выбрать в меню пункт Live Video;
• под картинкой будет адрес rtsp-ссылки, который можно скопировать для дальнейшего использования.

Смотрим видео через RTSP

Самый простой способ получить rtsp поток с ip камеры — использовать проигрыватель VLC. В нем достаточно пройти в пункт меню «Медиа — Открыть URL…», перейти в появившемся диалоге на вкладку «Сеть» и вставить в строку сетевого адреса rtsp-ссылку.

Для стриминга в интернет, существуют различные способы. Один из самых доступных — использовать связку VLC и программы OBS Studio, это бесплатное и достаточно простого решения.

Существуют также онлайн-сервисы вывода изображения в интернет, например, webcam.io, и прочие. Спецификации протокола открыты, поэтому специалисты могут написать и собственный проигрыватель RTSP.

Где купить IP-видеокамеру

Видео по теме

Источник

Как готовить 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 в браузере:

1. Взять свежий WCS (Web Call Server).
2. Добавить по вкусу: WebRTC, HLS или MSE.

Разложить на веб-странице.

Нет, еще не все

У пытливых нейронов обязательно возникнет вопрос “Как? Ну как это сделать? Как это будет выглядеть в браузере?”. Вашему вниманию представляется минимальный 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 поток?

Источник