Протокол потоковой передачи в реальном времени - Real Time Streaming Protocol

В Протокол потоковой передачи в реальном времени (RTSP) является сетевым управлением протокол разработан для использования в развлекательных и коммуникационных системах для управления потоковое мультимедиа серверы. Протокол используется для установления и управления медиа-сеансами между конечными точками. Выдача клиентов медиа-серверов VHS -style команды, такие как играть в, записывать и Пауза, для облегчения управления в реальном времени потоковой передачей мультимедиа с сервера на клиент (видео по запросу) или от клиента на сервер (запись голоса).

Сама по себе передача потоковых данных не является задачей RTSP. Большинство серверов RTSP используют Транспортный протокол в реальном времени (RTP) в сочетании с Протокол управления в реальном времени (RTCP) для доставки медиапотока. Однако некоторые поставщики реализуют собственные транспортные протоколы. Программное обеспечение сервера RTSP от RealNetworks, например, также использовала проприетарную технологию RealNetworks. Реальный перенос данных (RDT).

RTSP был разработан RealNetworks, Netscape^[1] и Колумбийский университет, первый проект был представлен в IETF в 1996 году.^[2] Он был стандартизирован Рабочей группой Multiparty Multimedia Session Control Working Group (MMUSIC WG) Инженерная группа Интернета (IETF) и опубликовано как RFC 2326 в 1998 г.^[3] RTSP 2.0 опубликован как RFC 7826 в 2016 году в качестве замены RTSP 1.0. RTSP 2.0 основан на RTSP 1.0, но не имеет обратной совместимости, кроме как в основном механизме согласования версии.

Директивы протокола

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

Здесь представлены основные запросы RTSP. Некоторые типичные HTTP-запросы, как и запрос OPTIONS, также доступны. Транспортный уровень по умолчанию номер порта это 554^[3] для обоих TCP и UDP, последний редко используется для управляющих запросов.

ОПЦИИ: Запрос OPTIONS возвращает типы запросов, которые сервер примет.

C-> S: OPTIONS rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 1 Require: implicit-play Proxy-Require: gzipped-messagesS-> C: RTSP / 1.0 200 OK CSeq: 1 Public: DESCRIBE , НАСТРОЙКА, TEARDOWN, ИГРАТЬ, ПАУЗА

ОПИСЫВАТЬ: Запрос DESCRIBE включает RTSP URL (rtsp: // ...) и тип данных ответа, которые можно обработать. Этот ответ включает описание презентации, обычно в Протокол описания сеанса (SDP) формат. Среди прочего, в описании презентации перечислены медиапотоки, управляемые с помощью совокупного URL. В типичном случае существует по одному медиапотоку для аудио и видеопотока. URL-адреса медиапотока либо получаются непосредственно из полей управления SDP, либо путем добавления поля управления SDP к совокупному URL-адресу.

C-> S: DESCRIBE rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 2S-> C: RTSP / 1.0 200 OK CSeq: 2 Content-Base: rtsp: //example.com/media.mp4 Content-Type: application / sdp Content-Length: 460 m = video 0 RTP / AVP 96 a = control: streamid = 0 a = range: npt = 0-7.741000 a = length: npt = 7.741000 a = rtpmap: 96 MP4V- ES / 5544 a = mimetype: string; "video / MP4V-ES" a = AvgBitRate: integer; 304018 a = StreamName: string; "подсказка видеодорожки" m = audio 0 RTP / AVP 97 a = control: streamid = 1 a = диапазон: npt = 0-7.712000 a = длина: npt = 7.712000 a = rtpmap: 97 mpeg4-generic / 32000/2 a = mimetype: string; "audio / mpeg4-generic" a = AvgBitRate: integer; 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; одноадресная передача; client_port = 8000-8001S-> C: RTSP / 1.0 200 OK CSeq : 3 Транспорт: RTP / AVP; одноадресная передача; client_port = 8000-8001; server_port = 9000-9001; ssrc = 1234ABCD Сессия: 12345678C-> S: SETUP rtsp: //example.com/media.mp4/streamid=1 RTSP / 1.0 CSeq: 3 Транспорт: RTP / AVP; одноадресная передача; client_port = 8002-8003 Сессия: 12345678S-> C: RTSP / 1.0 200 OK CSeq: 3 Транспорт: RTP / AVP; одноадресная передача; client_port = 8002-8003; server_port = 9002- 9003; ssrc = 1234ABCD Сессия: 12345678

ИГРАТЬ В: Запрос PLAY приведет к воспроизведению одного или всех медиапотоков. Запросы на воспроизведение можно складывать, отправляя несколько запросов на воспроизведение. URL-адрес может быть совокупным URL-адресом (для воспроизведения всех медиапотоков) или отдельным URL-адресом медиапотока (для воспроизведения только этого потока). Можно указать диапазон. Если диапазон не указан, поток воспроизводится с начала и воспроизводится до конца, или, если поток приостановлен, он возобновляется с того места, где он был приостановлен.

C-> S: PLAY rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 4 Диапазон: npt = 5-20 Сессия: 12345678S-> C: RTSP / 1.0 200 OK CSeq: 4 Сессия: 12345678 RTP- Информация: url = rtsp: //example.com/media.mp4/streamid=0; seq = 9810092; rtptime = 3450012

ПАУЗА: Запрос PAUSE временно останавливает один или все медиапотоки, чтобы позже его можно было возобновить с помощью запроса PLAY. Запрос содержит агрегированный URL-адрес или URL-адрес медиапотока. Параметр диапазона в запросе PAUSE указывает, когда следует приостановить. Если параметр диапазона опущен, пауза происходит немедленно и на неопределенный срок.

C-> S: PAUSE rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 5 Session: 12345678 S-> C: RTSP / 1.0 200 OK CSeq: 5 Session: 12345678

ЗАПИСЫВАТЬ: Этот метод инициирует запись ряда мультимедийных данных в соответствии с описанием презентации. Отметка времени отражает время начала и окончания (UTC). Если временной диапазон не указан, используйте время начала или окончания, указанное в описании презентации. Если сеанс уже начался, немедленно начните запись. Сервер решает, хранить ли записанные данные под URI запроса или под другим URI. Если сервер не использует URI запроса, ответ должен быть 201 и содержать объект, который описывает состояния запроса и ссылается на новый ресурс, и заголовок Location.

C-> S: ЗАПИСЬ rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 6 Сессия: 12345678 S-> C: RTSP / 1.0 200 OK CSeq: 6 Сессия: 12345678

ОБЪЯВЛЕНИЕ: Метод ANNOUNCE служит двум целям:; При отправке от клиента к серверу ANNOUNCE отправляет на сервер описание презентации или медиа-объекта, идентифицированного URL-адресом запроса. При отправке с сервера на клиент ANNOUNCE обновляет описание сеанса в реальном времени. Если к презентации добавляется новый медиапоток (например, во время презентации в реальном времени), все описание презентации должно быть отправлено снова, а не только дополнительные компоненты, чтобы компоненты можно было удалить.

C-> S: ОБЪЯВЛЕНИЕ rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 7 Дата: 23 января 1997 г., 15:35:06 GMT Сессия: 12345678 Content-Type: application / sdp Content-Length: 332 v = 0 o = mhandley 2890844526 2890845468 IN IP4 126.16.64.4 s = Семинар SDP i = Семинар по протоколу описания сеанса u = http: //www.cs.ucl.ac.uk/staff/M.Handley/sdp.03 .ps [email protected] (Марк Хэндли) c = IN IP4 224.2.17.12/127 t = 2873397496 2873404696 a = recvonly m = audio 3456 RTP / AVP 0 m = video 2232 RTP / AVP 31S-> C: RTSP /1.0 200 ОК CSeq: 7

СРЫВАТЬ: Запрос TEARDOWN используется для завершения сеанса. Он останавливает все медиапотоки и освобождает все данные, связанные с сеансом, на сервере.

C-> S: TEARDOWN rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 8 Сессия: 12345678 S-> C: RTSP / 1.0 200 OK CSeq: 8

GET_PARAMETER: Запрос GET_PARAMETER извлекает значение параметра презентации или потока, указанного в URI. Содержание ответа и ответа оставлено на усмотрение реализации. GET_PARAMETER без тела объекта может использоваться для проверки работоспособности клиента или сервера («пинг»).

S-> C: GET_PARAMETER rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 9 Content-Type: text / parameters Session: 12345678 Content-Length: 15 packets_received jitter C-> S: RTSP / 1.0 200 OK CSeq : 9 Content-Length: 46 Content-Type: текст / параметры packets_received: 10 джиттер: 0,3838

SET_PARAMETER: Этот метод запрашивает установку значения параметра для презентации или потока, указанного в URI.

C-> S: SET_PARAMETER rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 10 Content-length: 20 Content-type: text / parameters barparam: barstuffS-> C: RTSP / 1.0 451 Недействительный параметр CSeq: 10 Длина содержимого: 10 Тип содержимого: текст / параметры barparam

ПЕРЕНАПРАВЛЕНИЕ: Запрос REDIRECT сообщает клиенту, что он должен подключиться к другому серверу. Он содержит обязательный заголовок Location, который указывает, что клиент должен отправлять запросы для этого URL. Он может содержать параметр Range, указывающий, когда перенаправление вступает в силу. Если клиент хочет продолжить отправку или получение мультимедиа для этого URI, клиент ДОЛЖЕН выдать запрос TEARDOWN для текущего сеанса и SETUP для нового сеанса на указанном хосте.

S-> C: REDIRECT rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 11 Расположение: rtsp: //bigserver.com: 8001 Диапазон: clock = 19960213T143205Z-

Встроенные (чередующиеся) двоичные данные: Определенные конструкции брандмауэра и другие обстоятельства могут вынудить сервер чередовать методы RTSP и передавать данные в потоке. Как правило, этого чередования следует избегать без необходимости, поскольку оно усложняет работу клиента и сервера и накладывает дополнительные накладные расходы. Чередующиеся двоичные данные СЛЕДУЕТ использовать только в том случае, если RTSP передается по TCP. Потоковые данные, такие как пакеты RTP, инкапсулируются знаком доллара ASCII (24 шестнадцатеричного числа), за которым следует однобайтовый идентификатор канала, за которым следует длина инкапсулированных двоичных данных в виде двоичного двухбайтового целого числа в сетевом порядке байтов. Данные потока следуют сразу же после этого, без CRLF, но включая заголовки протокола верхнего уровня. Каждый блок $ содержит ровно одну единицу данных протокола верхнего уровня, например, один пакет RTP.

C-> S: НАСТРОЙКА rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 3 Транспорт: RTP / AVP / TCP; interleaved = 0-1S-> C: RTSP / 1.0 200 OK CSeq: 3 Дата: 05 июня 1997 г. 18:57:18 GMT Транспорт: RTP / AVP / TCP; interleaved = 0-1 Сессия: 12345678C-> S: PLAY rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 4 Session: 12345678S -> C: RTSP / 1.0 200 OK CSeq: 4 Сессия: 12345678 Дата: 05 июня 1997 г., 18:59:15 GMT RTP-информация: url = rtsp: //example.com/media.mp4; seq = 232433; rtptime = 972948234S-> C: $ 00 {2 байта} {"длина" байтов данных, с заголовком RTP} S-> C: $ 00 {2 байта длины} {"длина" байтов данных, с заголовком RTP} S- > C: $ 01 {длина 2 байта} {"длина" байтов пакета RTCP}

Адаптация скорости

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

Реализации

Сервер

Сервер потоковой передачи Дарвина: Версия QuickTime Streaming Server с открытым исходным кодом, поддерживаемая Apple.
Фэн: Экономичный и средний потоковый сервер с упором на соответствие RFC.
GStreamer на основе RTSP-сервера и клиента.
Сервер Helix DNA: RealNetworks 'потоковый сервер. Поставляется как с открытым исходным кодом, так и с проприетарными версиями.
Универсальный сервер Helix: RealNetworks коммерческий сервер потоковой передачи для клиентов потокового мультимедиа RTSP, RTMP, iOS, Silverlight и HTTP
LIVE555 liveMedia / openRTSP: Открытый исходный код C ++ серверные и клиентские библиотеки, используемые в известных клиентах, таких как VLC и mplayer.
Проворный стример поддерживает ввод с извлечением и объявлением по протоколу RTSP с чередованием вывода воспроизведения по протоколу TCP.
pvServer: Раньше назывался PacketVideo Streaming Server, это продукт для потокового сервера Alcatel-Lucent.
Сервер потоковой передачи QuickTime: Потоковый сервер Apple с закрытым исходным кодом, который поставляется с Mac OS X Server.
VideoLAN: Медиаплеер с открытым исходным кодом и потоковый сервер.
Службы Windows Media: Потоковый сервер Microsoft, ранее включенный в Windows Server который использует RTSP, измененный с помощью Расширения Windows Media
Wowza Streaming Engine: Многоформатный потоковый сервер для RTSP / RTP, RTMP, MPEG-TS, ICY, HTTP (HTTP Live Streaming, HTTP динамическая потоковая передача, Гладкая потоковая передача, MPEG-DASH ), WebRTC
YouTube: Доступна опция потоковой передачи при просмотре сайта через мобильную версию HTTPS на рабочем столе.
Motion_ (программное обеспечение для наблюдения)

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

Клиент

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

внешняя ссылка

«Информация и обновления протокола потоковой передачи в реальном времени». Архивировано из оригинал на 2007-03-06., центральное хранилище информации о RTSP.
«Туннелирование RTSP и RTP через HTTP». Архивировано из оригинал на 2013-05-01., Стандартное решение, помогающее RTSP работать через брандмауэры и веб-прокси.
"Управляемое агрегирование мультимедиа с использованием Rtsp и Rtp ", Знакомит разработчика с реализацией соответствующих стандартов RtspClient и RtspServer.

[Inc.1998-1] InfoWorld Media Group, Inc. (2 марта 1998 г.). InfoWorld. InfoWorld Media Group, Inc. стр. 18. ISSN 0199-6649.

[Osso1999-2] Рафаэль Оссо (1999). Справочник по новейшим коммуникационным технологиям: следующее десятилетие. CRC Press. п. 42. ISBN 978-1-4200-4962-6.

[:0-3] а ^б RFC 2326, Протокол потоковой передачи в реальном времени (RTSP), IETF, 1998 г.

[4] Сантос, Хьюго; Круз, Руи Сантос; Нуньес, Марио Серафим (2010), «Методы адаптации скорости для WebTV», Методы адаптации оценок для WebTV, Конспект лекций Института компьютерных наук, социальной информатики и телекоммуникационной инженерии, 40, стр. 161–168, Дои:10.1007/978-3-642-12630-7_19, ISBN 978-3-642-12629-1

[5] URL - Изменения

[6] «Документация FFmpeg». Проект FFmpeg. 11 сентября 2012 г. Раздел 20.19. Получено 2012-09-11.

[1]

[2]

[3]

[4]

[5]

[6]