Как настроить и подключить ip камеру

UDP vs. TCP: A Quick Background

User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) are both core components of the internet protocol suite, residing in the transport layer. The protocols used for streaming sit on top of these. UDP and TCP differ in terms of quality and speed, so it’s worth taking a closer look.

The primary difference between UDP and TCP hinges on the fact that TCP requires a three-way handshake when transporting data. The initiator (client) asks the accepter (server) to start a connection, the accepter responds, and the initiator acknowledges the response and maintains a session between either end. For this reason, TCP is quite reliable and can solve for packet loss and ordering. UDP, on the other hand, starts without requiring any handshake. It transports data regardless of any bandwidth constrains, making it speedier and riskier. Because UDP doesn’t support retransmissions, packet ordering, or error-checking, there’s potential for a network glitch to corrupt the data en route.

Protocols like Secure Reliable Transport (SRT) often use UDP, whereas HTTP-based protocols use TCP.

Adapted from https://microchipdeveloper.com/tcpip:tcp-vs-udp

Процесс работы RTMP

Для воспроизведения потокового мультимедиа по протоколу RTMP необходимо выполнить следующие шаги: рукопожатие, установить соединение, установить поток и воспроизвести.

1. Рукопожатие

1. Рукопожатие начинается, когда клиент отправляет блоки C0 и C1. Сервер отправляет S0 и S1 после получения C0 или C1.
2. Когда клиент получает все S0 и S1, он начинает отправлять C2. Когда сервер получает C0 и C1, он начинает отправлять S2.
3. Когда клиент и сервер получают S2 и C2 соответственно, рукопожатие завершается.

2. Установите сетевое соединение (NetConnection).

1. Клиент отправляет серверу «connect» в командном сообщении, запрашивая соединение с экземпляром приложения-службы.
2. После того, как сервер получает сообщение с командой подключения, он отправляет клиенту протокольное сообщение «Размер подтверждения окна» (Window Acknowledgment Size) и одновременно подключается к приложению, указанному в команде подключения.
3. Сервер отправляет клиенту сообщение протокола установленной полосы пропускания.
4. После того, как клиент обработает сообщение протокола установленной полосы пропускания, он отправляет на сервер сообщение протокола размера подтверждения окна (Window Acknowledgment Size).
5. Сервер отправляет клиенту сообщение «Stream Begin» в управляющем сообщении пользователя.
6. Сервер отправляет «результат» (_result) в командном сообщении, чтобы уведомить клиента о состоянии соединения.

3. Установите сетевой поток (NetStream).

1. Клиент отправляет на сервер команду createStream в командном сообщении.
2. После того, как сервер получает команду «создать поток», он отправляет «результат» (_result) в командном сообщении, чтобы уведомить клиента о состоянии потока.

4. Играть

1. Клиент отправляет на сервер команду «play» (воспроизведение) в командном сообщении.
2. После получения команды воспроизведения сервер отправляет сообщение протокола ChunkSize.
3. Сервер отправляет «streambegin» в пользовательском управляющем сообщении, чтобы сообщить клиенту идентификатор потока.
4. Если команда воспроизведения выполнена успешно, сервер отправляет «статус ответа» NetStream.Play.Start и NetStream.Play.reset в командном сообщении, чтобы сообщить клиенту, что команда «play» выполнена успешно.
5. После этого сервер отправляет аудио и видео данные для воспроизведения клиенту.

Реализации

Сервер

• Darwin Streaming Server : версия QuickTime Streaming Server с открытым исходным кодом, поддерживаемая Apple.
• Фэн : Экономичный и средний потоковый сервер с упором на соответствие RFC.
• Сервер и клиент RTSP на основе GStreamer .
• Сервер Helix DNA : потоковый сервер RealNetworks . Поставляется как с открытым исходным кодом, так и с проприетарными версиями.
• Helix Universal Server : коммерческий сервер потоковой передачи RealNetworks для клиентов потокового мультимедиа RTSP, RTMP, iOS, Silverlight и HTTP.
• LIVE555 liveMedia / openRTSP : серверные и клиентские библиотеки C ++ с открытым исходным кодом, используемые в известных клиентах, таких как VLC и mplayer .
• Движение : бесплатное приложение для видеонаблюдения для Linux.
• Nimble Streamer поддерживает ввод с извлечением и объявлением по протоколу RTSP с чередованием вывода воспроизведения по протоколу TCP.
• pvServer : ранее называвшийся PacketVideo Streaming Server, это продукт для потокового сервера Alcatel-Lucent.
• QuickTime Streaming Server : потоковый сервер Apple с закрытым исходным кодом, который поставляется с Mac OS X Server.
• VideoLAN : медиаплеер с открытым исходным кодом и потоковый сервер.
• Wowza Streaming Engine : многоформатный потоковый сервер для RTSP / RTP, RTMP , MPEG-TS , ICY, HTTP ( HTTP Live Streaming , , Smooth Streaming , ), WebRTC
• В июне 2007 года YouTube внедрил мобильный веб- интерфейс, который обслуживает видео по этому протоколу.

Многие камеры видеонаблюдения / безопасности, часто называемые IP-камерами , также поддерживают потоковую передачу RTSP, особенно с профилями ONVIF G, S, T.

Клиент

• Астра
• cURL (начиная с версии 7.20.0–9 февраля 2010 г.)
• FFmpeg
• GStreamer
• JetAudio
• LIVE555 liveMedia / openRTSP : серверные и клиентские библиотеки C ++ с открытым исходным кодом, используемые в известных клиентах, таких как VLC и mplayer .
• Классический медиаплеер
• MPlayer
• MythTV через Freebox
• QuickTime
• Реальный игрок
• Skype
• Spotify
• Медиаплеер VLC
• Winamp
• Проигрыватель Windows Media
• xine
• ZoneMinder
• Motion_ (программное обеспечение для наблюдения)

WebRTC

As the speediest technology available, WebRTC delivers near-instantaneous voice and video streaming to and from any major browser. The framework was designed for pure chat-based applications, but it’s now finding its way into more diverse use cases.

Scalability remains a challenge with WebRTC, though, so you’ll need to utilize a solution like Wowza Streaming Engine or Wowza Streaming Cloud to reach a larger audience.

• Video Codecs: H.264, VP8, VP9
• Audio Codecs: Opus, iSAC, iLBC
• Playback Compatibility: Chrome, Firefox, and Safari support WebRTC without any plugin
• Benefits: Super fast and browser-based
• Drawbacks: Designed for video conferencing and not scale
• Latency: Sub-500-millisecond delivery

История

Протокол RTSP был разработан RealNetworks , Netscape и Колумбийским университетом . Первый проект был представлен в IETF в октябре 1996 года компаниями Netscape и Progressive Networks , после чего Хеннинг Шульцринн из Колумбийского университета представил «RTSP ‘» («RTSP prime») в декабре 1996 года. были объединены для стандартизации Рабочей группой по управлению многосторонними мультимедийными сеансами (MMUSIC WG) Инженерной группы Интернета (IETF), а дальнейшие проекты были опубликованы рабочей группой. Предлагаемый стандарт для RTSP был опубликован в RFC 2326 в 1998 году RTSP 2,0 опубликован в RFC 7826 в 2016 году в качестве замены RTSP 1.0. RTSP 2.0 основан на RTSP 1.0, но не имеет обратной совместимости, кроме как в механизме согласования базовой версии, и остается «предлагаемым стандартом».

Подключаем IP камеру к роутеру и к облаку по RTSP для записи видео

1451 просмотровИнтернет 24 Фев 2019

В статье опишу самый простой способ организации IP видеонаблюдения через интернет, и с помощью приложения, которое будет слать уведомления о движении.

Что нужно для этого?

• IP камера с поддержкой RTSP протокола;
• Роутер Mikrotik (можно любой роутер, в моем случае именно такой);
• Патчкорд нужной длинны;
• Пара POE инжекторов (для того, что бы пустить питание по патчкорду без лишних проводов);
• Блок питания на 12 Вольт и не меньше 1 Ампера для одной камеры;
• Перфоратор или дрель, в зависимости от того, куда будете крепить камеру;
• Белый IP адрес выданный провайдером;
• Облачный сервис для IP видеонаблюдения, который поддерживает RTSP проктокол;
• Сразу продумайте как прокладывать кабель, будете ли прятать соединения возле камеры в специальную коробочку, нужен ли кабель канал.

Подключили? Теперь нужно правильно настроить подключение камеры в роутере:

Присваиваем камере постоянный локальный IP адрес. В Mikrotik для этого нужно зайти в IP -> ARP. В открывшемся окошке нажимаем правой кнопкой на IP с MAC-адресом камеры и выбираем «Make Static».Так не будет меняться IP у камеры внутри нашей сети, если камеру отключить и снова подключить. Плюс по этому IP всегда будет доступ к настройкам камеры в веб-интерфейсе (т.е. просто внутри локальной сети, открываете браузер, вводите локальный IP камеры и попадаете в её настройки).

Следующий шаг, это сетевые настройки в самой камере

По назначенному локальному IP адресу камеры заходим в браузере в настройки камеры. Настройки многих камер открываются только в Internet Explorer, учтите это (кстати вот статья о том, как открыть Internet Explorer в Windows 10). У разных камер, разный интерфейс настроек. Просто покажу пример сетевых настроек своей камеры с кратким разъяснением.

Проверяем работу RTSP внутри локальной сети

После назначения постоянного IP вашей камере, можно проверить работу видеопотока через RTSP протокол внутри локальной сети. Для этого нужно знать какая правильная ссылка rtsp:// для камеры, так как у разных производителей камер по разному. Эту информацию можно найти в инструкции к камере, на сайте производителя камеры или погуглить.У моей камеры она выглядит так rtsp://admin:123456@192.168.88.

12:554/mpeg4 (admin — логин камеры, 123456 — пароль камеры, 192.168.88.12 — локальный IP камеры, 554 — порт RTSP в камере, почти во всех камерах именно такой, mpeg4 — видеокодирование, в моей камере оно указывается обязательно, в других камерах может указываться по другому).

Устанавливаем VLC плеер -> Запускаем и нажимаем вверху «Медиа» -> выбираем «Открыть URL…» -> в поле «Введите сетевой адрес» введите rtsp ссылку -> нажмите «Воспроизвести». Должна открыться трансляция с камеры.

Открываем видеопоток по RTSP из внешнего интернета

К камере должен быть доступ извне по RTSP протоколу. Для этого нужно сделать проброс портов на 554 порт камеры. Гуглите, что бы узнать как сделать проброс портов в конкретном роутере (обычно это не сложно). В Mikrotik это немного сложнее:

• Заходим в IP -> Firewall.
• Во вкладке Filter Rules нужно хотя бы временно отключить запрещающие фильтры. (это отдельная обширная тема в Микротиках, просто отключите всё, кроме верхнего правила, или погуглите о Filter Rules в Микротиках)
• Во вкладке NAT обязательно должно быть сначала правило маскарадинга, а после него правило переброса. Создадим их.
• Сначала маскарадинг: нажимаем Add -> во вкладке General в пункте Chain выбираем srcnat -> во вкладке Action выбираем masquerade -> нажимаем Apply и OK.
• Переброс на 554й порт камеры: нажимаем Add -> во вкладке General выбираем dstnat -> в пункте Protocol выбираем tcp -> в пункте Dst. Port пропишите 554 -> в пункте In. Interface выберите в какой порт подключен кабель интернета, зачастую это ether1 -> во вкладке Action в пункте Action выберите dst-nat -> в пункте To Addresses пропишите локальный IP камеры -> в пункте To Ports пропишите 554.

В итоге должно получится как на скриншоте:

Подключаем IP камеру к облачному сервису по RTSP протоколу

Сделав проброс 554 порта для видимости RTSP видеопотока во внешний интернет, можно подключить камеру к облачному сервису видеонаблюдения. Заодно проверим всё ли работает.Я выбрал сервис ipeye.ru, там простой интерфейс, бесплатная трансляция и недорогая видеозапись, плюс есть приложение оповещающее о движении и запись так же по движению. Главное, что поддерживает RTSP

Для чего нужен протокол RTSP?

Название протокола RTSP переводится управление в онлайн-режиме. Таким образом, Real Time Streaming Protocol помогает наладить управление потоковым видео онлайн. Данный протокол очень часто используется в IP-видеонаблюдении, поскольку там есть описание необходимых команд.

RTSP-протокол позволяет собственнику камеры слежения решать несколько важных функций:

• транслировать данные при помощи VLC;
• транслировать видео на свои ресурсы и площадки;
• настраивать NVR-видеорегистраторы;
• соединять камеру видеонаблюдения с виртуальным хранилищем;
• добавлять видеокамеру в мобильные приложения на базе Android или iOS.

При этом открыть RTSP-поток многим пользователям систем видеонаблюдения не очень просто и достаточно затруднительно.

Узнаем адрес RTSP камеры видеонаблюдения

Есть несколько вариантов, которые позволяют узнать RTSP поток видеокамеры, когда он не указан в соответствующей инструкции.

Большое количество IP-видеокамер, которые продаются в России, в своём составе имеют китайские элементы XMEye. Данные комплектующие можно заметить даже у отечественных производителей таких камер, как Vesta, HiQ, SVplus и подобных. Камера подобных моделей будет иметь следующий формат RTSP-потока:

rtsp://192.168.132.32:554/user=admin&password=12345&channel=1&stream=0.cgi

В данном адресе присутствуют такие составляющие, как:

• 192.168.132.32 – непосредственно IP-адрес устройства;
• 554 – порт протокола (по умолчанию он имеет номер 554, но этот параметр можно поменять в настройках устройства);
• admin – логин камеры видеонаблюдения;
• 12355 – пароль от логина пользователя.

В том случае, когда в IP-видеокамере присутствуют другие комплектующие, необходимо будет воспользоваться одним из двух перечисленных ниже вариантов.

Для начала нужно будет скачать программу под названием One Device Manager. После установки данный софт поможет узнать RTSP-адрес.

Как правило, большинство видеокамер обладает поддержкой onvif-протокола, поэтому при эксплуатации программного обеспечения затруднений возникнуть не должно. Важный нюанс – для правильно работы необходимо подсоединить ноутбук или компьютер, куда будет установлена программа, а также само IP-устройство к одной и той же локальной сети.

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

Как открыть RTSP-поток в видеокамере?

Когда адрес RTSP-потока становится известен владельцу системы слежения, он может получать видеоинформацию с IP-камеры. Для того, чтобы открыть трансляцию потокового видео, необходимо будет выполнить следующий перечень шагов:

• установить для видеокамеры постоянный IP-адрес и заказать его у поставщика интернета;
• перебросить на RTSP-порт локальные запросы, поступающие с видеокамеры;
• пройти проверку работоспособности.

Статический адрес можно настроить можно при помощи программы IP Hunter или же связаться с провайдером и попросить его обеспечить в качестве дополнительной опции постоянный адрес IP. После этого нужно настроить переадресацию и пробросить порты на RTSP-порт с локальных портов видеокамеры. Затем можно переходить к проверке потока.

Чтобы понять, обладает ли RTSP-ссылка работоспособностью, можно открыть VLC-плеер и сделать там проверку. Для этого в главном меню плеера нужно нажать на категорию «Медиа» и выбрать пункт «Открыть URL». Далее потребуется перейти на вкладку «Сеть» окошка «Источник» и указать свою ссылку.

Другие статьи:

• • Настройка камеры Optimus
  • Настройка IP-камеры через роутер
  • Тепловизионные камеры видеонаблюдения
  • Основные принципы при проектировании системы видеонаблюдения

Восстановление потерянных пакетов[править]

FECправить

Прямая коррекция ошибок (англ. Forward Error Correction, FEC) — техника кодирования/декодирования, позволяющая исправлять ошибки методом упреждения. Применяется для исправления сбоев и ошибок при передаче данных, путём передачи избыточной служебной информации, на основе которой может быть восстановлена первоначальное содержание посылки. Например через каждые четыре пакета, можно передавать пакет контроля по четности, который содержит xor предыдущих четырёх. Таким образом можно восстановить поток при потере одного из пяти пакетов.

Интерливингправить

interleaving (чередование) — этот подход базируется на смешивании (интерливинге) порядка медиа перед передачей и сортировке (деинтерливинге) при его получении. Таким образом, благодаря перемешиванию не будет потеряно следующих друг за другом пакетов, и один большой разрыв при проигрывании медиа не образуется. Например, пакет может содержать 5 мс проигрывания музыки. Если они были посланы по порядку, потеря пакета повлечет перерыв в проигрывании на 5 мс. Вместо этого все четные сэмплы интервала в 10 мс посылаются в одном пакете, а нечетные во втором. Теперь потеря третьего пакета означает не пропуск в музыке в 5 мс, а чередование пустых и заполненных музыкой коротких промежутков в течение 10 мс. С потерей можно легко справиться, если плеер использует интерполяцию, учитывая предыдущий и следующий образцы. В результате мы получим временную потерю в разрешении на 10 мс, но значительного прерывания не будет. Эта схема интерливинга работает только при отсутствии сжатия. Однако схема интерливинга может также применяться после сжатия, если есть возможность обнаружить границы сэмплов в сжатом потоке.

Способ 1 — RTMP

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
rtsp://192.168.88.5/live.sdp — это RTSP адрес самой камеры.

Немного избыточный вариант кода плеера на Flex и AS3 доступен здесь.

Выглядит это так:

Как получить поток RTSP с камеры

Чтобы просматривать видео и захватывать звук посредством этой технологии, необходима поддержка RTSP на стороне камеры. Этот протокол поддерживают многие образцы имеющихся на рынке устройств, но в документации возможность описана не всегда.

Если поддержка заявлена, то в инструкции будут прописаны настройки для доступа к трансляции. Они представляют собой ссылку для подключения в следующем формате:

Здесь rtsp — указание на протокол подключения, addr — IP-адрес камеры. Через двоеточие указан порт. Последний может отличаться, если в настройках указан отличный от «дефолтного».

Далее следуют user и password — логин пользователя и пароль для подключения (их может и не быть). После них указываются дополнительные параметры, который у разных камер могут отличаться.

Функции

1. Поддержка модели клиент / сервер.
2. Просто и быстро: когда клиент запрашивает услугу с сервера, ему нужно только передать метод запроса и путь. Обычно используемые методы запроса — это GET, HEAD и POST. Каждый метод обеспечивает разный тип контакта между клиентом и сервером. Поскольку протокол HTTP прост, размер программы сервера HTTP небольшой, а скорость связи очень высокая.
3. Гибкость: HTTP позволяет передавать любой тип объекта данных. Передаваемый тип помечается Content-Type.
4. Нет соединения: значение отсутствия соединения состоит в том, чтобы ограничить каждое соединение обработкой только одного запроса. После того, как сервер обработал запрос клиента и получил ответ клиента, он отключится. Таким образом можно сэкономить время передачи.
5. Без сохранения состояния: протокол HTTP — это протокол без состояния. Отсутствие состояния означает, что протокол не имеет емкости памяти для обработки транзакций. Отсутствие состояния означает, что если предыдущая информация необходима для последующей обработки, ее необходимо повторно передать, что может привести к увеличению объема данных, передаваемых за одно соединение. С другой стороны, когда серверу не нужна предыдущая информация, его ответ происходит быстрее.

Программа для подключения и записи видео с IP камер (протокол RTSP)

openRTSP — это программа с интерфейсом командной строки, которую можно использовать для открытия, потоковой передачи, приёма и (необязательно) записи медиапотоков, указанных в URL-адресе RTSP, т. е. URL-адресе, который начинается с rtsp://

Как установить openRTSP. Как установить LIVE555 Streaming Media

Программа openRTSP является частью пакета LIVE555 Streaming Media, поэтому для её установки, нужно установить набор программ LIVE555.

В Debian, Linux Mint, Kali Linux, Ubuntu и их производных это можно сделать командой:

sudo apt install livemedia-utils

В Arch Linux и производных для установки выполните команду:

sudo pacman -S live-media

В других дистрибутивах попробуйте данный поискать пакет по ключевым словам «livemedia» и «live-media». Если его нет, то вы можете скомпилировать программу из исходного кода. Для этого выполните команды:

wget http://www.live555.com/liveMedia/public/live555-latest.tar.gz
tar xvzf live555-latest.tar.gz
rm live555-latest.tar.gz
cd live
./genMakefiles linux
make

Теперь исполнимый файл openRTSP находится в папке testProgs:

cd testProgs
./openRTSP

Полный список опций

Это краткое описание опций для команд openRTSP и playSIP.

-4

вывести файл в формате ‘.mp4’ (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-a

воспроизводить только аудиопоток (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-A НОМЕР КОДЕКА

укажите номер статического формата полезной нагрузки RTP аудиокодека для запроса с сервера (только «playSIP»)

-b РАЗМЕР БУФЕРА

изменить размер буфера выходного файла

-B РАЗМЕР БУФЕРА

изменить размер входного буфера сетевого сокета

-c

воспроизводить непрерывно

-C

явно запрашивать многоадресный поток, даже если в ответе сервера «DESCRIBE» не указан многоадресный адрес

(Обратите внимание, что не все серверы поддерживают это.) (Только «openRTSP»). -d ДЛИТЕЛЬНОСТЬ

-d ДЛИТЕЛЬНОСТЬ

укажите явную продолжительность

-D МАКСИМАЛЬНЫЙ-РАЗРЫВ-МЕЖДУ-ПАКЕТАМИ

указать максимальный период бездействия перед выходом

-E ПОЛНОЕ ВРЕМЯ

запросить, чтобы сервер завершил потоковую передачу в указанное абсолютное время (формат: «ГГГГММДДТЧЧММССЗ» или «ГГГГММДДТЧЧММСС.долиZ») (используется только с -U АБСОЛЮТНОЕ-ВРЕМЯ)

-f ЧАСТОТА

укажите частоту кадров видео (используется только с «-q», «-4» или «-i»)

-F ПРЕФИКС ФАЙЛА

укажите префикс для каждого имени выходного файла

-g USER-AGENT

укажите имя пользовательского агента для использования в исходящих запросах

-h ВЫСОТА

укажите высоту видеоизображения (используется только с «-q», «-4» или «-i»)

-H

выводит «подсказку» QuickTime для каждой аудио/видеодорожки (используется только с «-q» или «-4»)

-i

вывести файл в формате ‘.avi’ (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-I ИНТЕРФЕЙС-ИЛИ-IP

указать конкретный сетевой интерфейс для получения данных

-k ПОЛЬЗОВАТЕЛЬ ПАРОЛЬ

укажите имя пользователя и пароль, необходимые для аутентификации входящей команды «REGISTER» (используется только с «-R»)

-K

Периодически отправляйте команду RTSP «OPTIONS», чтобы поддерживать соединение. (Это полезно для серверов с ошибками, которые вместо этого не слушают наши периодические пакеты RTCP «RR».)

-l

попытаться компенсировать потерю пакетов (используется только с «-q», «-4» или «-i»)

-m

выводить каждый входящий кадр в отдельный файл

-M ПОДТИП MIME

укажите подтип MIME динамического формата полезной нагрузки RTP, который аудиокодек запрашивает у сервера (только «playSIP»)

-n

получать уведомление, когда начинают поступать пакеты данных RTP

-o

запросить возможные параметры команды сервера, не отправляя «DESCRIBE» (только «openRTSP»)

-O

не запрашивать возможные команды сервера; просто отправить «DESCRIBE» (только «openRTSP»)

-p НАЧАЛЬНЫЙ-ПОРТ

укажите номер(а) клиентского порта

-P ИНТЕРВАЛ-СЕКУНДЫ

записывать новые выходные файлы каждые ИНТЕРВАЛ-В-СЕКУНДАХ секунд

-q

вывести файл формата QuickTime ‘.mov’ (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-Q

выводить статистику QOS о потоке данных (при выходе из программы)

-r

воспроизводить потоки RTP, но не получать их самостоятельно

-R (или -R ПОРТ)

ожидать входящей команды «REGISTER» с указанием URL «rtsp://» для воспроизведения. Этот параметр используется вместо URL-адреса «rtsp://» в командной строке. (только «openRTSP»)

-s НАЧАЛО

запросить у сервера поиск указанного времени (в секундах) перед потоковой передачей

-S БАЙТЫ-СДВИГА

предполагать простой формат полезной нагрузки RTP (пропуск специального заголовка указанного размера)

-t

передавать данные RTP/RTCP через TCP, а не через (обычный) UDP. (только «openRTSP»)

-T ПОРТ

как «-t», за исключением использования туннелирования RTSP через HTTP. (только «openRTSP»)

-u ПОЛЬЗОВАТЕЛЬ ПАРОЛЬ

укажите имя пользователя и пароль для дайджест-аутентификации

-U ПОЛНОЕ-ВРЕМЯ

запросить у сервера поиск указанного абсолютного времени (формат: «ГГГГММДДТЧЧММССЗ» или «ГГГГММДДТЧЧММСС.доляZ») перед потоковой передачей

-v

воспроизводить только видеопоток (в ‘stdout’, если также не задана опция «-P ИНТЕРВАЛ-В-СЕКУНДАХ»)

-V

печатать менее подробный диагностический вывод

-w ШИРИНА

укажите ширину видеоизображения (используется только с «-q», «-4» или «-i»)

-y

попробовать синхронизировать аудио и видео треки (используется только с «-q» или «-4»)

-z СКОРОСТЬ

запросить, чтобы сервер масштабировал поток (ускоренная перемотка вперед, медленное или обратное воспроизведение)

Low-Latency CMAF for DASH

Low-latency CMAF for DASH is another emerging technology for speeding up HTTP-based video delivery. Although it’s still in its infancy, the technology shows promise delivering superfast video at scale by using shorter data segments. That said, many vendors have prioritized support for Low-Latency HLS over that of low-latency CMAF for DASH.

• Playback Compatibility: Any players that aren’t optimized for low-latency CMAF for DASH can fall back to standard (higher-latency) DASH behavior
• Benefits: Low latency meets HTTP-based streaming
• Drawbacks: As an emerging spec, vendors are still implementing support
• Latency: 3 seconds or less

What Is a Streaming Protocol?

Each time you watch a live stream or video on demand, streaming protocols are used to deliver data over the internet. These can sit in the application, presentation, and session layers.

Online video delivery uses both streaming protocols and HTTP-based protocols. Streaming protocols like Real-Time Messaging Protocol (RTMP) enable speedy video delivery using dedicated streaming servers, whereas HTTP-based protocols rely on regular web servers to optimize the viewing experience and quickly scale. Finally, a handful of emerging HTTP-based technologies like the Common Media Application Format (CMAF) and Apple’s Low-Latency HLS seek to deliver the best of both options to support low-latency streaming at scale.

Apple HLS

Since Apple is a major player in the world of internet-connected devices, it follows that Apple’s HLS protocol rules the digital video landscape. For one, the protocol supports adaptive bitrate streaming, which is key to viewer experience. More importantly, a stream delivered via HLS will play back on the majority of devices — thereby ensuring accessibility to a large audience.

HLS support was initially limited to iOS devices such as iPhones and iPads, but native support has since been added to a wide range of platforms. All Google Chrome browsers, as well as Android, Linux, Microsoft, and MacOS devices, can play streams delivered using HLS.

To view this video please enable JavaScript, and consider upgrading to a
web browser that
supports HTML5 video

• Video Codecs: H.265, H.264
• Audio Codecs: AAC-LC, HE-AAC+ v1 & v2, xHE-AAC, Apple Lossless, FLAC
• Playback Compatibility: Great (All Google Chrome browsers; Android, Linux, Microsoft, and MacOS devices; several set-top boxes, smart TVs, and other players)
• Benefits: Adaptive bitrate and widely supported
• Drawbacks: Quality of experience is prioritized over low latency
• Latency: 6-30 seconds (lower latency only possible when tuned)
• Variant Formats: Low-Latency HLS (see below), PHLS (Protected HTTP Live Streaming)

RTSP/RTP

Like RTMP, RTSP/RTP describes an old-school technology used for video contribution. RTSP and RTP are often used interchangeably. But to be clear: RTSP is a presentation-layer protocol that lets end users command media servers via pause and play capabilities, whereas RTP is the transport protocol used to move said data.

Android and iOS devices don’t have RTSP-compatible players out of the box, making this another protocol that’s rarely used for playback. But RTSP remains standard in many surveillance and closed-circuit television (CCTV) architectures. Why? The reason is simple. RTSP support is still ubiquitous in IP cameras.

To view this video please enable JavaScript, and consider upgrading to a
web browser that
supports HTML5 video

• Video Codecs: H.265 (preview), H.264, VP9, VP8
• Audio Codecs: AAC, AAC-LC, HE-AAC+ v1 & v2, MP3, Speex, Opus, Vorbis
• Playback Compatibility: Not widely supported (Quicktime Player and other RTSP/RTP-compliant players, VideoLAN VLC media player, 3Gpp-compatible mobile devices)
• Benefits: Low-latency and supported by most IP cameras
• Drawbacks: No longer used for video delivery to end users
• Latency: 2 seconds
• Variant Formats: The entire stack of RTP, RTCP (Real-Time Control Protocol), and RTSP is often referred to as RTSP