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

21.01.2022

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

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

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

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

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

Что же в RTSP хорошего и удачного и почему он не используется в телевидении?

Содержание:

1. Что такое RTSP и с чем его едят зачем он нужен?
2. Связь между RTSP и HTTP RTP (RTCP)
3. Взаимосвязь между RTSP, RTP, RTCP и SDP
4. Основные методы протоĸола RTSP. SIP и RTSP
5. RTSP. Было/стало
6. RTSP и RTMP
7. 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, 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:

Методы	Описание
DESCRIBE	Запрос описания содержимого, например, в формате SDP
OPTIONS	Запрос поддерживаемых методов
PLAY	Запрос начала вещания содержимого
PAUSE	Запрос временной остановĸи вещания
RECORD	Запрос на записывание содержимого сервером
REDIRECT	Запрос на перенаправление на другое содержимое
SETUP	Запрос установĸи транспортного механизма для содержимого
ANNOUNCE	Запрос на обновление данных описания содержимого
TEARDOWN	Запрос на остановĸу потоĸа и освобождение ресурсов

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/h364 — пример настоящей ссылки.

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

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

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

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

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

Протокол rtsp

Очевидно, что достаточное количество пользователей «потоковых» мультимедийных услуг желают или будут желать использовать такие стандартные для систем домашнего видео и DVD функции, как «пауза», «перемотка вперед/назад» и т.п. Как было сказано в п. 1.2.2 данной главы, реализация дополнительных протоколов позволит полностью удовлетворить запросы самого требовательного пользователя.

На момент написания книги самым широкораспространенным и быстроразвиваюшимся протоколом, на основе которого реализуются упомянутые выше функции, является «протокол для потоковых данных реального времени» RTSP (Real-Time Streaming Protocol) определенный в [RFC2326].

Главной функцией протокола RTSP является возможность управления «потоковым» приложением. Функции управления реализованы в программном продукте, осуществляющим воспроизведение аудио и/или видеоинформации, поступающей со стороны сервера, т. е. медиаплейеру. Управление осуществляется путем обмена управляющими сообщениями между сервером и клиентом. Управляющие сообщения протокола RTSP не принадлежат к информационным соединениям и потокам между сервером и клиентом — они используют отдельное соединение или поток с номером порта 544, поэтому этот протокол называется «выделенным» (out-of-band). Аналогию для управляющих сообщений RTSP можно провести с управляющим каналом в протоколе FTP. Спецификация RTSP позволяет использовать на транспортном уровне для своих лакетов как протокол TCP, так и UDP.

На рис. 1.27 приведен пример взаимодействия клиента и сервера при помощи протокола RTSP. Будем рассматривать случай, когда оконечный пользователь на стороне клиента использует стандартный браузер (browser) для просмотра гипертекстовой информации из сети и через него инициирует просмотр «потокового» видео со звуковым сопровождением. В результате процедуры инициирования (физически это может быть просто щелчок мышью на соответствующую гиперссылку) браузер посылает веб-серверу запрос о параметрах объекта (презентации), находящегося за гиперссылкой (в нашем случае это — «потоковое» видео со звуковым сопровождением), в результате чего веб-сервер присылает «файл описания презентации» (presentation description), пример которого приведен на рис. 1.26 [Schul97], Взаимодействие осуществляется через протокол HTTP [RFC 1945, RFC2616], Этот файл может содержать как ссылки на несколько «потоковых» файлов, так и директивы по их синхронизации. Каждая ссылка на «потоковый» файл должна начинаться с метода URL rtsp://.

Отметим, что физически «потоковые» файлы могут находиться на другом сервере, называемом «медиа-сервером» (media server). В рассматриваемом примере аудио и видеопотоки должны воспроизводиться параллельно на стороне клиента в режиме lip sync (синхронизация между аудио и видеопотоками), причем медиаплейер имеет возможность выбора в каком качестве должно воспроизводиться аудиосопровождение — на стороне медиа-сервера доступно два аудиопотока различного качества: высокого ni fi и низкого lofi. Отметим, что в примере предполагается использование известного формата SMIL [SMIL02] для файлов аудиопотока. Этот формат используется для обеспечения синхронизации между различными потоками многими коммерческими продуктами.

Рис. 1.26. Пример метакода «файл описания презентации» После принятия от веб-сервера «файла описания презентации» на стороне клиента браузер должен послать запрос на загрузку в оперативную память локального медиаплейера, способного воспроизводить аудио и видеопотоки заданного формата. Далее, как показано на рис. 1.27, медиаплейер на стороне клиента и медиа-сервер обмениваются рядом сообщений RTSP. Медиаплейер посылает медиа-серверу сообщение запроса установления RTSP-соединения RTSP SETUP, ответом на которое является сообщение о поддержке этого соединения RTSP ОК.

Сообщение RTSP SETUP содержит информацию о номере порта клиента, куда должны быть адресованы пакеты «потокового» файла. Затем медиаплейер посылает запрос RTSP PLAY на начало передачи «потокового» файла, пусть, в нашем случае, это аудио низкого качества lofi. После получения этого запроса, медиа-сервер начинает посылать медиаплейеру, находящемуся на стороне клиента, пакеты, содержащие требуемую аудиоинформацию.

Далее на рис. 1.27 показан пример реализации функции «пауза» — для приостановки посылки пакетов «потокового» аудио медиаплейер должен послать сообщение RTSP PAUSE, а медиа-сервер должен ответить сообщением RTSP ОК. Если пользователь решает окончить прослушивание/просмотр, должно быть инициировано разрушение RTSP-соединения, для чего медиаплейер посылает медиа-серверу сообщение RTSP TEARDOWN, а медиа-сервер должен ответить сообщением RTSP ОК.

Протокол RTSP не включает rs себя следующие функции:

• определение схем и алгоритмов компрессии для аудио и видео;

• определение каким образом аудио и видеоинформация инкапсулируется в пакеты для передачи через сеть; эта функция может быть реализована в протоколе RTP или в «корпоративном протоколе» производителя программного обеспечения приложения.

Например, в программных реализациях как медиа-сервера, так и клиента фирмы RealNetworks для обмена служебной информацией используется протокол RTSP, а аудио и видеоинформация инкапсулируется через протокол RTP;

• определение какой транспортный протокол используется для переноса пакетов «из-конца-в-конец» — может использоваться как UDP, так и TCP;

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

Самая свежая и полная информация о протоколе RTSP может быть найдена в Интернете по адресуhttp://www.cs.columbia.edu/~hgs/rtsp.

⇐Протокол rtcp | Управление трафиком и качество обслужевания в сети | Литература к главе 1⇒

404: Страница не найдена

Виртуальный рабочий стол

Страница, которую вы пытались открыть по этому адресу, похоже, не существует. Обычно это результат плохой или устаревшей ссылки. Мы приносим свои извинения за доставленные неудобства.

Что я могу сделать сейчас?

Если вы впервые посещаете TechTarget, добро пожаловать! Извините за обстоятельства, при которых мы встречаемся. Вот куда вы можете пойти отсюда:

Поиск

• Узнайте последние новости.
• Наша домашняя страница содержит самую свежую информацию о Virtual Desktop.
• Наша страница «О нас» содержит дополнительную информацию о сайте, на котором вы находитесь, Virtual Desktop.
• Если вам нужно, свяжитесь с нами, мы будем рады услышать от вас.

Просмотр по категории

Корпоративный настольный компьютер

• Замедление продаж ПК привело к снижению цен Цены на ПК

  падают, поскольку производители снижают цены для перемещения запасов. Насыщение рынка после пандемии является значительным…

• Тысячи сотрудников Citrix и Tibco уволены после слияния

  Cloud Software Group увольняет 2250 сотрудников в связи с серьезными изменениями в продажах и разработке продуктов после слияния с Citrix Systems…

• Intel выпускает чипы Raptor Lake для ноутбуков и мобильных устройств

  Надеясь отвоевать долю рынка у AMD, Intel представила процессор, который, по ее мнению, является самым быстрым для мобильных устройств. Новый …

Облачные вычисления

• Расходы на публичное облако и конкуренция возрастут в 2023 году

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

• 3 рекомендации по оптимальному размеру инстансов EC2 Инстансы

  EC2 неправильного размера истощают деньги и ограничивают требования к производительности при рабочих нагрузках. Узнайте, как правильно подобрать размер EC2 …

• Как выполнять и автоматизировать ротацию ключей в Azure Key Vault

  Чтобы добавить еще один уровень безопасности, узнайте, как автоматически менять ключи в хранилище ключей Azure с помощью пошаговых инструкций…

SearchVMware

• Пользователи VMware ESXi должны решить: остаться или уйти?

  Поскольку срок службы многих серверов VMware ESXi подходит к концу, пользователи должны принять решение о продлении существующих соглашений о поддержке, обновлении до версии 7…

• 5 функций vSphere 8, о которых нужно знать

  Последний выпуск vSphere предлагает расширенные функции управления жизненным циклом, аппаратную поддержку и управление блоками обработки данных . ..

• VMware Explore 2022: VMware предлагает клиентам мультиоблачные технологии

  Во время исследования компания VMware попыталась убедить клиентов использовать ее технологию для построения многооблачной архитектуры. Что делает VMware…

RTSP: объяснение протокола потоковой передачи в реальном времени

2 декабря 2022 г. Трейси Рютер

Для просмотра этого видео включите JavaScript и рассмотрите возможность перехода на веб-браузер, который поддерживает HTML5 видео

Протокол потоковой передачи в реальном времени (RTSP) — это проверенная видеотехнология. Он используется для управления передачей аудио/видео между двумя конечными точками и облегчения передачи потокового контента с малой задержкой через Интернет.

Наряду с протоколом обмена сообщениями в реальном времени (RTMP) RTSP когда-то доминировал в потоковом вещании. Сегодня это уже не так. Тем не менее, RTSP остается стандартом во многих архитектурах видеонаблюдения и систем видеонаблюдения (CCTV). Причина этого проста: это по-прежнему предпочтительный протокол для IP-камер.

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

Содержание

• Что такое протокол?
• Что такое RTSP?
• Снимок RTSP
• RTSP-запросов
• История потоковой передачи RTSP
• RTSP против других форматов потоковой передачи
• Потоковая передача IP-камеры
• Типичный рабочий процесс RTSP
• Использование Wowza в качестве RTSP-сервера

Что такое протокол?

Протоколы

предоставляют набор правил, определяющих, как данные перемещаются из одной взаимодействующей системы в другую. Например, протокол передачи гипертекста (HTTP) определяет, как данные веб-страницы и гипертекстовые ссылки передаются по всемирной паутине, управляя связью между веб-серверами и браузерами.

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

Будьте в курсе

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

Подпишитесь сейчас

Что такое RTSP?

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

Официальное определение из предложения стандарта 1998 года гласит:

«Протокол потоковой передачи в реальном времени (RTSP) устанавливает и контролирует либо один, либо несколько синхронизированных во времени потоков непрерывных медиаданных, таких как аудио и видео. Обычно он не доставляет непрерывные потоки сам по себе, хотя возможно чередование непрерывного медиапотока с управляющим потоком. Другими словами, RTSP действует как «сетевое дистанционное управление» для мультимедийных серверов».

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

RTSP: моментальный снимок

• Аудиокодеки:  AAC, AAC-LC, HE-AAC+ v1 и v2, MP3, Speex, Opus, Vorbis
• Видеокодеки: H.265 (предварительная версия), H.264, VP9, ​​VP8
• Совместимость с воспроизведением: Не широко поддерживается и редко используется для воспроизведения (Quicktime Player и другие проигрыватели, совместимые с RTSP/RTP, VideoLAN VLC медиаплеер, 3Gpp-совместимые мобильные устройства)
• Преимущества:  Малая задержка и повсеместное использование в IP-камерах
• Недостатки:  Не оптимизировано для качества работы и масштабируемости
• Задержка:
 2 секунды0010
• Варианты форматов:  RTSP как общий термин описывает весь стек RTP, RTCP (протокол управления в реальном времени), RTSPS (RTSP через SSL/защищенный RTSP) и старый добрый RTSP

RTSP-запросы

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

• Параметры: Этот запрос определяет, какие другие типы запросов будут приниматься медиа-сервером.
• Описание: Запрос описания идентифицирует URL-адрес и тип данных.
• Объявление: Метод объявления описывает презентацию при отправке с клиента на сервер и обновляет описание при отправке с сервера на клиент.
• Настройка: Запросы настройки определяют, как должен передаваться медиапоток перед отправкой запроса на воспроизведение.
• Воспроизведение: Запрос на воспроизведение запускает передачу мультимедиа, сообщая серверу о начале отправки данных.
• Пауза: Запросы на паузу временно приостанавливают доставку потока.
• Запись: Запрос на запись инициирует запись на носитель.
• Teardown: Этот запрос полностью завершает сеанс и останавливает все медиапотоки.
• Перенаправление: Запросы перенаправления информируют клиента о том, что он должен подключиться к другому серверу, предоставляя клиенту новый URL-адрес для отправки запросов.

Другие типы запросов RTSP включают «получить параметр», «установить параметр» и «встроенные (чередующиеся) двоичные данные», которые подробно описаны здесь.

История потоковой передачи RTSP

Спецификация RTSP, впервые разработанная Netscape Communications, Progressive Networks (сейчас RealNetworks) и Колумбийским университетом, была опубликована Целевой группой Internet Engineering Task Force в 1998 году. отключения связи с медиасервером.

До появления потоковой передачи с адаптивным битрейтом через протоколы на основе HTTP и RTSP, и RTMP обеспечивали большую часть потоков в Интернете. Но поскольку для обоих требуются выделенные серверы, они не подходят для крупномасштабных трансляций.

Таким образом, RTSP теперь используется в основном как протокол передачи. Большинство рабочих процессов используют медиасервер для приема потоков, передаваемых через RTSP/RTP, а затем переупаковывают файл для доставки на устройства просмотра — от iPhone до смарт-телевизоров.

Альтернативы следующего поколения, такие как Secure Reliable Transport (SRT), сегодня напрямую конкурируют с RTSP за передачу видео. Несмотря на это, RTSP остается популярным в рабочих процессах наблюдения как стандарт де-факто для IP-камер.

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

Подпишитесь, чтобы быть в курсе всех потоковых новостей — от протоколов до последних тенденций.

Регистрация

RTSP и альтернативные форматы загрузки

Если вы хотите заменить RTSP на проверенную альтернативу, RTMP — самый популярный протокол, используемый сегодня для доставки первой мили. На самом деле, целых 76,6 % респондентов нашего отчета о задержке потокового видео за 2021 год указали, что они используют RTMP для загрузки.

Как показано ниже, веб-коммуникации в реальном времени (WebRTC) и SRT также являются популярными форматами, и только 18,6% распространителей контента сегодня полагаются на RTSP.

Какие форматы потоковой передачи вы используете в настоящее время для загрузки?

Вот сравнение трех вариантов .

RTMP

RTMP — старейший конкурент RTSP, и это лучший выбор для потоковой передачи напрямую на платформу социальных сетей. Оба протокола используются для участия, но больше кодировщиков и сервисов потокового вещания принимают RTMP.

Например, Facebook, Twitch и YouTube принимают только RTMP для прямых трансляций с малой задержкой. Это означает, что вы либо захотите закодировать свой поток как RTMP с самого начала, либо переупаковать любые потоки RTSP как RTMP, используя видеоплатформу, такую ​​​​как Wowza. Последний вариант также позволит осуществлять одновременную трансляцию на несколько пунктов назначения одновременно, что делает его хорошим маршрутом для тех, кто хочет вести прямую трансляцию с IP-камеры в социальные сети.

RTMP и RTSP Deep Dive

СТО

Как технология с открытым исходным кодом, оптимизированная для непредсказуемых сетей, SRT обещает вытеснить RTSP и RTMP, когда-то получившие широкую поддержку. Кодировщики и медиа-серверы все еще добавляют поддержку SRT, и потоковые сервисы, такие как Facebook, вполне могут последовать этому примеру.

В недавнем опросе Wowza на LinkedIn SRT вызвала наибольший интерес к вкладам первой мили. Протокол также оптимизирован для непредсказуемых общедоступных сетей, сочетая скорость и надежность в одном решении.

SRT Глубокое погружение

WebRTC

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

Раньше WebRTC ограничивался мелкомасштабной потоковой передачей и публикацией в браузере, но сейчас все меняется. Технология под названием WebRTC HTTP Ingest Protocol (WHIP) предоставляет программное и аппаратное обеспечение для кодирования со стандартным сигнальным протоколом при общении с медиа-серверами, тем самым устраняя барьеры подключения WebRTC между кодировщиками и медиа-серверами. А функция масштабируемой потоковой передачи в реальном времени от Wowza для Wowza Video поддерживает WHIP, а также потоковую передачу для миллиона зрителей.

Станьте экспертом по WebRTC

Узнайте все, что вам нужно знать, в нашем исчерпывающем руководстве по WebRTC.

Скачать PDF

Потоковая передача IP-камеры

Как подчеркивалось выше, протокол RTSP и IP-камеры идеально подходят друг другу. Часто медиа-сервер получает сигнал RTSP от IP-камеры.

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

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

Типичный рабочий процесс RTSP

RTSP — это протокол с отслеживанием состояния, который чаще используется для передачи видео (прием), чем для доставки и воспроизведения последней мили (исход). Устройства Android и iOS не имеют готовых проигрывателей, совместимых с RTSP, поэтому RTSP редко используется для сквозной потоковой передачи. Вместо этого большинство вещательных компаний используют потоковый сервер, такой как Wowza, для переупаковки потока RTSP в более удобный формат, такой как HLS.

Использование Wowza в качестве сервера RTSP

Несмотря на свой возраст, RTSP остается популярным форматом приема. Но — чтобы еще раз вернуться домой — вам понадобится решение для переупаковки видео для доставки потока на устройства конечных пользователей.

Серверы

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