Ця стаття містить фрагменти іноземною мовою. |
Пото́ковий протоко́л реа́льного ча́су (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 ().
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>
Реалізації протоколу
Сервери
- : open source версія QuickTime Streaming Server яка підтримується Apple
- : має клієнт RTSP і може передавати відео в інші протоколи.
- : потоковий сервер з акцентом на дотриманні стандарту RFC.
- FFmpeg: включає ffserver в GPL або LGPL потокові сервери RTSP.
- GStreamer:основний RTSP сервер і клієнт.
- : потоковий сервер від RealNetworks. Поставляється в вигляді відкритого коду
- : комерційний потоковий сервер від RealNetworks для RTSP, RTMP, МО, Silverlight і HTTP потокових мультимедіа клієнтів.
- : Реалізована на C++ бібліотека з відкритим кодом, включає сервер і клієнт які використовуються у добре відомих додатках VLC і mplayer.
- : Повна назва: PacketVideo Streaming Server, це потоковий сервер, продукт Alcatel-Lucent.
- : потоковий сервер Apple, який поставляється разом з Mac OS X Server.
- : Інтегрований RTSP сервер для відео на вимогу, розроблений Anevia
- : медіа-плеєр і потоковий сервер з відкритим вихідним кодом.
- : Сервер потокового відео і вбудований JAVA клієнт від Мауа X-Stream
- : потоковий сервер Microsoft, раніше включався в Windows Server . Він використовує модифікований RTSP і розширення Windows Media
- : Мультиформатний потоковий сервер для RTSP / RTP, RTMP, MPEG-TS, ICY, HTTP (HTTP Live Streaming, HTTP Dynamic Streaming, SmoothStreaming)
- : Мобільний потоковий сервер від Vidiator Technology (US) Inc.
- YouTube : Доступна опція потокового відтворення при перегляді сайту через мобільну версію HTTPS на комп'ютері.
Клієнти
Посилання
Це незавершена стаття про інформаційні технології. Ви можете проєкту, виправивши або дописавши її. |
Це незавершена стаття про Інтернет. Ви можете проєкту, виправивши або дописавши її. |
Ця стаття потребує додаткових для поліпшення її . (квітень 2016) |
Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри, мобільний, телефон, android, ios, apple, мобільний телефон, samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Інтернет
Cya stattya mistit neperekladeni fragmenti inozemnoyu movoyu Vi mozhete dopomogti proyektu pereklavshi yih ukrayinskoyu Poto kovij protoko l rea lnogo cha su Real Time Streaming Protocol RTSP merezhevij protokol rozroblenij IETF v 1998 roci i opisanij v RFC 2326 ye prikladnim protokolom priznachenim dlya vikoristannya v sistemah sho pracyuyut z multimedia danimi i sho dozvolyaye kliyentovi viddaleno upravlyati potokom danih z servera nadayuchi mozhlivist vikonannya komand takih yak Start Stop a takozh dostupu za chasom do fajliv roztashovanih na serveri RTSP ne vikonuye stisku a takozh ne viznachaye metod inkapsulyaciyi multimedijnih danih i transportni protokoli Peredacha potokovih danih sama po sobi ne ye chastinoyu protokolu RTSP Bilshist serveriv RTSP vikoristovuyut dlya cogo standartnij transportnij protokol realnogo chasu sho zdijsnyuye peredachu audio i videodanih Protokol priznachenij dlya vikoristannya v rozvazhalnih i komunikacijnih sistemah dlya upravlinnya potokovim multimedia serverom Protokol vikoristovuyetsya dlya vstanovlennya ta upravlinnya seansami multimedia mizh kincevimi tochkami Kliyenti media serveriv vikoristovuyut VCR podibni komandi taki yak PLAY ta PAUSE shob polegshiti upravlinnya v realnomu chasi progravannyam media fajliv z servera Peredacha samih potokovih danih ne ye zavdannyam protokolu RTSP Bilshist serveriv RTSP vikoristovuyut Real Time Transport Protocol RTP u poyednanni z Real time Control Protocol RTCP dlya dostavki media potoku prote deyaki virobniki realizuyut vlasni transportni protokoli Serverne programne zabezpechennya RTSP vid RealNetworks napriklad vikoristovuye firmovij protokol RealNetworks Real Data Transport RTSP rozroblyavsya kompaniyami RealNetworks Netscape i Kolumbijskim universitetom z pershogo proektu predstavlenogo IETF v 1996 roci Vin buv standartizovanij Multiparty Multimedia Session Control Working Group MMUSIC WG yaka ye chastinoyu Internet Engineering Task Force IETF i opublikovanij v RFC 2326 u 1998 roci RTSP 2 0 znahoditsya v stadiyi rozrobki yak zamina RTSP 1 0 RTSP 2 0 bazuyetsya na RTSP 1 0 ale ne maye zvorotnoyi sumisnosti z nim v svoyij osnovnij versiyi RTSP z vikoristannyam RTP i RTCP dozvolyaye zdijsnennya adaptaciyi shvidkosti peredavannya Pri vsij svoyij podibnosti do HTTP RTSP viznachaye korisni keruyuchi poslidovnosti v upravlinni vidtvorennyam multimedia Vikoristovuyetsya identifikator pri neobhidnosti vidstezhuvati odnochasni sesiyi Yak HTTP RTSP vikoristovuye TCP dlya pidtrimki z yednannya mizh kincevimi tochkami i v toj chas yak bilshist keruyuchih povidomlen RTSP vidpravlyayutsya kliyentom na server deyaki komandi vidpravlyayutsya v inshomu napryamku tobto vid servera do kliyenta Deyaki tipovi zapiti HTTP yak napriklad OPTIONS takozh dostupni Za zamovchuvannyam nomer portu transportnogo rivnya dlya RTSP 554 Spisok komand metodiv OPTIONS zapit pidtrimuvanih metodiv DESCRIBE zapit opisu kontentu napriklad u formati SDP PLAY zapit pochatku movlennya kontenta PAUSE zapit timchasovoyi zupinki movlennya RECORD zapit na zapisuvannya kontenta serverom REDIRECT perenapravlennya na inshij kontent SETUP zapit ustanovki transportnogo mehanizmu dlya media kontenta ANNOUNCE onovlennya danih opisu kontenta GET PARAMETER zapit vkazanih parametriv v servera SET PARAMETER ustanovka parametriv servera TEARDOWN zupinka potoku i zvilnennya resursiv OPTIONS Zapit OPTIONS povertaye tipi zapitiv yaki server mozhe prijmati C gt S OPTIONS rtsp example com media mp4 RTSP 1 0 CSeq 1 Require implicit play Proxy Require gzipped messages S gt C RTSP 1 0 200 OK CSeq 1 Public DESCRIBE SETUP TEARDOWN PLAY PAUSE DESCRIBE Zapit DESCRIBE vklyuchaye RTSP URL RTSP i tip vidpovidi danih yaki mozhut buti obrobleni Port za zamovchuvannyam dlya protokolu RTSP 554 ye odnakovim dlya UDP vikoristovuyetsya v dodatkah yaki potrebuyut minimalnih zatrimok peredavannya de yakist peredavannya ne ye najvazhlivishim kriteriyem i TCP protokoliv Vidpovid cogo zapitu vklyuchaye opis predstavlennya danih yak pravilo v formati Session Description Protocol SDP Sered inshogo opis predstavlennya spiskiv media potokiv kontrolovanih iz URL U tipovomu vipadku ye odin multimedijnij potik dlya audio i video C gt S DESCRIBE rtsp example com media mp4 RTSP 1 0 CSeq 2 S gt 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 Zapit SETUP viznachaye yak yedinij media potik povinen transportuvatisya Ce maye buti zrobleno pered nadsilannyam zapitu PLAY Zapit mistit URL media potoku ta transportnij specifikator Cej specifikator zazvichaj vklyuchaye v sebe lokalnij port dlya prijomu RTP danih audio abo video ta she odin port dlya RTCP danih meta informaciyi Vidpovid servera zazvichaj pidtverdzhuye vibrani parametri i zapovnyuye vidsutni chastini taki yak obrani porti servera Kozhen media potik povinen buti nalashtovanij za dopomogoyu zapitu SETUP pered tim yak vidpravlyayetsya zapit PLAY C gt S SETUP rtsp example com media mp4 streamid 0 RTSP 1 0 CSeq 3 Transport RTP AVP unicast client port 8000 8001 S gt C RTSP 1 0 200 OK CSeq 3 Transport RTP AVP unicast client port 8000 8001 server port 9000 9001 Session 12345678 PLAY Vikonannya zapitu PLAY prizvede do vidtvorennya odnogo abo vsih media potokiv Zapiti PLAY mozhut nakopichuvatisya yaksho vidpraviti dekilka takih zapitiv odin za odnim ce prizvede do vidtvorennya potokiv poslidovno URL adresa mozhe buti agregatnoyu dlya vidtvorennya vsih media potokiv abo adresoyu odnogo potoku dlya vidtvorennya tilki cogo potoku Vidrizok yakij maye vidtvoryuvatisya mozhe buti vkazanij Yaksho vidrizok ne vkazanij to potik vidtvoryuyetsya z samogo pochatku i do kincya abo yaksho potik buv prizupinenij vidtvorennya vidnovlyuyetsya v tochci de vono bulo pripineno C gt S PLAY rtsp example com media mp4 RTSP 1 0 CSeq 4 Range npt 5 20 Session 12345678 S gt 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 Zapit PAUSE timchasovo zupinyaye odin abo vsi media potoki tak sho nadali voni mozhut buti vidnovleni zapitom PLAY Zapit mistit agregatnu URL abo URL media potoku Parametr diapazon za zapitom pauzu vkazuye koli slid prizupiniti Koli parametr vidrizok ne vkazanij to pauza vidbuvayetsya vidrazu i na neviznachenij termin C gt S PAUSE rtsp example com media mp4 RTSP 1 0 CSeq 5 Session 12345678 S gt C RTSP 1 0 200 OK CSeq 5 Session 12345678 RECORD Cej metod iniciyuye zapis media danih vidpovidno do opisu Mitka chasu poznachaye chas pochatku i chas zakinchennya UTC Takozh mozhna vikoristovuvati lishe chas pochatku abo zakinchennya Yaksho seans vzhe pochavsya pochati zapis negajno Server virishuye de slid zberigati zapisani dani na URI z yakogo prijshov zapit chi inshomu URI Yaksho zapis vidbudetsya z vikoristannyam URL vidminnogo vid URL z yakogo nadijshov zapit to vidpovid servera maye buti 201 i mistiti ob yekt yakij opisuye stanu zapitu i posilayetsya na novij resurs u yakij bude vikonuvatisya zberezhennya C gt S RECORD rtsp example com media mp4 RTSP 1 0 CSeq 6 Session 12345678 S gt C RTSP 1 0 200 OK CSeq 6 Session 12345678 ANNOUNCE Metod ANNOUNCE sluzhit dvom cilyam Pri vidpravci vid kliyenta do servera ANNOUNCE povidomlyaye opis predstavlennya abo media ob yekt viznachenij v URL zapitu do servera Pri vidpravci vid servera do kliyenta ANNOUNCE onovlyuye opis seansu v rezhimi realnogo chasu Yaksho novij multimedijnij potik dodanij do predstavlennya napriklad pid chas zhivogo podannya ves opis povinni buti vidpravleni znovu C gt 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 gt C RTSP 1 0 200 OK CSeq 7 TEARDOWN Zapit TEARDOWN vikoristovuyetsya dlya zavershennya seansu Vin zupinyaye vsi media potoki i vidalyaye iz servera vsi dani pov yazani iz sesiyeyu C gt S TEARDOWN rtsp example com media mp4 RTSP 1 0 CSeq 8 Session 12345678 S gt C RTSP 1 0 200 OK CSeq 8 GET PARAMETER Zapit GET PARAMETER vityaguye znachennya parametra predstavlennya abo potoku zadanogo v URI Zmist vidpovidi zalezhit vid realizaciyi GET PARAMETER bez tila mozhe buti vikoristanij dlya testuvannya zhivuchosti kliyenta abo servera ping S gt 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 gt S RTSP 1 0 200 OK CSeq 9 Content Length 46 Content Type text parameters packets received 10 jitter 0 3838 SET PARAMETER Cej metod vstanovlyuye znachennya parametra dlya predstavlennya abo potoku yakij zadayetsya URI C gt S SET PARAMETER rtsp example com media mp4 RTSP 1 0 CSeq 10 Content length 20 Content type text parameters barparam barstuff S gt C RTSP 1 0 451 Invalid Parameter CSeq 10 Content length 10 Content type text parameters barparam REDIRECT Zapit REDIRECT povidomlyaye kliyentu sho vin povinen pidklyuchitisya do inshogo servera Vin mistit obov yazkove pole header Location yake vkazuye sho kliyent povinen posilati zapiti dlya cogo URL Vin mozhe mistiti diapazon znachen yaki vkazuyut na te koli perenapravlennya maye vidbutisya Yaksho kliyent hoche prodovzhuvati vidpravlyati i otrimuvati media z potochnogo URI kliyent povinen vidati zapit TEARDOWN dlya potochnogo seansu i SETUP dlya novoyi sesiyi S gt C REDIRECT rtsp example com media mp4 RTSP 1 0 CSeq 11 Location rtsp bigserver com 8001 Range clock 19960213T143205Z lt br gt Realizaciyi protokoluServeri open source versiya QuickTime Streaming Server yaka pidtrimuyetsya Apple maye kliyent RTSP i mozhe peredavati video v inshi protokoli potokovij server z akcentom na dotrimanni standartu RFC FFmpeg vklyuchaye ffserver v GPL abo LGPL potokovi serveri RTSP GStreamer osnovnij RTSP server i kliyent potokovij server vid RealNetworks Postavlyayetsya v viglyadi vidkritogo kodu komercijnij potokovij server vid RealNetworks dlya RTSP RTMP MO Silverlight i HTTP potokovih multimedia kliyentiv Realizovana na C biblioteka z vidkritim kodom vklyuchaye server i kliyent yaki vikoristovuyutsya u dobre vidomih dodatkah VLC i mplayer Povna nazva PacketVideo Streaming Server ce potokovij server produkt Alcatel Lucent potokovij server Apple yakij postavlyayetsya razom z Mac OS X Server Integrovanij RTSP server dlya video na vimogu rozroblenij Anevia media pleyer i potokovij server z vidkritim vihidnim kodom Server potokovogo video i vbudovanij JAVA kliyent vid Maua X Stream potokovij server Microsoft ranishe vklyuchavsya v Windows Server Vin vikoristovuye modifikovanij RTSP i rozshirennya Windows Media Multiformatnij potokovij server dlya RTSP RTP RTMP MPEG TS ICY HTTP HTTP Live Streaming HTTP Dynamic Streaming SmoothStreaming Mobilnij potokovij server vid Vidiator Technology US Inc YouTube Dostupna opciya potokovogo vidtvorennya pri pereglyadi sajtu cherez mobilnu versiyu HTTPS na komp yuteri Kliyenti cURL FFmpeg GStreamer Media Player Classic MPlayer MythTV cherez QuickTime RealPlayer Skype Spotify VLC media player Winamp Windows Media Player xine JetAudioPosilannyaCe nezavershena stattya pro informacijni tehnologiyi Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi Ce nezavershena stattya pro Internet Vi mozhete dopomogti proyektu vipravivshi abo dopisavshi yiyi Cya stattya potrebuye dodatkovih posilan na dzherela dlya polipshennya yiyi perevirnosti Bud laska dopomozhit udoskonaliti cyu stattyu dodavshi posilannya na nadijni avtoritetni dzherela Zvernitsya na storinku obgovorennya za poyasnennyami ta dopomozhit vipraviti nedoliki Material bez dzherel mozhe buti piddano sumnivu ta vilucheno kviten 2016