✖


Jump to content

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

Не путать с протоколом быстрого связующего дерева или протоколом обмена сообщениями в реальном времени .
Протокол потоковой передачи в реальном времени
Протокол связи
Аббревиатура РТСП
Цель Интернет-стриминг
Разработчик(и) RealNetworks , Netscape , Колумбийский университет
Введение апрель 1998 г .; 26 лет назад ( 1998-04 )
Уровень OSI Прикладной уровень (7)
Порт(ы)
  • 554/ПТС
  • 554/УДП
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]

Набор интернет-протоколов
Прикладной уровень
Транспортный уровень
Интернет-слой
Слой связи

РТП [ править ]

Основная статья: Транспортный протокол реального времени

Сама по себе передача потоковых данных не является задачей 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-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 приведет к воспроизведению одного или всех медиапотоков. Запросы воспроизведения можно группировать, отправляя несколько запросов 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-адрес совокупного или медиапотока. Параметр диапазона в запросе PAUSE указывает, когда делать паузу. Если параметр range опущен, пауза возникает сразу и на неопределенный срок. 
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 отправляет описание презентации или медиа-объекта, идентифицированного 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 31

S->C: RTSP/1.0 200 OK
      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 позволяет реализовать адаптацию скорости. [9]

Реализации [ править ]

Сервер [ править ]

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

Клиент [ править ]

Ссылки [ править ]

  1. ^ InfoWorld Media Group, Inc. (2 марта 1998 г.). Инфомир . InfoWorld Media Group, Inc. с. 18. ISSN   0199-6649 .
  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 г.
  7. ↑ Перейти обратно: Перейти обратно: а б 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. ^ cURL — Изменения
  12. ^ «Документация FFmpeg» . Проект FFmpeg. 11 сентября 2012 г. Раздел 20.19 . Проверено 11 сентября 2012 г.

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Real-Time_Streaming_Protocol&oldid=1217188031"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 385333a67c8cfc1637436a77247da188__1712214180
URL1:https://arc.ask3.ru/arc/aa/38/88/385333a67c8cfc1637436a77247da188.html
Заголовок, (Title) документа по адресу, URL1:
Real-Time Streaming Protocol - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)