RTSP

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Ця стаття містить неперекладені фрагменти іноземною мовою.
Ви можете допомогти проєкту, переклавши їх українською.
Модель TCP/IP (RFC 1122)
Прикладний рівень
Транспортний рівень
Мережевий рівень
Канальний рівень
Цей шаблон:

Пото́ковий протоко́л реа́льного ча́су (Real Time Streaming Protocol, RTSP) — мережевий протокол розроблений IETF в 1998 році і описаний в RFC 2326, є прикладним протоколом, призначеним для використання в системах, що працюють з мультимедіа даними, і що дозволяє клієнтові віддалено управляти потоком даних з сервера, надаючи можливість виконання команд, таких як «Старт», «Стоп», а також доступу за часом до файлів, розташованих на сервері.

RTSP не виконує стиску, а також не визначає метод інкапсуляції мультимедійних даних і транспортні протоколи. Передача потокових даних сама по собі не є частиною протоколу RTSP. Більшість серверів RTSP використовують для цього стандартний транспортний протокол реального часу, що здійснює передачу аудіо- і відеоданих.

Протокол призначений для використання в розважальних і комунікаційних системах для управління потоковим мультимедіа сервером . Протокол використовується для встановлення та управління сеансами мультимедіа між кінцевими точками. Клієнти медіа серверів використовують VCR подібні команди, такі як PLAY та PAUSE, щоб полегшити управління в реальному часі програванням медіа файлів з сервера.

Передача самих потокових даних не є завданням протоколу RTSP. Більшість серверів RTSP використовують Real-Time Transport Protocol (RTP) у поєднанні з  Real-time Control Protocol (RTCP) для доставки медіа потоку, проте деякі виробники реалізують власні транспортні протоколи. Серверне програмне забезпечення RTSP від RealNetworks, наприклад, використовує фірмовий протокол RealNetworks Real Data Transport (RDT).

RTSP розроблявся компаніями RealNetworks, Netscape і Колумбійським університетом, з першого проекту, представленого IETF в 1996 році. Він був стандартизований Multiparty Multimedia Session Control Working Group (MMUSIC WG) яка є частиною Internet Engineering Task Force (IETF) і опублікований в RFC 2326 у 1998 році.

RTSP 2.0 знаходиться в стадії розробки як заміна RTSP 1.0. RTSP 2.0 базується на RTSP 1.0, але не має зворотної сумісності з ним в своїй основній версії.

RTSP з використанням RTP і RTCP дозволяє здійснення адаптації швидкості передавання.

При всій своїй подібності до HTTP, RTSP визначає корисні керуючі послідовності в управлінні відтворенням мультимедіа.

Використовується ідентифікатор при необхідності відстежувати одночасні сесії. Як HTTP, RTSP використовує TCP для підтримки з'єднання між кінцевими точками, і в той час як більшість керуючих повідомлень RTSP відправляються клієнтом на сервер, деякі команди відправляються в іншому напрямку (тобто від сервера до клієнта). Деякі типові запити HTTP, як наприклад OPTIONS, також доступні.

За замовчуванням, номер порту транспортного рівня для RTSP —  554.

Список команд (методів)[ред. | ред. код]

  • OPTIONS — запит підтримуваних методів
  • DESCRIBE — запит опису контенту, наприклад, у форматі SDP
  • PLAY — запит початку мовлення контента
  • PAUSE — запит тимчасової зупинки мовлення
  • RECORD — запит на записування контента сервером
  • REDIRECT — перенаправлення на інший контент
  • SETUP — запит установки транспортного механізму для медіа-контента
  • ANNOUNCE — оновлення даних опису контента
  • GET_PARAMETER — запит вказаних параметрів в сервера
  • SET_PARAMETER — установка параметрів сервера
  • TEARDOWN — зупинка потоку і звільнення ресурсів

OPTIONS[ред. | ред. код]

Запит 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[ред. | ред. код]

Запит DESCRIBE включає RTSP URL (RTSP:/ / …), і тип відповіді даних, які можуть бути оброблені. Порт за замовчуванням для протоколу RTSP — 554, є однаковим для UDP(використовується в додатках які потребують мінімальних затримок передавання, де якість передавання не є найважливішим критерієм) і TCP протоколів. Відповідь цього запиту включає опис представлення даних, як правило, в форматі Session Description Protocol(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[ред. | ред. код]

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

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
       Session: 12345678

PLAY[ред. | ред. код]

Виконання запиту PLAY призведе до відтворення одного або всіх медіа потоків. Запити PLAY можуть накопичуватися якщо відправити декілька таких запитів один за одним, це призведе до відтворення потоків послідовно. 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[ред. | ред. код]

Запит PAUSE тимчасово зупиняє один або всі медіа потоки, так що надалі вони можуть бути відновлені запитом PLAY. Запит містить агрегатну URL або  URL медіа-потоку. Параметр діапазон за запитом паузу вказує, коли слід призупинити. Коли параметр відрізок не вказаний, то пауза відбувається відразу і на невизначений термін. 

 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

RECORD[ред. | ред. код]

Цей метод ініціює запис медіа-даних відповідно до опису. Мітка часу позначає час початку і час закінчення (UTC). Також, можна використовувати лише час початку або закінчення. Якщо сеанс вже почався, почати запис негайно. Сервер вирішує, де слід зберігати записані дані: на URI з якого прийшов запит, чи іншому URI. Якщо запис відбудеться з використанням URL відмінного від URL з якого надійшов запит, то відповідь сервера має бути 201 і містити об'єкт, який описує стану запиту і посилається на новий ресурс, у який буде виконуватися збереження. 

 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 служить двом цілям: При відправці від клієнта до сервера, ANNOUNCE повідомляє опис представлення або медіа-об'єкт, визначений в URL запиту до сервера.

При відправці від сервера до клієнта, ANNOUNCE оновлює опис сеансу в режимі реального часу. Якщо новий мультимедійний потік доданий до представлення (наприклад, під час живого подання), весь опис повинні бути відправлені знову. 

 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
       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[ред. | ред. код]

Запит 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[ред. | ред. код]

Запит REDIRECT повідомляє клієнту, що він повинен підключитися до іншого сервера. Він містить обов'язкове поле header Location, яке вказує, що клієнт повинен посилати запити для цього URL. Він може містити діапазон значень, які вказують, на те коли перенаправлення має відбутися. Якщо клієнт хоче продовжувати відправляти і отримувати медіа з поточного URI, клієнт повинен видати запит TEARDOWN для поточного сеансу і SETUP для нової сесії. 

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

Реалізації протоколу[ред. | ред. код]

Сервери[ред. | ред. код]

  • Darwin Streaming Server: open source версія  QuickTime Streaming Server яка підтримується Apple
  • Erlyvideo: має клієнт RTSP і може передавати відео в інші протоколи.
  • Feng: потоковий сервер з акцентом на дотриманні стандарту RFC.
  • FFmpeg: включає ffserver в GPL або LGPL потокові сервери RTSP.
  • GStreamer:основний RTSP сервер і клієнт.
  • Helix DNA Server: потоковий сервер від RealNetworks. Поставляється в вигляді відкритого коду
  • Helix Universal Server:  комерційний потоковий сервер від RealNetworks для RTSP, RTMP, МО, Silverlight і HTTP потокових мультимедіа клієнтів.
  • LIVE555: Реалізована на C++ бібліотека з відкритим кодом, включає сервер і клієнт які використовуються у добре відомих додатках VLC і mplayer.
  • pvServer: Повна назва: PacketVideo Streaming Server, це потоковий сервер, продукт Alcatel-Lucent.
  • QuickTime Streaming Server:  потоковий сервер Apple, який поставляється разом з Mac OS X Server.
  • ViaMotion: Інтегрований RTSP сервер для відео на вимогу, розроблений Anevia
  • VideoLAN: медіа-плеєр і потоковий сервер з відкритим вихідним кодом.
  • VX30: Сервер потокового відео і вбудований JAVA клієнт від  Мауа X-Stream
  • Windows Media Services: потоковий сервер Microsoft, раніше включався в Windows Server . Він використовує модифікований RTSP і розширення Windows Media
  • Wowza Media Server: Мультиформатний потоковий сервер для RTSP / RTP, RTMP, MPEG-TS, ICY, HTTP (HTTP Live Streaming, HTTP Dynamic Streaming, SmoothStreaming)
  • Xenon Streaming Server: Мобільний потоковий сервер від Vidiator Technology (US) Inc.
  • YouTube : Доступна опція потокового відтворення при перегляді сайту через мобільну версію HTTPS на комп'ютері.

Клієнти[ред. | ред. код]

Посилання[ред. | ред. код]


Інформаційні технології Це незавершена стаття про інформаційні технології.
Ви можете допомогти проєкту, виправивши або дописавши її.
Інтернет Це незавершена стаття про Інтернет.
Ви можете допомогти проєкту, виправивши або дописавши її.
Ця стаття потребує додаткових посилань на джерела для поліпшення її перевірності. Будь ласка, допоможіть удосконалити цю статтю, додавши посилання на надійні (авторитетні) джерела. Зверніться на сторінку обговорення за поясненнями та допоможіть виправити недоліки.
Матеріал без джерел може бути піддано сумніву та вилучено. (квітень 2016)
Отримано з https://uk.wikipedia.org/w/index.php?title=RTSP&oldid=41591403