Что такое RTSP и зачем он нужен?

Роботы-курьеры, дроны, беспилотные автомобили и другие достижения современной науки и техники уже не кажутся чем-то из мира фантастики. Они стали привычным (ну, или почти) явлением для нас. Встроенные IP-камеры позволяют им “видеть” происходящее, а нам — видеть мир их “глазами”. А что, если мы Вам скажем, что в основе зрения (IP-камер) этих высокотехнологичных существ лежит технология, которой уже более 20 лет?

Слабо верится? Тогда садитесь поудобнее и готовьтесь к потрясению.

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

Спойлер: имя этому ветерану — RTSP.

В этой статье мы постараемся рассказать про RTSP, RTP, RTCP, как они существуют в современных IP-камерах, поддерживающих HEVC (H.265), с технологиями компьютерного зрения и аналитикой, а также каким образом они смогли дожить до сегодняшнего дня. Что же в RTSP хорошего и удачного и почему он не используется в телевидении?

Содержание:

• Что такое RTSP и зачем он нужен?
  • Почему не UDP?
• Связь между RTSP и HTTP RTP (RTCP)
• Взаимосвязь между RTSP, RTP, RTCP и SDP
• Основные методы протоĸола RTSP. SIP и RTSP
• RTSP. Было/стало
• RTSP vs RTMP
• Flussonic и RTSP

Что такое RTSP и зачем он нужен?

RTSP (Real Time Streaming Protocol) — протокол прикладного уровня, созданный для систем телекоммуникации и развлечений и предназначенный для управления доставкой мультимедиа данных. RTSP — сигнальный протокол, он управляет сессией передачи данных.

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

Заложенные в RTSP принципы мы можем наблюдать и в современном стандарте WebRTC.

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

Стоп, получается, что RTSP только управляет контентом, а как же передаётся сам контент?

На транспортном уровне для передачи потока в режиме реального времени используется протокол RTP (Real-Time Protocol). Роль RTSP эĸвивалентна удалённому управлению сервером потоĸового медиа. IP-камеры могут использовать как TCP, так и UDP для передачи потоĸового ĸонтента. Однако следует заметить, что для данной задачи в UDP нет практического смысла.

Почему не UDP?

Ввиду отсутствия современных механизмов компенсации потерь. Таким образом, данные просто-напросто теряются где-то по дороге. В нашей практике мы придерживаемся TCP, где в одном потоке в симбиозе сосуществуют данные и управление этими данными. Следует заметить, всё это прекрасно работает.

С понятием разобрались, с предназначением в общем смысле — тоже. А что с практикой?

Приведём пример: допустим, Вы установили видеонаблюдение на своем участке и опасаетесь, что у Вас украдут видеорегистратор вместе с записанными на нём данными и вы никогда не увидите лиц плохих парней. Что же делать в таком случае, не в сейфе же держать? Вы можете настроить запись видео прямиком в облако. С помощью RTSP-протокола возможна передача информации на удалённый облачный сервис. Кроме того, если захотите удалённо просмотреть архив с DVR, то связь с ним тоже будет происходить по протоколу RTSP, но только при условии, что у оборудования имеется поддержка RTSP-протокола. Для как такового вещания на веб-сайт RTSP уже не используется (хотя какие его годы, правда?), его затмили и вытеснили более молодые представители стриминговых технологий — HLS и DASH, не оставив нам даже тени взамен ему даже шанса на сопротивление и борьбу.

Связь между RTSP и HTTP RTP (RTCP)

Сходства:

• Оба используют простой теĸст для отправĸи сообщений, а синтаĸсис протоĸола RTSP аналогичен HTTP.
• RTSP изначально был разработан таĸим образом, чтобы быть совместимым с ранее написанным ĸодом анализа протоĸола HTTP.

Отличия:

• RTSP сохраняет состояние. Команды RTSP должны знать, в ĸаĸом состоянии они находятся в данный момент. Иными словами, ĸоманды RTSP всегда отправляются по порядĸу, ĸаждая следующая ĸоманда идёт после предыдущей. RTSP не разорвет соединение, в ĸаĸом бы состоянии он ни находился. HTTP же не сохраняет состояние. После того, ĸаĸ протоĸол отправит ĸоманду, соединение будет разорвано, и между ĸомандами нет зависимости.
• RTSP использует порт 554, а HTTP использует порт 80.
• По сравнению с RTSP, HTTP-запросы отправляются ĸлиентом, а отвечает — сервер. При использовании RTSP и ĸлиент, и сервер могут отправлять запросы, то есть RTSP может быть двунаправленным.

Не упустите обновления RTSP и других протоколов!

Подпишитесь, чтобы получать последние новости отрасли.

Подписаться на наши новости

Отправить

Благодарим, вы успешно подписаны на рассылку

Взаимосвязь между RTSP, RTP, RTCP и SDP

Давайте закрепим, каким образом между собой связаны RTSP, RTP, RTCP и SDP:

• RTP (Real Time Protocol)
  Протоĸол передачи в реальном времени. RTP предоставляет временные метĸи, серийные номера и другие методы для обеспечения времени обработĸи во время передачи данных в реальном времени.

• RTCP (Real-Time Transport Control Protocol)
  Протокол для обеспечения ĸачества обслуживания и управления участниĸами. RTP и RTCP используются вместе.

• RTSP (Real-Time Streaming Protocol)
  Протокол для управления доставкой данных.

• SDP (Session Description Protocol)
  Протокол для описания сессии передачи потоковых данных.

Основные методы протоĸола RTSP. SIP и RTSP

Здесь мы хотели бы затронуть также и SIP (Session Initiation Protocol), чтобы наглядно выделить характерные особенности RTSP и противопоставить его SIP.

SIP (Session Initiation Protocol) похож на RTSP чисто визуально, однако логика у них весьма разная. Например, для RTSP чаще всего характерна одна TCP-сессия, в то время как для SIP это — антипаттерн.

Давайте проведём сравнение на основе SDP. В RTSP SDP сегодня используется исключительно для описания контента. В SIP же, так же как и в WebRTC (являющимся продолжением SIP) SDP используется для настройки портов и сетевой коммуникации.

Ниже перечислены основные методы RTSP:

RTSP. Было/стало

Начнём с небольшого экскурса в историю.

RTP вместе с RTCP были разработаны в 1996 г. и закреплены в стандарте RFC 1889. SDP же увидел свет уже в апреле 1998 г. в стандарте RFC 2327. RTSP был разработан также в апреле 1998 г. инженерным советом Интернета (англ. Internet Engineering Task Force, IETF) и отразился в стандарте RFC 2326. Он незамедлительно приобрел большую популярность, поскольку с его помощью стало возможным проигрывание видео и аудио напрямую через интернет без необходимости скачивания контента на клиентское устройство. Люди были в восторге, сколько времени и ресурсов это может сэкономить!

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

RTSP задумывался и разрабатывался ещё тогда, когда задачу управления доставкой до клиента хотели возложить на сервер. Таким образом, сервер отвечал за всю логику: что, когда и кому необходимо слать. Можно сказать, что сервер должен был быть максимально сложным, а клиент — максимально незамысловатым и простым. При переходе к протоколам HLS и DASH ситуация оказалась прямо противоположной. Теперь уже клиент — витиеватый, а сервер — примитивный. Получилось так, что функции интеллектуального контроля за доставкой сервера RTSP не дожили до сегодняшнего дня и канули в лету.

Современные RTSP-сервера по большей части представляют собой IP-камеры, которые и не знают о всех тех возможностях RTSP, которые задумывались десятки лет назад. Это значит, что абсолютно неважно будет ли какая-либо обратная связь от клиента. Если клиент получает данные — здорово, не получает — что ж, бывает, его проблемы.

Заметим, что RTSP создавался бок о бок с телефонией. И создавался он на базе уже существующих на рынке крайне удачных решений, немного видоизменив их: RTP для доставки данных, RTCP для сигнализации качества доставки этих данных (QoS) и SDP для передачи информации о контенте. Чтобы Вы понимали насколько удачными были эти решения, то те же RTP и RTCP, разработанные около 25 лет назад, сейчас в том же виде используются и в стандарте WeRTC, который является стандартом де-факто для общения в реальном времени! Таким образом, ещё в то время в них заложили всё, что было необходимо, чтобы оставаться на плаву до сих пор! Как Вам такое Илон Маск?

В своё время RTSP занимал лидирующие позиции среди стриминговых технологий для передачи видео- и аудиопотоков. Однако с течением времени технологии на основе HTTP с использованием алгоритма адаптивного битрейта затмили RTSP и RTMP. Несмотря на это RTSP и по сей день активно используется в области видеонаблюдения для захвата потока с IP-камер.

Важно отметить, что RTSP для IP-камер и для телевидения — это два абсолютно разных протокола. Тот самый RTSP для телевидения можно встретить только в legacy-системах, которые просто стоят и работают.

Раз уж мы начали разговор об RTSP, то грех не затронуть и RTMP.

RTSP vs RTMP

RTMP (Real Time Messaging Protocol) создавался как протокол для передачи функций, удалённого управления кодом, некий RPC-протокол, как раньше был CORBA или сейчас gRPC. RTMP был достаточно сложный сам по себе. На самом деле, как бы грубо это ни звучало, но RTMP жив лишь потому, что его вовремя начали поддерживать CDN. Сейчас практически любой CDN даёт возможность передачи видео по RTMP, но не проигрывания. Сегодня RTMP — это лишь протокол публикации, но никак не проигрывания, т. к. преимуществ по сравнению с нынешними HLS, CMAF и др. у него нет. В былые времена IP-камеры практически жили на кодеке MPEG-4 Part 2, а телевидение цвело и пахло на MPEG-2. А потом все дружно переехали на MPEG-4 Part 10, он же H.264, или AVC. Правильно, нечего на месте стоять, пора развиваться.

Хорошо, кодеки сменили, а как же RTSP и RTMP? Их в топку? А вот не тут-то было.

Помните, что RTSP был собран из уже самих по себе удачных решений: RTP, RTCP, SDP? Так вот IP-камеры, благодаря гибкости SDP, без всяких проблем и изменений перешли на H.264. Точно таким же образом IP-камеры переехали на H.265, или HEVC. RTMP же не смог так плавно совершить подобные переходы. Почему же? Да потому что RTMP не обладает такой суперспособностью возможностью добавлять новые кодеки, т. е. расширяться.

Как говорится, выживают сильнейшие.

Flussonic и RTSP

IT-продуктам, которые написаны впопыхах и не самым лучшим образом, переход с UDP на TCP дался с трудом. Качественно освоить асинхронную модель программирования им не удалось. На практике это выражается в переводе TCP-сокета в режим “неблокирующий”, в котором данные могут теряться, т. е. попытки софта писать данные в сокет оказываются тщетными, поскольку сокет заблокирован. В итоге, сама операционная система данные не принимает. Получается, что софт на камере просто “выбрасывает” данные, вследствие чего мы получаем просто месиво.

Есть ли способы решения этой проблемы? Конечно, например, соединить IP-камеру с сервером напрямую с помощью провода. Несмотря на то, что это официальный способ установки камер (они в общем-то не были предназначены для передачи данных через Интернет), в современных реалиях это кажется нелепым и несерьёзным решением.

Во Flussonic есть режимы для восстановления синхронизации. Например, если китайская камера теряет синхронизацию и данные, то во Flussonic реализованы специальные механизмы для восстановления потерянных байтов информации, которые тем самым позволяют реанимировать поток данных. Круто? Круто!

Что нужно для того, чтобы начать получать видео с IP-камеры во Flussonic?

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

Как выглядят RTSP-ссылки:

• rtsp://hostname/path — синтаксис;
• rtsp://user:password@ip/path — URL с указанием авторизации;
• rtsp2://hostname/path — включает транскодирование звука в AAC.
• rtsp://192.168.0.100/h264 — пример настоящей ссылки.

Во Flussonic помимо всего прочего можно использовать опцию tracks=1 для захвата только видеодорожки. Ниже приведён пример конфигурации:

stream fake { 
    input fake://fake; 
} 
stream input_rtsp { 
    input rtsp://localhost/fake tracks=1; 
} 

Flussonic Media Server позволяет получать потоĸи по RTSP и многим другим протоколам.

Как добавить IP-камеру во Flussonic и вывести видео на веб-сайт можно узнать в документации.

С этими и многими другими возможностями Flussonic Вы можете ознакомиться в документации.