Movatterモバイル変換


[0]ホーム

URL:


İçeriğe atla
VikipediÖzgür Ansiklopedi
Ara

Real Time Streaming Protocol

Vikipedi, özgür ansiklopedi
Bu madde,Vikipedi biçem el kitabına uygun değildir. Maddeyi, Vikipedi standartlarına uygun biçimde düzenleyerek Vikipedi'ye katkıda bulunabilirsiniz.Gerekli düzenleme yapılmadan bu şablon kaldırılmamalıdır.(Mayıs 2010)

Real Time Streaming Protocol (RTSP), eğlence ve iletişim sistemlerinde medyasunucularındaki verilerin akışını kontrol etmek için tasarlanan bir ağ denetimprotokolüdür. Bu protokol bitiş noktaları arasındaki medya bağlantılarının kurulması ve kontrol edilmesinde kullanılır. Medya sunucularının sorunu VCR'lerdeki gibi müşterilerin sunucudan alınan medya dosyalarını çalışma, durdurma gibi kısacası gerçek zamanlı kontrolü kolaylaştırmak.

Kendi veri akışının iletimi RTSP protokolünün görevi değildir. Çoğu RTSP sunucuları medya akışının dağıtımı için Gerçek Zamanlı Aktarım Protokolü (RTP) kullanır. Ancak bazı sunucular özel taşıma protokolü uygulamaktadır.Realnetworks'daki RTSP sunucusu örnek olarak, ayrıca RDT veri akışını taşıma özelliğinide bulunmaktadır.

RTSP 1998 yılında Internet Engineering Task Force(Internet Mühendisliği Görev Gücü ) (IETF) deki Multiparty Multimedia Session Control Working Group (MMUSIC WG) tarafından geliştirilmiş veRFC 2326 olarak yayınlandı.

RTSP, HTTP'ye benzer, ancak özellikle akış ortamının kontrolü için tasarlanmıştır. Bir istemcinin bir sunucuya "oynat", "duraklat" ve "kaydet" gibi komutlar vermesine izin verir ve aynı zamanda akış ortamının teslimi için de kullanılabilir. Örneğin, bir kullanıcı akışı yaptığı bir videoyu duraklattığında, RTSP kullanıcının videoyu duraklatma isteğini video akış sunucusuna iletir.

Geçmiş

[değiştir |kaynağı değiştir]

RTSPRealNetworks,Netscape[1] veColumbia Üniversitesi tarafından geliştirilmiştir.[2] İlk taslak, Ekim 1996'daNetscape veProgressive Networkstarafından IETF'ye sunuldu, ardındanColumbia Üniversitesi'ndenHenning Schulzrinne [en], Aralık 1996'da "RTSP՚" ("RTSP prime") sundu.[3][4] İki taslak İnternet Mühendisliği Görev Gücü'nün (IETF ) Çok Taraflı Multimedya Oturum Kontrolü Çalışma Grubu (MMUSIC WG) tarafından standardizasyon için birleştirildi ve çalışma grubu tarafından daha fazla taslak yayınlandı.[5][6]RTSP için Önerilen Standart [en], 1998'de RFC 2326 olarak yayınlandı.[7] RTSP 2.0, 2016'da RTSP 1.0'ın yerine RFC 7826 olarak yayınlandı. RTSP 2.0, RTSP 1.0'ı temel alır, ancak temel sürüm anlaşma mekanizması dışında geriye dönük uyumlu değildir ve bir "Önerilen Standart" olarak kalır.[8]

RTP

[değiştir |kaynağı değiştir]
Ana madde:Gerçek Zamanlı İletim Protokolü

Akış verilerinin iletimi, RTSP'nin bir görevi değildir. Çoğu RTSP sunucusu, medya akışı teslimi için Gerçek Zamanlı Kontrol ProtokolüReal-time Control Protocol [en] (RTCP) ile birlikte Gerçek Zamanlı Aktarım ProtokolünüReal-time Transport Protocol (RTP) kullanır. Ancak, bazı satıcılar özel taşıma protokolleri uygular. Örneğin, RealNetworks'ün RTSP sunucu yazılımı daRealNetworks'ün tescilli Gerçek Veri Aktarımı'nıReal Data Transport [en] (RDT) kullanıyordu.

Protokol direktifleri

[değiştir |kaynağı değiştir]

RTPS protokolününHTTP ile benzerlikleri vardır, ancak RTSP yeni isteklerde eklemektedir. HTTPdurumsuz iken, RTSP bir durumsal protokolüdür. Oturum tanımlayıcısı oturumları takip etmek için kullanılır yani kalıcı TCP bağlantısı gerektiren durumlarda kullanılır. RTSP mesajları istemciden sunucuya gönderilir istisna olarak sunucunun hangi istemciye sonuç döndüreceğidir.

Burada sunulanlar temel RTSP istekleridir. Bazı tipik HTTP istekleri OPTIONS istekleri gibi de mevcuttur. Varsayılantaşıma katmanı port numarası 554'dür.

OPTIONS (Seçenekler)
Seçme isteği sunucunun kabul ettiği istek tiplerini döndürür.
C->S:  OPTIONS rtsp://example.com/media.mp4 RTSP/1.0       CSeq: 1       Require: implicit-play       Proxy-Require: gzipped-messagesS->C:  RTSP/1.0 200 OK       CSeq: 1       Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
DESCRIBE (Açıklama)
Açıklama isteği RTSPURL (rtsp://...) isteklerinive yönetilebilir cevap veri türlerini içerir.UDP veTCP için taşımaları için RTSP protokolü için varsayılan port 554'dür. Bu cevap genellikle Session Description Protocol (SDP) formatında olup sunum açıklamaları içerir. Diğer şeylerin yanı sıra sunum açıklaması toplam URL leri ile kontrollü medya akışlarını listeler. Tipik bir durum da, her bir ses ve video için bir stream akışı bulunmaktadır.
C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 2S->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 (Kurulum)
SETUP isteği tek bir medya akışının nasıl taşınacağını belirtmektedir. Bu istek PLAY isteği gönderilmeden önce yapılmalıdır. İstek medya akışURL'sini ve taşıma belirteci içerir. Bu belirtec genellikleRTCP verilerisini(ses veya video) almak için yerel bir port içerir. Sunucu cevaplarımız genellikle seçilen parametrelerin onaylanması ve yanlış kısımların duzeltilmesidir. Toplu PLAY isteği gönderilmeden önce her medya akışı SETUP kullanılarak yapılandırılmış olması gerekir.
C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0      CSeq: 3      Transport: RTP/AVP;unicast;client_port=8000-8001S->C: RTSP/1.0 200 OK      CSeq: 3      Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001;ssrc=1234ABCD      Session: 12345678C->S: SETUP rtsp://example.com/media.mp4/streamid=1 RTSP/1.0      CSeq: 3      Transport: RTP/AVP;unicast;client_port=8002-8003      Session: 12345678S->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 (Oynat)
Oynatma bir veya tüm medya akışlarının çalınması isteğidir. Birçok çalma isteği gönderilerek PLAY isteği yığın haline getirilebilir. URL toplam bütün URL de olabilir(tüm medya akışlarını oynatmak için) veya tek bir medya akışı için gerekli URL de(sadece tek bir akışı oynatmak için) olabilir. Bununla ilgili bir aralıkta belirtilebilir. Hiç aralık belirtilmezse PLAY akışı baştan sona kadar oynatılır veya akış durdurulursa sonra durdurulduğu bu noktan aynen devam eder.
C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 4      Range: npt=5-20      Session: 12345678S->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 (Duraklat)
PAUSE isteği akışı geçici olarak durdurur veya tüm akış isteğini bir PLAY isteği gelince devam edicek şekilde erteler. İstek toplu veya medya akış URL si içerir. PAUSE zamanı bir dizi parametresi ile belirlenebilir. Dizi parametresi PAUSE yi hızlı bir şekilde değiştirebilir yani PAUSE yi kaldırabilir.
C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 5      Session: 12345678S->C: RTSP/1.0 200 OK      CSeq: 5      Session: 12345678
RECORD (Kaydet)
Kaydetme isteği depolama yapmak için sunucuya akış isteği göndermede kullanılır.
C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 6      Session: 12345678S->C: RTSP/1.0 200 OK      CSeq: 6      Session: 12345678

ANNOUNCE (Duyuru)

[değiştir |kaynağı değiştir]

ANNOUNCE yöntemi iki amaca hizmet eder:

ANNOUNCE, istemciden sunucuya gönderildiğinde, istek URL'si tarafından tanımlanan bir sunumun veya medya nesnesinin açıklamasını bir sunucuya gönderir. ANNOUNCE, sunucudan istemciye gönderildiğinde, oturum açıklamasını gerçek zamanlı olarak günceller. Bir sunuma yeni bir medya akışı eklenirse (örneğin, canlı bir sunum sırasında), bileşenlerin silinebilmesi için yalnızca ek bileşenler yerine tüm sunum açıklamasının yeniden gönderilmesi gerekir.
TEARDOWN
TEARDOWN isteği oturumu sonlandırmak için kullanılır. Bütün medya akışlarını durdurur ve sunucudaki bütün oturumla ilgili verileri kurtarır.
C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 8      Session: 12345678S->C: RTSP/1.0 200 OK      CSeq: 8

GET_PARAMETER

[değiştir |kaynağı değiştir]

GET_PARAMETER isteği, URI'de belirtilen bir sunumun veya akışın bir parametresinin değerini alır. Cevap ve cevabın içeriği uygulamaya bırakılmıştır. Hiçbir varlık gövdesi olmayan GET_PARAMETER, istemci veya sunucu canlılığını ("ping") test etmek için kullanılabilir.

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      jitterC->S: RTSP/1.0 200 OK      CSeq: 9      Content-Length: 46      Content-Type: text/parameters      packets_received: 10      jitter: 0.3838

SET_PARAMETER

[değiştir |kaynağı değiştir]

Bu yöntem, URI tarafından belirtilen bir sunum veya akış için bir parametrenin değerini ayarlamayı talep eder.

C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 10      Content-length: 20      Content-type: text/parameters      barparam: barstuffS->C: RTSP/1.0 451 Invalid Parameter      CSeq: 10      Content-length: 10      Content-type: text/parameters      barparam

REDIRECT (Yönlendirme)

[değiştir |kaynağı değiştir]
Yönlendirme isteği, istemciye başka bir sunucu konumuna bağlanması gerektiğini bildirir. İstemcinin bu URL için istekte bulunması gerektiğini belirten zorunlu Konum başlığını içerir. Yönlendirmenin ne zaman etkili olacağını gösteren Range parametresini içerebilir. İstemci, bu URI için medya göndermeye veya almaya devam etmek istiyorsa, belirlenen ana bilgisayarda mevcut oturum için bir TEARDOWN isteği ve yeni oturum için bir KURULUM YAPMAK ZORUNDADIR.
S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 11      Location: rtsp://bigserver.com:8001      Range: clock=19960213T143205Z-

Katıştırılmış (Araya Eklenmiş) İkili Veri

[değiştir |kaynağı değiştir]

Belirli güvenlik duvarı tasarımları ve diğer koşullar, bir sunucuyu RTSP yöntemlerini serpiştirmeye ve veri akışı yapmaya zorlayabilir. İstemci ve sunucu çalışmasını karmaşıklaştırdığından ve ek yük getirdiğinden, bu serpiştirmeden genellikle gerekli olmadıkça kaçınılmalıdır. Aralıklı ikili veriler yalnızca RTSP, TCP üzerinden taşınıyorsa KULLANILMALIDIR. RTP paketleri gibi akış verileri, birASCII dolar işareti (24 onaltılık), ardından bir baytlık bir kanal tanımlayıcısı ve ardından ağ bayt sırasına göre ikili, iki baytlık bir tam sayı olarak kapsüllenmiş ikili verilerin uzunluğu ile kapsüllenir. Akış verileri, CRLF olmadan, ancak üst katman protokol başlıkları dahil olmak üzere hemen ardından gelir. Her $ bloğu tam olarak bir üst katman protokol veri birimi, örneğin bir RTP paketi içerir.

C->S: SETUP rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 3      Transport: RTP/AVP/TCP;interleaved=0-1S->C: RTSP/1.0 200 OK      CSeq: 3      Date: 05 Jun 1997 18:57:18 GMT      Transport: RTP/AVP/TCP;interleaved=0-1      Session: 12345678C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0      CSeq: 4      Session: 12345678S->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=972948234S->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}

Hız Adaptasyonu

[değiştir |kaynağı değiştir]

RTP ve RTCP kullanan RTSP, hız uyarlamasının kullanılmasına izin verir.[9]

Sunucu uygulamaları

[değiştir |kaynağı değiştir]

İstemci uygulamaları

[değiştir |kaynağı değiştir]

Dış bağlantılar

[değiştir |kaynağı değiştir]

Kaynakça

[değiştir |kaynağı değiştir]
  1. ^InfoWorld Media Group, Inc. (2 Mart 1998).InfoWorld. InfoWorld Media Group, Inc. s. 18.ISSN 0199-6649. 
  2. ^Rafael Osso (1999).Handbook of Emerging Communications Technologies: The Next Decade. CRC Press. s. 42.ISBN 978-1-4200-4962-6. 
  3. ^Rao, Anup; Lanphier, Rob."Real Time Streaming Protocol (RTSP)".Ietf Datatracker (İngilizce). Erişim tarihi: 23 Şubat 2021. 
  4. ^"RTSP prime"Henning Schulzrinne,Columbia University(http://www.cs.columbia.edu/~hgs/papers/Schu9612_RTSP.ps 26 Mart 2023 tarihindeWayback Machine sitesindearşivlendi.) December 1996
  5. ^Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (24 Şubat 1997)."Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-01.txt)".Ietf Datatracker (İngilizce). 30 Haziran 2017 tarihinde kaynağındanarşivlendi. Erişim tarihi: 23 Şubat 2021. 
  6. ^Schulzrinne, Henning; Rao, Anup; Lanphier, Rob (15 Ocak 1998)."Real Time Streaming Protocol (RTSP) (draft-ietf-mmusic-rtsp-08.txt)".Ietf Datatracker (İngilizce). 30 Haziran 2017 tarihinde kaynağındanarşivlendi. Erişim tarihi: 23 Şubat 2021. 
  7. ^RFC 2326,Real Time Streaming Protocol (RTSP), IETF, 1998
  8. ^Schulzrinne, Henning; Rao, Anup; Lanphier, Rob; Westerlund, Magnus; Stiemerling, Martin (December 2016). Stiemerling, M (Ed.)."Real-Time Streaming Protocol Version 2.0".tools.ietf.org (İngilizce).doi:10.17487/RFC7826. 7 Temmuz 2017 tarihinde kaynağındanarşivlendi23 Şubat 2021. 
  9. ^Santos, Hugo; Cruz, Rui Santos; Nunes, Mário Serafim (2010), "Rate Adaptation Techniques for WebTV",Rate Adaption Techniques for WebTV, Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering,40, ss. 161-168,doi:10.1007/978-3-642-12630-7_19,ISBN 978-3-642-12629-1 
"https://tr.wikipedia.org/w/index.php?title=Real_Time_Streaming_Protocol&oldid=35856570" sayfasından alınmıştır
Kategoriler:
Gizli kategoriler:

[8]ページ先頭

©2009-2026 Movatter.jp