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

Протокол потоковой передачи в реальном времени
Протокол связи
Аббревиатура	РТСП
Цель	Интернет-стриминг
Разработчик(и)	RealNetworks , Netscape , Колумбийский университет
Введение	апрель 1998 г .; 26 лет назад
Уровень OSI	Прикладной уровень (7)
Порт(ы)	554/ПТС ; 554/УДП ;
RFC(ы)	RFC 2326 , 7826

Протокол потоковой передачи в реальном времени ( 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]

RTP

Сама по себе передача потоковых данных не является задачей RTSP. Большинство серверов RTSP используют транспортный протокол реального времени (RTP) в сочетании с протоколом управления в реальном времени (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:  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, SETUP, TEARDOWN, PLAY, PAUSE

ОПИСЫВАТЬ

Запрос DESCRIBE включает URL-адрес RTSP (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;"hinted video track"      m=audio 0 RTP/AVP 97      a=control:streamid=1      a=range:npt=0-7.712000      a=length:npt=7.712000      a=rtpmap:97 mpeg4-generic/32000/2      a=mimetype:string;"audio/mpeg4-generic"      a=AvgBitRate:integer;65790      a=StreamName:string;"hinted audio track"

НАСТРАИВАТЬ

Запрос SETUP определяет, как должен транспортироваться один медиапоток. Это необходимо сделать до отправки запроса PLAY. Запрос содержит URL-адрес медиапотока и спецификатор транспорта. Этот спецификатор обычно включает локальный порт для приема данных RTP (аудио или видео) и другой для данных RTCP (метаинформации). Ответ сервера обычно подтверждает выбранные параметры и заполняет недостающие части, например, выбранные сервером порты. Каждый медиапоток должен быть настроен с помощью SETUP, прежде чем можно будет отправить совокупный запрос на воспроизведение.

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0      CSeq: 3      Transport: RTP/AVP;unicast;client_port=8000-8001S->C: RTSP/1.0 200 OK      CSeq: 3      Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD      Session: 12345678C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0      CSeq: 3      Transport: RTP/AVP;unicast;client_port=8002-8003      Session: 12345678S->C: RTSP/1.0 200 OK      CSeq: 3      Transport: RTP/AVP;unicast;client_port=8002-8003;server_port=9002-9003;ssrc=1234ABCD      Session: 12345678

ИГРАТЬ

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

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 4      Range: npt=5-20      Session: 12345678S->C: RTSP/1.0 200 OK      CSeq: 4      Session: 12345678      RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012

ПАУЗА

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

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

ЗАПИСЫВАТЬ

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

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

ОБЪЯВИТЬ

Метод ОБЪЯВЛЕНИЕ служит двум целям:

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

C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 7      Date: 23 Jan 1997 15:35:06 GMT      Session: 12345678      Content-Type: application/sdp      Content-Length: 332      v=0      o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4      s=SDP Seminar      i=A Seminar on the session description protocol      u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps      [email protected] (Mark Handley)      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 OK      CSeq: 7

СРЫВАТЬ

Запрос TEARDOWN используется для завершения сеанса. Он останавливает все медиапотоки и освобождает все данные, связанные с сеансом, на сервере.

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

ПОЛУЧИТЬ_ПАРАМЕТР

Запрос 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      jitterC->S: RTSP/1.0 200 OK      CSeq: 9      Content-Length: 46      Content-Type: text/parameters      packets_received: 10      jitter: 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 Invalid Parameter      CSeq: 10      Content-length: 10      Content-type: text/parameters      barparam

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

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

S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 11      Location: rtsp://bigserver.com:8001      Range: clock=19960213T143205Z-

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

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

C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 3      Transport: RTP/AVP/TCP;interleaved=0-1S->C: RTSP/1.0 200 OK      CSeq: 3      Date: 05 Jun 1997 18:57:18 GMT      Transport: RTP/AVP/TCP;interleaved=0-1      Session: 12345678C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 4      Session: 12345678S->C: RTSP/1.0 200 OK      CSeq: 4      Session: 12345678      Date: 05 Jun 1997 18:59:15 GMT      RTP-Info: url=rtsp://example.com/media.mp4;seq=232433;rtptime=972948234S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}S->C: $\000{2 byte length}{"length" bytes data, w/RTP header}S->C: $\001{2 byte length}{"length" bytes  RTCP packet}

Адаптация тарифа

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

Реализации

Сервер

Darwin Streaming Server : версия сервера QuickTime Streaming Server с открытым исходным кодом, поддерживаемая Apple.
RTSP-сервер и клиент на базе GStreamer .
Helix DNA Server : RealNetworks потоковый сервер . Поставляется как с открытым исходным кодом, так и с проприетарной версией.
Helix Universal Server : коммерческий потоковый сервер RealNetworks для клиентов потокового мультимедиа RTSP, RTMP, iOS, Silverlight и HTTP.
LIVE555 liveMedia/openRTSP : Серверные и клиентские библиотеки C++ с открытым исходным кодом , используемые в таких известных клиентах, как VLC и mplayer .
Motion: бесплатное приложение для видеонаблюдения для Linux.
Nimble Streamer поддерживает ввод запроса и объявления 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 Dynamic Streaming , Smooth Streaming , MPEG-DASH ), WebRTC.
В июне 2007 года YouTube реализовал мобильный веб- интерфейс, который передает видео через этот протокол. ^[10]

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

Клиент

Астра
cURL (начиная с версии 7.20.0 — 9 февраля 2010 г.) ^[11])
FFmpeg ^[12]
GStreamer
ДжетАудио
LIVE555 liveMedia/openRTSP : Серверные и клиентские библиотеки C++ с открытым исходным кодом , используемые в таких известных клиентах, как VLC и mplayer .
Медиаплеер классический
MPlayer
MythTV через Freebox
QuickTime
RealPlayer
Скайп
Спотифай
медиаплеер VLC
Винамп
Проигрыватель Windows Media
ксин
ЗонаМеньше
Движение (программное обеспечение для наблюдения)

Ссылки

^ InfoWorld Media Group, Inc. (2 марта 1998 г.). Инфомир . InfoWorld Media Group, Inc. с. 18. ISSN 0199-6649 .
^ Рафаэль Оссо (1999). Справочник по новым коммуникационным технологиям: следующее десятилетие . ЦРК Пресс. п. 42. ИСБН 978-1-4200-4962-6 .
^ Рао, Ануп; Ланфье, Роб. «Протокол потоковой передачи в реальном времени (RTSP)» . Ietf Datatracker . Проверено 23 февраля 2021 г.
^ "RTSP prime" Хеннинг Шульцринн , Колумбийский университет ( http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps ), декабрь 1996 г.
^ Шульцринн, Хеннинг ; Рао, Ануп; Ланфьер, Роб (24 февраля 1997 г.). «Протокол потоковой передачи в реальном времени (RTSP) (draft-ietf-mmusic-rtsp-01.txt)» . Ietf Datatracker . Проверено 23 февраля 2021 г.
^ Шульцринн, Хеннинг ; Рао, Ануп; Ланфье, Роб (15 января 1998 г.). «Протокол потоковой передачи в реальном времени (RTSP) (draft-ietf-mmusic-rtsp-08.txt)» . Ietf Datatracker . Проверено 23 февраля 2021 г.
^ Jump up to: ^а ^б RFC 2326, Протокол потоковой передачи в реальном времени (RTSP) , IETF, 1998 г.
^ Шульцринн, Хеннинг; Рао, Ануп; Ланфьер, Роб; Вестерлунд, Магнус; Штимерлинг, Мартин (декабрь 2016 г.). Штимерлинг, М. (ред.). «Протокол потоковой передачи в реальном времени версии 2.0» . www.tools.ietf.org . дои : 10.17487/RFC7826 . Проверено 23 февраля 2021 г.
^ Сантос, Хьюго; Круз, Руи Сантос; Нуньес, Марио Серафим (2010), «Методы адаптации скорости для веб-телевидения», Пользовательско-ориентированные медиа , Конспекты лекций Института компьютерных наук, социальной информатики и телекоммуникационной техники, том. 40, стр. 161–168, номер документа : 10.1007/978-3-642-12630-7_19 , ISBN. 978-3-642-12629-1
^ «YouTube Mobile — это провал! (Запуск 3GP/RTSP для работы на WM5)» . Крис Дюк . 23 июня 2007 г. Проверено 29 мая 2021 г.
^ cURL — Изменения
^ «Документация FFmpeg» . Проект FFmpeg. 11 сентября 2012 г. Раздел 20.19 . Проверено 11 сентября 2012 г.

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

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

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

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

[3] Рао, Ануп; Ланфье, Роб. «Протокол потоковой передачи в реальном времени (RTSP)» . Ietf Datatracker . Проверено 23 февраля 2021 г.

[4] "RTSP prime" Хеннинг Шульцринн , Колумбийский университет ( http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps ), декабрь 1996 г.

[5] Шульцринн, Хеннинг ; Рао, Ануп; Ланфьер, Роб (24 февраля 1997 г.). «Протокол потоковой передачи в реальном времени (RTSP) (draft-ietf-mmusic-rtsp-01.txt)» . Ietf Datatracker . Проверено 23 февраля 2021 г.

[6] Шульцринн, Хеннинг ; Рао, Ануп; Ланфье, Роб (15 января 1998 г.). «Протокол потоковой передачи в реальном времени (RTSP) (draft-ietf-mmusic-rtsp-08.txt)» . Ietf Datatracker . Проверено 23 февраля 2021 г.

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

[8] Шульцринн, Хеннинг; Рао, Ануп; Ланфьер, Роб; Вестерлунд, Магнус; Штимерлинг, Мартин (декабрь 2016 г.). Штимерлинг, М. (ред.). «Протокол потоковой передачи в реальном времени версии 2.0» . www.tools.ietf.org . дои : 10.17487/RFC7826 . Проверено 23 февраля 2021 г.

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

[10] «YouTube Mobile — это провал! (Запуск 3GP/RTSP для работы на WM5)» . Крис Дюк . 23 июня 2007 г. Проверено 29 мая 2021 г.

[11] URL — Изменения

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

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]