stringtranslate.com

Протокол потоковой передачи в реальном времени

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

История

RTSP был разработан RealNetworks , Netscape [1] и Колумбийским университетом . [2] Первый проект был представлен в IETF в октябре 1996 года компаниями Netscape и Progressive Networks , после чего Хеннинг Шульцринне из Колумбийского университета представил «RTSP՚» («RTSP prime») в декабре 1996 года. [3] [4] Два проекта были объединены для стандартизации Рабочей группой по управлению сеансами мультимедиа (MMUSIC WG) Целевой группы по инжинирингу Интернета (IETF), и дополнительные проекты были опубликованы рабочей группой. [5] [6] Предлагаемый стандарт для RTSP был опубликован как RFC 2326 в 1998 году. [7]
RTSP 2.0 опубликован как RFC 7826 в 2016 году в качестве замены RTSP 1.0. RTSP 2.0 основан на RTSP 1.0, но не имеет обратной совместимости, за исключением механизма согласования базовой версии, и остается предлагаемым стандартом. [8]

РТП

Передача потоковых данных сама по себе не является задачей RTSP. Большинство серверов RTSP используют Real-time Transport Protocol (RTP) в сочетании с Real-time Control Protocol (RTCP) для доставки потока мультимедиа. Однако некоторые поставщики реализуют собственные транспортные протоколы. Например, программное обеспечение сервера RTSP от RealNetworks также использовало собственный Real Data Transport (RDT) RealNetworks.

Протокольные директивы

Хотя протокол RTSP в некотором роде похож на HTTP , он определяет управляющие последовательности, полезные для управления воспроизведением мультимедиа. В то время как HTTP не имеет состояния , RTSP имеет состояние; идентификатор используется при необходимости отслеживания одновременных сеансов. Как и HTTP, RTSP использует TCP для поддержания сквозного соединения, и хотя большинство управляющих сообщений RTSP отправляются клиентом на сервер, некоторые команды передаются в другом направлении (т. е. от сервера к клиенту).

Здесь представлены основные запросы RTSP. Некоторые типичные запросы HTTP , такие как запрос OPTIONS, также доступны. Номер порта транспортного уровня по умолчанию — 554 [7] как для TCP , так и для UDP , последний редко используется для контрольных запросов.

ПАРАМЕТРЫ

Запрос OPTIONS возвращает типы запросов, которые примет сервер.
C->S: ПАРАМЕТРЫ rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 1 Требовать: неявное воспроизведение Proxy-Require: gzip-сообщенияS->C: RTSP/1.0 200 ОК CSeq: 1 Публичные: ОПИСАНИЕ, НАСТРОЙКА, РАЗБОРКА, ВОСПРОИЗВЕДЕНИЕ, ПАУЗА

ОПИСЫВАТЬ

Запрос DESCRIBE включает URL-адрес RTSP (rtsp://...) и тип данных ответа, которые могут быть обработаны. Этот ответ включает описание представления, как правило, в формате протокола описания сеанса (SDP). Помимо прочего, описание представления перечисляет потоки мультимедиа, контролируемые с помощью совокупного URL-адреса. В типичном случае для аудио- и видеопотоков существует по одному потоку мультимедиа. URL-адреса потоков мультимедиа либо получаются непосредственно из полей управления SDP, либо они получаются путем добавления поля управления SDP к совокупному URL-адресу.
C->S: ОПИСАТЬ rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 2S->C: RTSP/1.0 200 ОК CSeq: 2 База контента: rtsp://example.com/media.mp4 Тип содержимого: application/sdp Длина контента: 460 m=видео 0 RTP/AVP 96 a=control:streamid=0 a=диапазон:npt=0-7.741000 а=длина:npt=7.741000 а=rtpmap:96 MP4V-ES/5544 a=mimetype:string;"видео/MP4V-ES" a=Средняя скорость передачи данных:целое число;304018 a=StreamName:string;"намекаемая видеодорожка" m=аудио 0 RTP/AVP 97 a=control:streamid=1 a=диапазон:npt=0-7.712000 а=длина:npt=7.712000 а=rtpmap:97 mpeg4-generic/32000/2 a=mimetype:string;"audio/mpeg4-generic" a=Средняя скорость передачи данных:целое число;65790 a=StreamName:string;"намекаемая звуковая дорожка"

НАСТРАИВАТЬ

Запрос SETUP определяет, как должен транспортироваться отдельный медиапоток. Это должно быть сделано до отправки запроса PLAY. Запрос содержит URL-адрес медиапотока и спецификатор транспорта. Этот спецификатор обычно включает локальный порт для получения данных RTP (аудио или видео) и еще один для данных RTCP (метаинформация). Ответ сервера обычно подтверждает выбранные параметры и заполняет недостающие части, такие как выбранные сервером порты. Каждый медиапоток должен быть настроен с помощью SETUP до отправки запроса на совокупное воспроизведение.
C->S: НАСТРОЙКА rtsp://example.com/media.mp4/streamid=0 RTSP/1.0 CSeq: 3 Транспорт: RTP/AVP; одноадресная передача; порт_клиента=8000-8001S->C: RTSP/1.0 200 ОК CSeq: 3 Транспорт: RTP/AVP; одноадресная передача; порт_клиента=8000-8001; порт_сервера=9000-9001; ssrc=1234ABCD Сессия: 12345678C->S: НАСТРОЙКА rtsp://example.com/media.mp4/streamid=1 RTSP/1.0 CSeq: 3 Транспорт: RTP/AVP; одноадресная передача; порт_клиента=8002-8003 Сессия: 12345678S->C: RTSP/1.0 200 ОК CSeq: 3 Транспорт: RTP/AVP; одноадресная передача; порт_клиента=8002-8003; порт_сервера=9002-9003; ssrc=1234ABCD Сессия: 12345678

ИГРАТЬ

Запрос PLAY приведет к воспроизведению одного или всех потоков мультимедиа. Запросы на воспроизведение могут быть объединены путем отправки нескольких запросов PLAY. URL может быть объединенным URL (для воспроизведения всех потоков мультимедиа) или URL одного потока мультимедиа (для воспроизведения только этого потока). Можно указать диапазон. Если диапазон не указан, поток воспроизводится с начала и до конца или, если поток приостановлен, он возобновляется с точки, в которой он был приостановлен.
C->S: ВОСПРОИЗВЕДЕНИЕ rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Диапазон: npt=5-20 Сессия: 12345678S->C: RTSP/1.0 200 ОК CSeq: 4 Сессия: 12345678 RTP-информация: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

ПАУЗА

Запрос PAUSE временно останавливает один или все медиапотоки, чтобы его можно было возобновить позже с помощью запроса PLAY. Запрос содержит агрегат или URL медиапотока. Параметр диапазона в запросе PAUSE указывает, когда следует приостановить. Если параметр диапазона опущен, пауза происходит немедленно и на неопределенный срок.
C->S: ПАУЗА rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 5 Сессия: 12345678S->C: RTSP/1.0 200 ОК CSeq: 5 Сессия: 12345678

ЗАПИСЫВАТЬ

Этот метод инициирует запись диапазона медиаданных в соответствии с описанием представления. Временная метка отражает время начала и окончания (UTC). Если временной диапазон не указан, используйте время начала или окончания, указанное в описании представления. Если сеанс уже начался, начните запись немедленно. Сервер решает, следует ли сохранять записанные данные под URI запроса или другим URI. Если сервер не использует URI запроса, ответ должен быть 201 и содержать сущность, которая описывает состояния запроса и ссылается на новый ресурс, а также заголовок Location.
C->S: ЗАПИСЬ rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 6 Сессия: 12345678S->C: RTSP/1.0 200 ОК CSeq: 6 Сессия: 12345678

ОБЪЯВЛЯЕМ

Метод ANNOUNCE служит двум целям:

При отправке от клиента к серверу ANNOUNCE публикует описание презентации или медиа-объекта, идентифицированного URL-адресом запроса, на сервере. При отправке от сервера к клиенту ANNOUNCE обновляет описание сеанса в реальном времени. Если в презентацию добавляется новый медиа-поток (например, во время прямой презентации), следует снова отправить все описание презентации, а не только дополнительные компоненты, чтобы компоненты можно было удалить.
C->S: ОБЪЯВЛЕНИЕ rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 7 Дата: 23 января 1997 г., 15:35:06 по Гринвичу. Сессия: 12345678 Тип содержимого: application/sdp Длина контента: 332 в=0 o=mhandley 2890844526 2890845468 В IP4 126.16.64.4 s=Семинар СДП i=A Семинар по протоколу описания сеанса u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps [email protected] (Марк Хэндли) с=IN IP4 224.2.17.12/127 т=2873397496 2873404696 a=recvonly m=аудио 3456 RTP/AVP 0 m=видео 2232 RTP/AVP 31S->C: RTSP/1.0 200 ОК CSeq: 7

СРЫВАТЬ

Для завершения сеанса используется запрос TEARDOWN. Он останавливает все медиапотоки и освобождает все данные, связанные с сеансом, на сервере.
C->S: РАЗБОРКА rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 8 Сессия: 12345678S->C: RTSP/1.0 200 ОК CSeq: 8

GET_PARAMETER

Запрос GET_PARAMETER извлекает значение параметра представления или потока, указанного в URI. Содержание ответа и ответ оставлены на усмотрение реализации. GET_PARAMETER без тела сущности может использоваться для проверки жизнеспособности клиента или сервера («ping»).
S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 9 Content-Type: текст/параметры Сессия: 12345678 Длина контента: 15 пакеты_получены дрожаниеC->S: RTSP/1.0 200 ОК CSeq: 9 Длина контента: 46 Content-Type: текст/параметры получено пакетов: 10 джиттер: 0,3838

УСТАНОВИТЬ_ПАРАМЕТР

Этот метод запрашивает установку значения параметра для презентации или потока, указанного в URI.
C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 10 Длина контента: 20 Тип содержимого: текст/параметры barparam: барная штукаS->C: RTSP/1.0 451 Неверный параметр CSeq: 10 Длина контента: 10 Тип содержимого: текст/параметры барпарам

ПЕРЕНАПРАВИТЬ

Запрос REDIRECT информирует клиента о том, что он должен подключиться к другому серверу. Он содержит обязательный заголовок Location, который указывает, что клиент должен отправлять запросы для этого URL. Он может содержать параметр Range, который указывает, когда перенаправление вступает в силу. Если клиент хочет продолжить отправлять или получать медиа для этого URI, клиент ДОЛЖЕН отправить запрос TEARDOWN для текущего сеанса и SETUP для нового сеанса на указанном хосте.
S->C: ПЕРЕНАПРАВЛЕНИЕ rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 11 Расположение: rtsp://bigserver.com:8001 Диапазон: часы=19960213T143205Z-

Встроенные (чередующиеся) двоичные данные

Определенные конструкции брандмауэров и другие обстоятельства могут заставить сервер чередовать методы RTSP и потоковые данные. Такого чередования следует избегать, если это не необходимо, поскольку это усложняет работу клиента и сервера и налагает дополнительные накладные расходы. Чередующиеся двоичные данные СЛЕДУЕТ использовать только в том случае, если RTSP передается по TCP. Потоковые данные, такие как пакеты RTP, инкапсулируются знаком доллара ASCII (24 шестнадцатеричных), за которым следует однобайтовый идентификатор канала, за которым следует длина инкапсулированных двоичных данных в виде двоичного двухбайтового целого числа в сетевом порядке байтов. Потоковые данные следуют сразу после этого, без CRLF, но включая заголовки протокола верхнего уровня. Каждый блок $ содержит ровно одну единицу данных протокола верхнего уровня, например, один пакет RTP.
C->S: НАСТРОЙКА rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 3 Транспорт: RTP/AVP/TCP; чередование=0-1S->C: RTSP/1.0 200 ОК CSeq: 3 Дата: 05 июня 1997 г. 18:57:18 GMT Транспорт: RTP/AVP/TCP; чередование=0-1 Сессия: 12345678C->S: ВОСПРОИЗВЕДЕНИЕ rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Сессия: 12345678S->C: RTSP/1.0 200 ОК CSeq: 4 Сессия: 12345678 Дата: 05 июня 1997 г. 18:59:15 GMT RTP-информация: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234S->C: $\000{длина 2 байта}{"длина" байт данных, с заголовком RTP}S->C: $\000{длина 2 байта}{"длина" байт данных, с заголовком RTP}S->C: $\001{длина 2 байта}{"длина" байт RTCP-пакет}

RTSP через HTTP

RTSP через HTTP был определен Apple в 1999 году [9] и [1]. Он чередует видео- и аудиоданные RTP в RTSP Command Connection (как определено в RFC2326), а затем отправляет RTSP Command Connection через пару HTTP-соединений, одно из которых является долгосрочным соединением GET, а другое — долгосрочным соединением POST.

Этот метод также используется в стандарте IP-камер ONVIF и может сочетаться с HTTPS для обеспечения безопасной и зашифрованной передачи видео и аудио.

Шифрование RTSP и RTSPS

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

RTSP 2.0 (RFC7826) определяет несколько методов шифрования и вводит новый URL-адрес rtsps://, многие из которых были включены в клиенты и серверы RFC2326 RTSP 1.0.

IANA зарезервировала префикс URL rtsps:// и порт 322 для RTSPS. [10] По состоянию на сентябрь 2024 года RTSP через HTTPS был реализован в нескольких IP-камерах ONVIF, а RTSPS (с использованием URL rtsps://) был реализован в камерах видеонаблюдения Axis и Bosch, [11] FFmpeg , GStreamer , MediaMTX [12] и SharpRTSP. [13]

Скорость адаптации

RTSP с использованием RTP и RTCP позволяет реализовать адаптацию скорости. [14]

Реализации

Сервер

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

Клиент

Ссылки

  1. ↑ InfoWorld Media Group, Inc. (2 марта 1998 г.). InfoWorld. InfoWorld Media Group, Inc. стр. 18. ISSN  0199-6649.
  2. ^ Рафаэль Оссо (1999). Справочник по новым технологиям связи: следующее десятилетие. CRC Press. стр. 42. ISBN 978-1-4200-4962-6.
  3. ^ Рао, Ануп; Ланфьер, Роб. "Протокол потоковой передачи в реальном времени (RTSP)". Ietf Datatracker . Получено 23.02.2021 .
  4. ^ "RTSP prime" Хеннинг Шульцринн , Колумбийский университет (http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps) Декабрь 1996 г.
  5. ^ Шульцринне, Хеннинг ; Рао, Ануп; Ланфьер, Роб (1997-02-24). "Протокол потоковой передачи в реальном времени (RTSP) (draft-ietf-mmusic-rtsp-01.txt)". Ietf Datatracker . Получено 2021-02-23 .
  6. ^ Шульцринне, Хеннинг ; Рао, Ануп; Ланфьер, Роб (1998-01-15). "Протокол потоковой передачи в реальном времени (RTSP) (draft-ietf-mmusic-rtsp-08.txt)". Ietf Datatracker . Получено 23.02.2021 .
  7. ^ ab RFC 2326, Протокол потоковой передачи в реальном времени (RTSP) , IETF, 1998
  8. ^ Шульцринн, Хеннинг; Рао, Ануп; Ланфьер, Роб; Вестерлунд, Магнус; Штимерлинг, Мартин (декабрь 2016 г.). Штимерлинг, М. (ред.). «Протокол потоковой передачи в реальном времени версии 2.0». www.tools.ietf.org . дои : 10.17487/RFC7826 . Проверено 23 февраля 2021 г.
  9. ^ "Разработчик - QuickTime - Письма с льдины". 2013-05-01. Архивировано из оригинала 2013-05-01 . Получено 2024-09-22 .
  10. ^ «Реестр имен служб и номеров портов транспортных протоколов».
  11. ^ «Безопасная потоковая передача RTSP — SRTP/RTSPS».
  12. ^ МедиаMTX
  13. ^ "Ngraziano/SharpRTSP". GitHub .
  14. ^ Сантос, Хьюго; Круз, Руи Сантос; Нуньес, Марио Серафим (2010), «Методы адаптации скорости для веб-телевидения», Пользовательско-ориентированные медиа , Конспекты лекций Института компьютерных наук, социальной информатики и телекоммуникационной техники, том. 40, стр. 161–168, номер документа : 10.1007/978-3-642-12630-7_19, ISBN. 978-3-642-12629-1
  15. ^ "YouTube Mobile A Bust! (Заставляем 3GP/RTSP работать на WM5)". Крис Дьюк . 2007-06-23 . Получено 29 мая 2021 г.
  16. ^ cURL — Изменения
  17. ^ "Документация FFmpeg". Проект FFmpeg. 11 сентября 2012 г. Раздел 20.19 . Получено 11 сентября 2012 г.

Внешние ссылки