RTSP
Пото́ковий протоко́л реа́льного ча́су (Real Time Streaming Protocol, RTSP) — мережевий протокол розроблений IETF в 1998 році і описаний в RFC 2326, є прикладним протоколом, призначеним для використання в системах, що працюють з мультимедіа даними, і що дозволяє клієнтові віддалено управляти потоком даних з сервера, надаючи можливість виконання команд, таких як «Старт», «Стоп», а також доступу за часом до файлів, розташованих на сервері.
| Модель TCP/IP (RFC 1122) |
|---|
| Прикладний рівень |
| Транспортний рівень |
| Мережевий рівень |
| Канальний рівень |
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 e=mjh@isi.edu (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
Запит 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 на комп'ютері.