Протокол потоковой передачи в реальном времени - Real Time Streaming Protocol
Real Time Streaming Protocol ( RTSP ) представляет собой сеть управления протокол предназначен для использования в развлекательных и коммуникационных систем для управления потокового мультимедиа серверов . Протокол используется для установления и управления медиа-сеансами между конечными точками. Клиенты медиа-серверов выдают такие команды, как воспроизведение , запись и пауза , для облегчения управления в реальном времени потоковой передачей мультимедиа от сервера к клиенту (видео по запросу) или от клиента к серверу (запись голоса).
История
Протокол RTSP был разработан RealNetworks , Netscape и Колумбийским университетом . Первый проект был представлен в IETF в октябре 1996 года компаниями Netscape и Progressive Networks , после чего Хеннинг Шульцринн из Колумбийского университета представил "RTSP" ("RTSP prime") в декабре 1996 года. Два проекта были объединены для стандартизации на Multiparty Multimedia Session Контрольная рабочая группа (MMUSIC WG) Инженерной группы Интернета (IETF) и другие проекты были опубликованы рабочей группой. Предлагаемый стандарт для RTSP был опубликован в RFC 2326 в 1998 году RTSP 2,0 опубликован в RFC 7826 в 2016 году в качестве замены RTSP 1.0. RTSP 2.0 основан на RTSP 1.0, но не имеет обратной совместимости, кроме как в механизме согласования базовой версии, и остается «предлагаемым стандартом».
Набор интернет-протоколов |
---|
Уровень приложения |
Транспортный уровень |
Интернет-уровень |
Связующий слой |
RTP
Сама по себе передача потоковых данных не является задачей RTSP. Большинство серверов RTSP используют транспортный протокол реального времени (RTP) в сочетании с протоколом управления в реальном времени (RTCP) для доставки медиапотока. Однако некоторые поставщики реализуют собственные транспортные протоколы. Программное обеспечение сервера RTSP от RealNetworks , например, также использовало проприетарный протокол Real Data Transport (RDT) RealNetworks .
Директивы протокола
Хотя RTSP в некотором смысле похож на HTTP , он определяет управляющие последовательности, полезные для управления воспроизведением мультимедиа. В то время как HTTP не имеет состояния , RTSP имеет состояние; идентификатор используется, когда необходимо отслеживать параллельные сеансы. Как и HTTP, RTSP использует TCP для поддержания сквозного соединения, и хотя большинство управляющих сообщений RTSP отправляются клиентом на сервер, некоторые команды передаются в другом направлении (т. Е. От сервера к клиенту).
Здесь представлены основные запросы RTSP. Также доступны некоторые типичные HTTP-запросы , такие как запрос OPTIONS. Номер порта транспортного уровня по умолчанию - 554 как для TCP, так и для UDP , последний редко используется для запросов управления.
ПАРАМЕТРЫ
- Запрос OPTIONS возвращает типы запросов, которые сервер примет.
C->S: OPTIONS rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 1 Require: implicit-play Proxy-Require: gzipped-messages S->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: 2 S->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-8001 S->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD Session: 12345678 C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003 Session: 12345678 S->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 приведет к воспроизведению одного или всех медиапотоков. Запросы на воспроизведение можно складывать, отправляя несколько запросов на воспроизведение. URL-адрес может быть совокупным URL-адресом (для воспроизведения всех потоков мультимедиа) или отдельным URL-адресом мультимедийного потока (для воспроизведения только этого потока). Можно указать диапазон. Если диапазон не указан, поток воспроизводится с начала и воспроизводится до конца, или, если поток приостановлен, он возобновляется с того места, где он был приостановлен.
C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Range: npt=5-20 Session: 12345678 S->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-адрес или 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: RECORD rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 6 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 6 Session: 12345678
ОБЪЯВЛЕНИЕ
Метод ANNOUNCE служит двум целям:
- При отправке от клиента к серверу ANNOUNCE отправляет на сервер описание презентации или медиа-объекта, идентифицированного URL-адресом запроса. При отправке с сервера на клиент ANNOUNCE обновляет описание сеанса в реальном времени. Если к презентации добавляется новый медиапоток (например, во время прямой презентации), все описание презентации должно быть отправлено снова, а не только дополнительные компоненты, чтобы компоненты можно было удалить.
C-> S: ОБЪЯВЛЕНИЕ rtsp: //example.com/media.mp4 RTSP / 1.0
CSeq: 7
Дата: 23 января 1997 г., 15:35:06 GMT
Сессия: 12345678
Тип содержимого: приложение / sdp
Длина содержимого: 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
e=mjh@isi.edu (Марк Хэндли)
c = В IP4 224.2.17.12/127
т = 2873397496 2873404696
a = recvonly
m = аудио 3456 RTP / AVP 0
m = видео 2232 RTP / AVP 31
S-> C: RTSP / 1.0 200 ОК
CSeq: 7
СРЫВАТЬ
- Запрос TEARDOWN используется для завершения сеанса. Он останавливает все медиапотоки и освобождает все данные, связанные с сеансом, на сервере.
C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 8 Session: 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: 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: barstuff S->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-1 S->C: RTSP/1.0 200 OK CSeq: 3 Date: 05 Jun 1997 18:57:18 GMT Transport: RTP/AVP/TCP;interleaved=0-1 Session: 12345678 C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0 CSeq: 4 Session: 12345678 S->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=972948234 S->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 позволяет реализовать адаптацию скорости.
Реализации
Сервер
- Darwin Streaming Server : версия QuickTime Streaming Server с открытым исходным кодом, поддерживаемая Apple.
- Фэн : Экономичный и средний потоковый сервер с упором на соответствие RFC.
- Сервер и клиент RTSP на основе GStreamer .
- Сервер Helix DNA : потоковый сервер RealNetworks . Поставляется как с открытым исходным кодом, так и с проприетарными версиями.
- Helix Universal Server : коммерческий сервер потоковой передачи RealNetworks для клиентов потокового мультимедиа RTSP, RTMP, iOS, Silverlight и HTTP.
- LIVE555 liveMedia / openRTSP : серверные и клиентские библиотеки C ++ с открытым исходным кодом, используемые в хорошо известных клиентах, таких как VLC и mplayer .
- Движение : бесплатное приложение для систем видеонаблюдения для Linux.
- Nimble Streamer поддерживает ввод с извлечением и объявлением по протоколу RTSP с чередованием вывода воспроизведения по протоколу TCP.
- pvServer : ранее называвшийся PacketVideo Streaming Server, это продукт для потокового сервера Alcatel-Lucent.
- QuickTime Streaming Server : потоковый сервер 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 внедрил мобильный веб- интерфейс, который обслуживает видео по этому протоколу.
Многие камеры видеонаблюдения / безопасности, часто называемые IP-камерами , также поддерживают потоковую передачу RTSP, особенно с профилями ONVIF G, S, T.
Клиент
- Астра
- cURL (начиная с версии 7.20.0–9 февраля 2010 г.)
- FFmpeg
- 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, соответствующих стандартам.