Real Time Streaming Protocol ( 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: ОПЦИИ rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 1 Требовать: неявная игра Требование прокси: gzipped-messagesS-> C: RTSP / 1.0 200 ОК CSeq: 1 Общедоступные: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
ОПИСЫВАТЬ
- Запрос 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 Content-Base: rtsp: //example.com/media.mp4 Тип содержимого: приложение / sdp Длина содержимого: 460 m = видео 0 RTP / AVP 96 a = control: streamid = 0 a = диапазон: npt = 0-7,741000 a = длина: npt = 7,741000 a = rtpmap: 96 MP4V-ES / 5544 a = mimetype: string; "видео / MP4V-ES" a = AvgBitRate: целое число; 304018 a = StreamName: string; "подсказка видеодорожки" m = аудио 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: целое число; 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 ОК CSeq: 3 Транспорт: RTP / AVP; одноадресная передача; client_port = 8000-8001; server_port = 9000-9001; ssrc = 1234ABCD Сессия: 12345678C-> S: НАСТРОЙКА rtsp: //example.com/media.mp4/streamid=1 RTSP / 1.0 CSeq: 3 Транспорт: RTP / AVP; одноадресная передача; client_port = 8002-8003 Сессия: 12345678S-> C: RTSP / 1.0 200 ОК CSeq: 3 Транспорт: RTP / AVP; одноадресная передача; client_port = 8002-8003; server_port = 9002-9003; ssrc = 1234ABCD Сессия: 12345678
ИГРАТЬ
- Запрос 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-адрес или 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 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 [email protected] (Марк Хэндли) c = В 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: TEARDOWN 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 без тела объекта может использоваться для проверки работоспособности клиента или сервера («пинг»).
S-> C: GET_PARAMETER rtsp: //example.com/media.mp4 RTSP / 1.0 CSeq: 9 Content-Type: текст / параметры Сессия: 12345678 Длина содержимого: 15 packets_received дрожьC-> S: RTSP / 1.0 200 ОК CSeq: 9 Длина содержимого: 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 Длина содержимого: 20 Content-type: текст / параметры barparam: barstuffS-> C: RTSP / 1.0 451 неверный параметр CSeq: 10 Длина содержимого: 10 Content-type: текст / параметры барпарам
ПЕРЕНАПРАВЛЕНИЕ
- Запрос REDIRECT сообщает клиенту, что он должен подключиться к другому серверу. Он содержит обязательный заголовок Location, который указывает, что клиент должен отправлять запросы для этого URL-адреса. Он может содержать параметр Range, указывающий, когда перенаправление вступает в силу. Если клиент хочет продолжить отправку или получение мультимедиа для этого URI, клиент ДОЛЖЕН отправить запрос TEARDOWN для текущего сеанса и SETUP для нового сеанса на указанном хосте.
S-> C: ПОВРЕДИТЬ 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; чередование = 0-1S-> C: RTSP / 1.0 200 ОК CSeq: 3 Дата: 5 июня 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 Дата: 5 июня 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 с использованием RTP и RTCP позволяет реализовать адаптацию скорости. [9]
Реализации
Сервер
- 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
- YouTube : доступна опция потоковой передачи при просмотре сайта через мобильную версию HTTPS на рабочем столе.
Многие камеры видеонаблюдения / безопасности, часто называемые IP-камерами , также поддерживают потоковую передачу RTSP, особенно с профилями ONVIF G, S, T.
Клиент
- Астра
- cURL (начиная с версии 7.20.0–9 февраля 2010 г. [10] )
- FFmpeg [11]
- GStreamer
- JetAudio
- LIVE555 liveMedia / openRTSP : серверные и клиентские библиотеки C ++ с открытым исходным кодом, используемые в известных клиентах, таких как VLC и mplayer .
- Классический медиаплеер
- MPlayer
- MythTV через Freebox
- QuickTime
- Реальный игрок
- Skype
- Spotify
- Медиаплеер VLC
- Winamp
- Проигрыватель Windows Media
- xine
- ZoneMinder
- Motion_ (программное обеспечение для наблюдения)
Рекомендации
- ^ InfoWorld Media Group, Inc. (2 марта 1998). InfoWorld . InfoWorld Media Group, Inc. стр. 18. ISSN 0199-6649 .
- ^ Рафаэль Оссо (1999). Справочник по новейшим коммуникационным технологиям: следующее десятилетие . CRC Press. п. 42. ISBN 978-1-4200-4962-6.
- ^ Рао, Ануп; Ланфье, Роб. «Протокол потоковой передачи в реальном времени (RTSP)» . tools.ietf.org . Проверено 23 февраля 2021 .
- ^ "RTSP prime" Хеннинг Шульцринн , Колумбийский университет ( http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps ), декабрь 1996 г.
- ^ Шульцринне, Хеннинг ; Рао, Ануп; Ланфье, Роб (24 февраля 1997). «Протокол потоковой передачи в реальном времени (RTSP) (draft-ietf-mmusic-rtsp-01.txt)» . tools.ietf.org . Проверено 23 февраля 2021 .
- ^ Шульцринне, Хеннинг ; Рао, Ануп; Ланфье, Роб (1998-01-15). «Протокол потоковой передачи в реальном времени (RTSP) (draft-ietf-mmusic-rtsp-08.txt)» . tools.ietf.org . Проверено 23 февраля 2021 .
- ^ a b RFC 2326, Протокол потоковой передачи в реальном времени (RTSP) , IETF, 1998
- ^ Шульцринне, Хеннинг; Рао, Ануп; Ланфье, Роб; Вестерлунд, Магнус; Штимерлинг, Мартин (декабрь 2016 г.). «Протокол потоковой передачи в реальном времени версии 2.0» . tools.ietf.org . Проверено 23 февраля 2021 .
- ^ Сантос, Хьюго; Круз, Руи Сантос; Нунес, Марио Серафим (2010), «Методы адаптации скорости для WebTV», Методы адаптации скорости для WebTV , Лекционные заметки Института компьютерных наук, социальной информатики и телекоммуникационной инженерии, 40 , стр. 161–168, DOI : 10.1007 / 978 -3-642-12630-7_19 , ISBN 978-3-642-12629-1
- ^ cURL - Изменения
- ^ «Документация FFmpeg» . Проект FFmpeg. 11 сентября 2012 г. Раздел 20.19 . Проверено 11 сентября 2012 .
Внешние ссылки
- «Информация и обновления протокола потоковой передачи в реальном времени» . Архивировано из оригинала на 2007-03-06., центральное хранилище информации о RTSP.
- «Туннелирование RTSP и RTP через HTTP» . Архивировано из оригинала на 2013-05-01., Стандартное решение, помогающее RTSP работать через брандмауэры и веб-прокси.
- « Управляемая агрегация мультимедиа с использованием Rtsp и Rtp ». Проводит разработчика через реализацию соответствующих стандартов RtspClient и RtspServer.