, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006w-MMK-D-VoD.fm, ]

Transkript

1 D Video on Demand D.1 1 RTSP Real-Time Streaming Protocol (RTSP) IETF Standard definiert in RFC 2326 (1998) Zielsetzung Signalisierung und Kontrolle von multimedialen Datenströmen Aufbau, Abbruch von Sitzungen z.b. Audio, Video z.b. Life-Sendungen, On-Demand-Streaming, Videorekorderfunktion Unterstützung von Unicast und Multicast Unabhängigkeit vom Transport multimedialer Daten typisch: Nutzung von RTP D.2

2 1 RTSP (2) Aufbau textbasiert ähnlich wie HTTP oder SIP lesbares Protokoll leichtgewichtig basiert typischereise auf TCP/IP auch UDP/IP möglich Zugang Default Port 554 D RTSP-URI URI-Schema beginnt mit rtsp: Aufbau wie HTTP-URI Benutzername, Rechnername, Portnummer, Pfad auf Server z.b. Zweck eindeutige Identifikation Medienströmen auf einem Server z.b. VoD Angebot eines Films auf einem Server D.4

3 1.2 Protokollablauf Unterscheidung von Client und Server Client initiiert Sitzung z.b. Video-on-Demand Server wartet auf Clients-Anfragen Anfrage-Antwort-Schema ähnlich wie HTTP und SIP typisch: Client fragt bei Server an aber auch Server kann Anfrage an Client stellen D Einfacher Sitzungsverlauf Signalisierung eines VoD-Abrufs Client will Video ansehen Client Server SETUP rtsp:// OK PLAY rtsp:// OK RTP-Session TEARDOWN rtsp:// OK D.6

4 1.3 Einfacher Sitzungsverlauf (2) Kontaktadresse RTSP IP-Adresse und Portnummer über RTSP-URI bekannt SETUP-Anfrage Einrichten einer Client-Server-Sitzung erfordert Zustand in Client und Server Angabe von Transportinformationen Beispiel der Anfrage: SETUP rtsp://vs.informatik.uni-ulm.de/videos/matrix RTSP/1.0 CSeq: 302 Transport: RTP/AVP;unicast;client_port= D Einfacher Sitzungsverlauf (3) Beispiel der Antwort RTSP/ OK CSeq: 302 Date: 23 Jan :35:06 GMT Session: Transport: RTP/AVP;unicast; client_port= ;server_port= Antwortzeile Statuscodes wie bei HTTP oder SIP Kopfzeilen CSeq: eindeutige Zuordnung von Antwort an Anfrage zufälliger erster Wert, sonst inkrementiert Session: eindeutige Zuordnung zu einer Sitzung wird bei jeder Folgeanfrage zur Sitzung mitgesendet Transport: Beschreibung der Transportparameter hier: RTP mit AVP-Profil, Unicast-Modus, Ports für RTP und RTCP D.8

5 1.3 Einfacher Sitzungsverlauf (4) PLAY-Anfrage startet Senden des Datenstroms bzw. der Datenströme Beispiel Anfrage: PLAY rtsp://vs.informatik.uni-ulm.de/videos/matrix RTSP/1.0 CSeq: 303 Session: Range: npt=0- Header Range: Angabe der Ausspielzeitpunkte npt = Normal Play Time bezieht sich auf absolute Zeit z.b. im Video mögliche Formate (Beispiele): von Sekunde 150 bis Sekunde 180 im Video 1:23:10.1- ab Zeitpunkt 1h 23min 10,1s im Video D Einfacher Sitzungsverlauf (5) Header (fortges.) smpte = Timecode für Synchronisierung SMPTE = Society of Motion Picture and Television Engineers Adressierung von Frames und Subframes in einem Video mögliche Formate (Beispiele): 01:23:10: :23:10:59:24.1 eine Sekunde von 1h 23m 10s an (zwei Halbbilder/Subbframes pro Frame) Typen: smtpe (30 Frames/s), smtpe-25 (25 Frames/s), smpte-30-drop (29,97 Frames/s) clock = Absolute Zeitangabe ISO 8601 Zeitstempel Beispiel: T Z 08:09 Uhr und 30,25 s am UTC-Zeit (entspricht GMT) wird beispielsweise für Lifesendungen oder Aufnahmen benötigt D.10

6 1.3 Einfacher Sitzungsverlauf (6) Antwort auf PLAY RTSP/ OK CSeq: 303 Date: 23 Jan :35:06 GMT Range: npt=0- TEARDOWN-Transaktion Anfrage TEARDOWN rtsp://vs.informatik.uni-ulm.de/videos/matrix RTSP/1.0 CSeq: 304 Session: Antwort RTSP/ OK CSeq: 304 D Einfacher Sitzungsverlauf (7) Zustandsautomat INIT SETUP READY PLAY PLAYING TEARDOWN PAUSE TEARDOWN angenommene Zustände in einem RTSP-Server in Abhängigkeit der Anfragen D.12

7 1.4 Sitzungsbeschreibung Bisherige Annahme Parameter der Datenströme mehr oder weniger bekannt Transportparameter können bei SETUP konfiguriert werden Sitzungsbeschreibung Vorgabe von außen z.b. SDP-Datei zum Download Inspektion durch Client DESCRIBE Anfrage an Server Beispiel PLAY rtsp://vs.informatik.uni-ulm.de/videos/matrix RTSP/1.0 CSeq: 300 Accept: application/sdp D Sitzungsbeschreibung (2) Beispiel Antwort RTSP/ OK CSeq: 300 Date: 23 Jan :35:06 GMT Content-Type: application/sdp Content-Length: 286 v=0 o=vod IN IP s=matrix der Film c=in IP a=recvonly m=audio 4588 RTP/AVP 0 m=video 4590 RTP/AVP 31 D.14

8 1.5 Anfragen Zuordnung von Antwort zu Anfrage durch CSeq-Zeile Unterbrechung und Wiederaufnahme der TCP-Verbindung unschädlich auch UDP-Nachrichten möglich erfordert Datensicherung durch Wiederholung nach Timeout Durchmischung der Anfragen und Antworten erlaubt z.b. PLAY-Anfragen werden gestapelt und sukzessive abgearbeitet D Ausspieloptionen Weitere Kopfzeilen für PLAY-Anfragen Scale: Einstellung der Abspielgeschwindigkeit z.b. Scale: 2.0 Abspielen eines Videos in doppelter Geschwindigkeit z.b. Scale: 0.5 Abspielen in Zeitlupe (halbe Geschwindigkeit) z.b. Scale: -1 Rückwärts abspielen Speed: Einstellung der Datenmenge Änderungen von Scale führen nicht zur Veränderung der Datenmenge Speed beeinflusst Datenmenge z.b. Scale: 2.0 und Speed: 2.0doppelte Abspielgeschwindigkeit, aber auch doppelte Datenrate, d.h. keine Informationsverluste D.16