RTSP¶

RTSP — это протокол, который позволяет соединить две точки и установить направленный поток аудио/видео с ультранизкой задержкой между ними.

Сегодня он в основном используется в IP-камерах по историческим причинам. Это хорошо продуманный, высоко расширяемый протокол, который имеет достаточно функций и возможностей для использования сегодня и не устарел за свои 30 лет существования. Мы сходим с ума по ультра-нулевой-минимальной задержке в настоящее время, поэтому этот протокол все еще актуален.

RTSP можно сравнить с SIP и WebRTC. SIP очень похож на RTSP, но используется для управления двунаправленным (или более сложной топологией) потоком и используется в IP-телефонии или системах видеоконференций. WebRTC похож на SIP, но текстовый протокол сигнализации заменен неопределенным HTTP-методом обмена информацией. Однако расширения WHEP/WHIP для WebRTC являются прямой заменой RTSP.

По сравнению с MPEG-TS, RTSP сосредоточен на доставке аудио/видео через IP, в то время как MPEG-TS сосредоточен на предоставлении телевизионных услуг на однонаправленных медиа.

Flussonic поддерживает:

Иногда можно встретить RTSP/2.0, но это упоминается, но не встречается на практике. Все используют разные варианты RTSP/1.0.

Существуют два разных несовместимых варианта RTSP в дикой природе:

• RTSP IP-камеры, которая передает видео и аудио в разных потоках UDP/чередующихся TCP. Обычно юникаст.
• RTSP IPTV, которая передает видео и аудио внутри MPEG-TS, который инкапсулируется в пакеты RTP, отправляемые через мультикаст.

Flussonic имеет полную поддержку первого варианта и ограниченную поддержку второго (только прием).

RTSP, SDP, RTP and RTCP¶

Слово RTSP подразумевает использование следующих стандартов:

• RTSP как текстовый протокол сигнализации. Он выглядит так же, как HTTP и очень похож на него.
• SDP — это формат для одного текстового сообщения, которое передается от источника видео к пункту назначения видео и рассказывает о содержании и способах его получения.
• RTP — это бинарный протокол для передачи видео, аудио, метаданных через UDP или TCP в том же сокете, что и RTSP.
• RTCP — это бинарный двунаправленный протокол для обмена управляющими сообщениями, связанными с передаваемым RTP.

RTSP¶

В то время как HTTP может обходиться только двумя глаголами (GET и POST), он расширяется списком бизнес-уровневых глаголов для WebDAV, таких как MKCOL, MOVE.

RTSP имеет дюжину хорошо известных глаголов, которые используются для логического уровня. Наиболее общий список включает: OPTIONS/GET_PARAMETER, DESCRIBE, ANNOUNCE, SETUP, PLAY, RECORD, TEARDOWN.

Инициатор соединения отправляет запросы и получает ответы. Термины вроде клиент или сервер здесь не очень удобны, поскольку не совсем ясно, кто является клиентом, а кто сервером, когда соединяются два сервера.

Например, когда Flussonic читает видео с RTSP-камеры, он пытается отправить следующие запросы:

> OPTIONS rtsp://192.168.1.100/h264 RTSP/1.0
> Www-Authenticate: Basic c2VjcmV0
> CSeq: 1
>
< RTSP/1.0 200 OK
< CSeq: 1 
<
> DESCRIBE rtsp://192.168.1.100/h264 RTSP/1.0
> Www-Authenticate: Basic c2VjcmV0
> CSeq: 2
>
< RTSP/1.0 200 OK
< CSeq: 2
< Content-Type: application/sdp
< Content-Length: 370
<
.... here goes SDP
....
> SETUP rtsp://192.168.1.100/h264/trackID=1 RTSP/1.0
> Www-Authenticate: Basic c2VjcmV0
> CSeq: 3
>
< RTSP/1.0 200 OK
< CSeq: 3
<
> PLAY rtsp://192.168.1.100/h264/trackID=1 RTSP/1.0
> Www-Authenticate: Basic c2VjcmV0
> CSeq: 4
>
< RTSP/1.0 200 OK
< CSeq: 4
<
> GET_PARAMETER rtsp://192.168.1.100/h264 RTSP/1.0
> Www-Authenticate: Basic c2VjcmV0
> CSeq: 5
>
< RTSP/1.0 200 OK
< CSeq: 5
<

Это очень ограниченный пример, просто чтобы дать вам краткое представление о том, что здесь происходит.

Обратите внимание на то, что надо точно знать полный RTSP урл вместе с путем: rtsp://192.168.1.100/h264. Без пути на сервере (/h264) ничего проиграть не получится.

Задача поиска RTSP путей решается протоколом Onvif

Вы можете увидеть странный вызов GET_PARAMETER после PLAY. Никто на самом деле не собирается получать какие-либо параметры, это просто пустой вызов keepalive, чтобы сообщить, что инициатор все еще жив и все еще хочет отправлять/получать видео.

Это выглядит довольно безумно, когда вы используете тот же сокет для отправки видео, но обычно код организован таким образом, что если вы отправляете мегабиты видео в секунду, отправляете пакеты RTCP, но не отправляете GET_PARAMETER, соединение будет прервано.

SDP¶

Протокол описания сеанса, как вы можете догадаться, обычно не описывает сам сеанс. Он описывает медиа и иногда может описывать способ получения/отправки этого медиа.

Пример SDP:

v=0
o=- 1273580251173374 1273580251173374 IN IP4 axis-00408ca51334.local
s=Media Presentation
e=NONE
c=IN IP4 0.0.0.0
b=AS:50000
t=0 0
a=control:*
a=range:npt=0.000000-
m=video 0 RTP/AVP 96
b=AS:50000
a=framerate:30.0
a=control:trackID=1
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1; profile-level-id=420029; sprop-parameter-sets=Z0IAKeNQFAe2AtwEBAaQeJEV,aM48gA==

Этот тривиальный SDP содержит достаточно информации для настройки декодера (sprop-parameter-sets) и установления воспроизведения (поле a=control:).

Да, этот самоочевидный и читаемый человеком текст порождает вопрос: почему бы просто не использовать JSON? Потому что он был стандартизирован за годы до популяризации JSON, и это большая удача, что он не XML.

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

RTP¶

Протокол реального времени (RTP) является основным протоколом, используемым для доставки аудио и видео. Он бинарный и довольно простой.

Каждый пакет содержит:

• идентификатор трека (все аудио и видео треки передаются отдельно)
• идентификатор последовательности для контроля потерь пакетов, переупорядочивания, повторной передачи и т.д.
• временной код этого пакета
• необязательные расширения

RTP может быть настолько удобным, что его даже используют для передачи MPEG-TS (который также имеет счетчик непрерывности и временные метки) в IP-сетях. Это используется для повторной передачи потерянных пакетов.

RTP ориентирован на использование UDP с максимальным контролем доставки на стороне пользователя. Поэтому пакеты RTP обычно ограничиваются размером около 1400 байт, что позволяет передавать их без фрагментации. Этот размер слишком велик для аудиокадров и слишком мал для видео.

Вся спецификация для упаковки аудио/видео внутри RTP предлагает какой-то вид фрагментации и агрегации.

Идея фрагментации проста: если вы потеряете 1400 байт посреди 30КБ кадра, можно восстановить эту потерю или даже восстановить эти данные. Если вы потеряете 30КБ UDP-пакет, его почти невозможно восстановить.

RTP использует 2 байта для размера одного пакета, поэтому невозможно сделать пакет больше 64КБ. Видеопотоки высокого разрешения имеют ключевые кадры, большие этого лимита, поэтому фрагментация обязательна.

Агрегация нескольких аудио пакетов в одном кадре не так широко используется, потому что это вносит дополнительную задержку, и поэтому это не так интересно. Мы готовы тратить 80% трафика, только чтобы не увеличивать задержку в 5 раз.

RTCP¶

Протокол управления реальным временем (RTCP) — это секретная примесь RTSP. Этот протокол немного напоминает RTP (но они различны и не могут быть разобраны одним и тем же кодом) и позволяет двунаправленный обмен статистикой в реальном времени:

• Преобразование между временным кодом RTP и абсолютным временем NTP. Да, RTSP предполагает, что у вас есть абсолютные временные метки каждого кадра, и это чрезвычайно круто.
• Обмен количеством байтов и пакетов, которые были отправлены и получены. Некоторые источники RTSP могут изменять свой битрейт, если они видят растущую джиттерность или потерю пакетов на клиенте. Точно так же, как это делает WebRTC сегодня.
• Запросы на повторную передачу пакетов.
• Другие крутые вещи, связанные с доставкой видео.

Этот протокол разделяет функции между RTSP, SIP и WebRTC. WebRTC использует наиболее сложный поднабор функций RTCP.

RTSP в IP-камерах обычно использует только пакеты типов Sender Report (код 200) и Receiver Report (код 201). Оба являются обязательными, обычно ничего не будет работать, если их игнорировать, другие типы встречаются очень редко.

Стандарты¶

Flussonic ориентируется на следующие спецификации для работы с RTSP:

RFC7826 RTSP/2.0 спецификация указана как замена для RTSP/1.0, но на практике не используется.

Чтение DVR через RTSP¶

Воспроизведение DVR через RTSP возможно. Хотя мы не рекомендуем использовать протоколы кадров для DVR (dash гораздо лучше подходит для этого), это может быть строгим требованием для интеграции видеонаблюдения, которое использует только RTSP.

Flussonic полностью поддерживает воспроизведение DVR через RTSP.

Это реализовано с использованием следующих функций:

• В SDP есть поле range, которое используется для передачи списка непрерывных периодов записи.
• Заголовок Range: clock=20230919T084734Z-20230919T084914Z в методе PLAY.
• GET_PARAMETER с position в теле вернет текущую временную метку воспроизведения.

Onvif¶

Onvif — это протокол обнаружения HTTP XML (и немного UDP), который может помочь настроить IP-камеру и найти URL-адреса RTSP.

Читайте больше об этом в статье о протоколе Onvif.