Настройки 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-видеокамеру
Видео по теме
Как готовить 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 поток?
Настройки rtsp что это
My Account
Поиск
Последние записи
Последние комментарии
Категории
Что такое RTSP-ссылка и как
сформировать ее для устройств
Hikvision?
RTSP-протокол – это real time streaming protocol, то есть потоковый протокол реального времени. По сути, это узкоспециализированный протокол, использующийся для удалённого управления потока данных с сервера и работы с мультимедийными данными.
Протокол существует с 1998 года. Он не передает и не сжимает данные самостоятельно. Для передачи зачастую используется стандартный RTP-протокол (осуществляет передачу аудио- и видеоданных). Для RTSP-сообщений используется специальный порт, по умолчанию – 554.
Согласны, вышло немного запутанно. Теперь расскажем простым языком.
RTSP – что-то вроде пульта для телевизора, работающего через интернет. Сам ничего не показывает, но может включать картинку на экране, изменять опции вещания и т.д. Для этого используется RTSP-ссылка. Достаточно вставить её в проигрыватель, и можно наслаждаться видео. Заманчиво, не правда ли?
Следующее ПО может выступать в роли клиента RTSP:
Winamp (некоторые версии протокола),
Для оборудования Hikvision мы рекомендуем использовать VSPlayer, ПО от Hikvision. Ссылка для скачивания у нас на сайте.
Основная универсальная ссылка, которая подходит для камер и регистраторов:
rtsp — тип используемого протокола;
admin — имя учетной записи (в вашем случае укажите актуальное);
12345 – пароль используемой учетной записи (в вашем случае укажите актуальный);
192.168.200.11 — IP-адрес камеры (в вашем случае укажите актуальный);
554 — RTSP-порт камеры (по умолчанию 554, может быть изменен в настройках);
Еще раз о видеонаблюдении, камерах, RTSP, onvif. И «велосипед»!
Non-Interleaved Mode.
RTSP устанавливает связь и передает в камеру информацию о том «куда слать» данные (UDP порты).
Пример общения RTSP
Запоминаем
Transport: RTP/AVP;unicast;destination=10.112.28.33;source=10.112.28.231;client_port=49501-49502;server_port=6970-6971
Interleaved Mode.
Разница с Non-Interleaved Mode в том что все пакеты будут сыпаться в этот же порт.
Пример:
Запоминаем
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Теперь смотрим что и как.
Камеры шлют видео и аудио в разные RTP потоки. 2n поток — данные, 2n+1 поток — RTCP.
На видео нам идет 0 и 1 канал, на аудио 2 и 3 канал.
Теперь смотрим
Transport: RTP/AVP;unicast;destination=10.112.28.33;source=10.112.28.231;client_port=49501-49502;server_port=6970-6971
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
В первом случае указаны порты, во втором каналы.
С с Non-Interleaved Mode всё понятно. Просто RTP пакеты сыпятся в порты и их можно читать как то так:
DatagramPacket packet = new DatagramPacket(buffer, buffer.length);
s.receive(packet);
Проблемы начинаются с Interleaved mode.
По факту ни каких проблем быть не должно. По RFC мы ищем magic char «$», следующий байт — канал (он указывается в подключении 0-4 у нас) и 2 байта Length. Всего 4 байта.
Но есть не нормальные камеры. Например D-ling DCS-2103 «Досыпает» какие то данные после rtp пакета. frame дает размер 1448,
шлет 1448 фрейма, и после 827 байт какого то мусора. (Так делает Dlink DCS-2103 прошивка 1.00 и 1.20)
И такое у «них» происходит постоянно. Этим частенько страдают китайские камеры. Qihan (356) этим не страдали.
Кроме как пропускать этот мусор идей больше нет.
В RTP сыпятся полезные данные. При DESCRIBE RTSP возвращается SDP пакет
Примеры SDP (h264, mjpeg, mpeg4):
Прочитать про SDP
Так как мода была mjpeg и текущая на h264, то рассмотрим их.
С MJpeg всё предельно ясно. А вот с H264 начинаются различия в камерах.
Формат h264 состоит из блоков с NAL заголовками (7.4.1 NAL unit semantics).
Чтобы можно было декодировать h264 необходимо помимо данных самого h264 иметь данные SPS (Sequence parameter set) и PPS(Picture parameter set). Первый описывает последовательность, второй параметры картинки. Так как сам кодек h264 знаю очень плохо, то большего описания не будет. SPS имеет тип 7, PPS 8. Без них невозможно декодировать h264.
Самое интересное — Qihan шлет SPS и PPS прям в RTP пакетах, Dlink не шлет их в RTP пакетах. Но SPS и PPS шлется в SDP пакете в параметре sprop-parameter-sets в кодировке base64.
sprop-parameter-sets=Z2QAKK2EBUViuKxUdCAqKxXFYqOhAVFYrisVHQgKisVxWKjoQFRWK4rFR0ICorFcVio6ECSFITk8nyfk/k/J8nm5s00IEkKQnJ5Pk/J/J+T5PNzZprQCgDLSpAAAAwHgAAAu4YEAAPQkAABEqjve+F4RCNQ=,aO48sA==
Шлются они через запятую
Вариант декодирования.
Так как камеры 720p или 1080p, то в 1 RTP пакет ни jpeg фрейм, ни h264 фрейм не поместится, то они режутся на пакеты.
RTP Payload Format for JPEG-compressed Video
RTP Payload Format for H.264 Video
JPEG
RTP пакет содержит main JPEG header
а дальше может варьироваться от Type и Q
Для декодирования jpeg нужно знать или вычислить quantization tables.
В моих камерах quantization tables шли в стартовом пакете Jpeg, по этому они просто брались оттуда.
Все вычисления есть в RFC.
Последний пакет фрейма вычисляется по RTP header Marker bit. Если он 1, то это последний пакет фрейма.
Single NAL Unit Packet
Это как раз SPS и PPS. Type=7 или Type=8
Если фрейм h264 не влезает в RTP пакет (1448 байт), то фрейм режется на фрагменты. (5.8. Fragmentation Units (FUs))
Type = 28
Эти заголовки следуют сразу после RTP заголовка
Для декодера h264 NAL — нужная информация. Если идет фрагментация фрейма, то NAL нужно восстанавливать. (FU)
нужно взять первые 3 бита из FU indicator и слить их с 5 последними FU header.
Теперь самое главное — сохраняем поток.
Jpeg
NON_IDR_PICTURE — необходим для декодирования, «разделяем» фреймы. (h264) Тут нужно меня поправить, так как это просто «костыль» и обоснований пока нет. Просто работает.
Получается такой поток: 00000001 + SPS + 00000001 + PPS + 00000001 + NAL…
erlyvideo: 0,0,0,1 — это префикс AnnexB записи H264. Это не часть H264 NAL-юнита, а разделитель между юнитами.
ну и обработка «всего» этого
в 2х словах. Получаем RTSP Interleaved Frame (например Channel: 0x00, 1448 bytes), читаем 1448 байт, делаем writeRawToStream, полиморфизм делает свое дело.
Дальше это нужно обкатать.
Казалось бы что для поддержания потока RTSP нужно делать RTCP отчеты, но нет, всё оказалось проще
Dlink, Qihan, VLC просто «едят» GET_PARAMETER:
шлем его раз в 55 секунд и всё.
При простом просмотре генерируется m3u файл и кормится в VLC
4
При склеивании ffmpeg клеит, после запускается VLC
5
Программа нарезает поток на файлы, интервал задается в настройках
Что делает ffmpeg:
Клеит
«Нормализует» (просчитывает заголовки и т.д.)
На выходе куча файлов
6
По хорошему можно писать в любой OutputStream
Git hub
Дальнейшей жизни программы может и не быть. Возможно допишу когда нибудь RTP классы для звука. (так как увлекаюсь до сих пор SIP)
Ну и самое вкусное.
Есть стандарт видео наблюдения ONVIF
Есть профессиональные железки, которые с камерами работают только по нему.
Есть камеры, которые работают по нему (Qihan, он же Proline), а ссылки rtsp приходится гуглить.
Есть опенсорсный продукт Onvif device manager для управления подобными железяками.
Я же в программу добавил поддержку onvif без авторизации и с авторизацией.
7
Git hub
Если пройтись по ссылкам выше, то можно получить всю документацию по Onvif.
Ответ:
Дальнейшее общение по onvif без авторизации идет в этом же ключе.
А вот пример общения но уже с авторизацией
Т.е. нужно слать заголовок. (тестилось на D-link DCS-2103, остальные камеры без авторизации работали, китай).
и пароль (Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) ))
Всё было сделано в образовательных целях. Если есть вопросы и вдруг понадобиться более подробное описание чего либо — пишите.
Надеюсь кому нибудь пригодится.
PS Не надо писать в комментариях про организацию на большую букву «I». Их Server использует SQLite, SSL, avcodec (ffmpeg), а в папке \Resources есть божественный файлик с названием camera_list.json, но моя наглость не позволила его прикрутить к своей программе 🙂 Но я не видел у них поддержку Onvif, видимо потому что они выпускают «свои» камеры. UPDATED: см комментарии от ivideon
Если прикрутить к программе OpenVPN и OpenCV, то будет забавное решение и «велосипед»
Ну и вот вам полезная ссылка на базу ссылок потоков камер
Как определить параметры RTSP-потока с IP-камер?
Как определить параметры RTSP-потока с IP-камер?
Этот протокол не был создан исключительно для видеонаблюдения, он уже использовался в других секторах, где существует необходимость в передаче в реальном времени, был принят производителями устройств видеонаблюдения и стал стандартным протоколом.
Производители видеонаблюдения внедряют протокол RTSP на своих камерах, рекордерах и программном обеспечении, чтобы они были совместимы с другими устройствами, доступными на рынке.
Приобретая IP-камеру и сетевой видеомагнитофон от разных производителей, вы можете общаться с ними по этому универсальному протоколу.
Для настройки оборудования необходимо выяснить, какую команду RTSP следует использовать, и эту информацию можно найти в руководстве по продукту или в службе технической поддержки.
В инструкции, которое поставляется совместно с камерой видеонаблюдения, не всегда может присутствовать информация о протоколе RTSP, согласно которому устройство функционирует. Однако существует большое количество случаев, когда требуется использовать данный протокол, поэтому возникает необходимость узнавать его адрес.
Это необходимо в тех случаях, когда:
RTSP-протокол позволяет использовать несколько важных функций системы видеонаблюдения:
При этом открыть RTSP-поток не всегда просто, хотя и есть несколько вариантов, которые позволяют узнать RTSP поток видеокамеры, когда он не указан в соответствующем руководстве.
К примеру, большое количество IP-видеокамер, которые продаются в России, в своём составе имеют китайские элементы XMEye. Данные комплектующие есть и у некоторых отечественных производителей видеокамер для систем наблюдения. Но с этим проще. У таких камер следующий формат RTSP-потока: rtsp://192.168.132.32:554/user=admin&password=12345&channel=1&stream=0.cgi, где:
Если же в камере в установлены другие комплектующие, чтобы узнать RTSP-поток необходимо будет связаться с производителем или поставщиком данного устройства. Если же это невозможно, придется использовать специальное программное обеспечение.
Для этого нужно скачать программу под названием One Device Manager. После установки данный софт поможет узнать RTSP-адрес.
Большинство современных видеокамер обладает поддержкой onvif-протокола, поэтому при работе с ПО проблем возникнуть не должно. Однако нужно помнить, что для правильной работы необходимо подсоединить не только ноутбук или ПК, куда устанавливается программа, но и саму IP-камеру к одной и той же локальной сети.
Кроме того найти адреса RTSP-потоков можно в Интернете, но искать его нужно по фирме-производителю видеокамеры.
Найдя адрес RTSP-потока можно легко получить видеоинформацию с IP-камеры. Для этого нужно:
После этого нужно настроить переадресацию и пробросить порты на RTSP-порт с локальных портов видеокамеры. Затем проверить, есть ли поток с помощью VLC-плеера. Для этого нужно:
В общем, сложного ничего нет, но без данных в этой статье знаний не всегда получается сделать все правильно.