Hochqualitative Audioübertragung mit geringer Latenz für
Werbung
DAGA '06 - Braunschweig Audioübertragung mit geringer Latenz für interaktive Web-Services Christian Borß Institut für Kommunikationsakustik, Ruhr-Universität Bochum, 44780 Bochum, Email: [email protected] Einleitung Web-Services stellen über das World-Wide-Web Dienste zur Verfügung, die über XML-formatierte Funktionsaufrufe von lokaler Software genutzt werden können. Web-Services, die auf dem Server ein von der Interaktion des Benutzers abhängiges Audiosignal generieren, das auf dem Client wiedergegeben wird, erfordern eine Audioübertragung mit geringer Latenz. Abbildung 1 zeigt einen solchen Web-Service. Konventionelle Audio-Streaming-Lösungen wurden für nicht-interaktive Anwendungen entwickelt und weisen meist eine Latenz von mehreren Sekunden auf. In diesem Artikel wird eine Streaming-Lösung mit geringer Latenz für interaktive Web-Services vorgestellt, die ohne Installation von zusätzlicher Software direkt in der Java-Virtual-Machine eines gewöhnlichen Web-Browsers verwendet werden kann. Data Format HTML SDP MPEG−1 Application Layer HTTP RTSP RTP Transport Layer TCP Network Layer RTCP UDP IP Abbildung 2: Standardisierte Streaming-Protokolle Übertragung der betroffenen Pakete bietet. Somit ist es speziell zur Übertragung von Echtzeit-Daten geeignet, da keine Verzögerung durch das erneute Versenden verlorener Pakete entsteht. Das Real Time Streaming Protocol (RTSP) ist ein Anwendungsprotokoll, das zur Selektion des gewünschten Datenstroms und zur Initialisierung der Verbindung verwendet wird. Über RTSP werden Meta-Informationen im Session Description Protocol (SDP) Format an den Empfänger gegeben. Die paketierten Audio-/Videodaten werden durch das Real-Time Transport Protocol (RTP) mit Zeitmarken und Sequenznummern versehen und für gewöhnlich über UDP an den Empfänger gesand. Mit dem RTP Control Protocol (RTCP) gibt der Empfänger Rückmeldung über Paketverlustrate und Jitter. Streaming− server RTCP RTP/ UDP RTCP Broadcaster RTP/UDP RTSP A/V Data Client QoS Feedback Setup / Control Abbildung 1: Interaktive auditive virtuelle Umgebung, die dem Anwender über das Internet zur Verfügung gestellt wird Abbildung 3: Live-Streaming unter Verwendung von RTSP/RTP/RTCP Live-Streaming Ein aus Sender (Broadcaster), Streaming-Server und Empfänger (Client) bestehendes Live-Streaming System, das diese Protokolle verwendet, ist in Abbildung 3 dargestellt. Die Aufteilung in Streaming-Server und Broadcaster, der die Audio-/Videodaten lediglich weiterleitet, dient dabei der Lastverteilung und ist speziell bei einer großen Anzahl von Clients vorteilhaft. Für die Übertragung von Echtzeit-Audio-/Videodaten1 existieren bereits Lösungen, die für Broadcast Systeme konzipiert wurden. Im Folgendem wird ein Überblick über die gebräuchlichsten dafür verwendeten und auf offenen Standards [1]-[6] basierenden Protokolle gegeben. Abbildung 2 zeigt eine hierarchische Übersicht dieser Protokolle. Peer-to-Peer Lösung Das User Datagram Protocol (UDP) ist ein Verbindungsloses Transportprotokoll, das im Gegensatz zum Transmission Control Protocol (TCP) keinen Mechanismus zum Schutz gegen Paketverlust durch erneute Die Standard Edition der Java 2 Platform, die Sun Microsystems als Plugin für Web-Browser anbietet, enthält keine Unterstützung für die zuvor beschriebenen StreamingProtokolle. Es existieren zwar Bibliotheken, wie das Java Media Framework (JMF) von Sun Microsystems, die die- 1 Der Begriff “Echtzeit” weist hierbei lediglich daruf hin, daß es sich nicht um die Übertragung gespeicherter Daten handelt. 249 DAGA '06 - Braunschweig 1 se Unterstützung bieten, doch müßen sie vom Endanwender zuvor installiert werden. Abhängig von der Zielgruppe, der ein Internet-Dienst zur Verfügung gestellt werden soll, kann das allerdings bereits eine unzumutbare Hürde darstellen. Da RTSP und RTCP zudem noch für individuelle Datenströme mit einem gewissen Overhead versehen sind - es existiert nur ein einziger Audio-Datenstrom, die Ausgabe des Web-Services - ist die Verwendung einer direkten Verbindung zwischen Sender und Empfänger unter Verwendung eines vereinfachten Protokolls zweckmäßig. Ein solches Protokoll wurde in Java implementiert und die Eigenschaften des Gesamtsystems untersucht. P(δi < TB) 0.8 0 0 50 Web-Browser nutzbar ist, wurde gemäß Abbildung 6 bestimmt. Mit 200 . . . 350 ms erfüllt sie die Anforderungen, die an die Latenz einer Audioübertragung für interaktive Web-Services gestellt wird. (1) . Die Paketverzögerung ti setzt sich dabei aus der minimalen Netzwerk-Latenz T und einem variablen Anteil δi zusammen, ti = T + δ i . (2) Abbildung 6: Meßaufbau zur Bestimmung der Latenz des implementierten Systems: Ein periodisches Testsignal wird sowohl über das Netzwerk als auch über den Parallel-Port versand. Die Wiedergabelatenz wird mit Hilfe eines dritten PCs bestimmt. Die Pufferzeit TB , die der Empfänger zum Ausgleich des Jitters wählt, sollte somit an die mittlere variable Verzögerung δ angepaßt werden, Literatur (3) TB = f (δ) . [1] “RTP Payload Format for MPEG1/MPEG2 Video”, RFC 2250, Jan. 1998, URL: http://www. rfc-editor.org/rfc/rfc2250.txt Abbildung 4 zeigt den qualitativen Verlauf der Wahrscheinlichkeitsdichtefunktion für die Paketverzögerung und Abbildung 5 die Verteilungsfunktion der variablen Verzögerung δi für DSL-Verbindungen in Deutschland, die aus 27 Meßreihen ermittelt wurde. PSfrag replacements P (t) T T + δ̄ 10 20 30 40 Pufferzeit TB in Millisekunden Abbildung 5: Verteilungsfunktion der variablen Verzögerung δi für DSL-Verbindungen in Deutschland (ermittelt aus 27 Meßreihen) Um die Anforderungen, die das Übertragungsverhalten aktueller Internet-Anbindungen an die Wiedergabe des Audio-Datenstroms stellt, zu bestimmen, wurde die Verzögerung der Pakete bei der Übertragung untersucht. Unter der Annahme, daß die Pakete die gleiche Verzögerung ti auf dem Hinweg erfahren wie auf dem Rückweg, ergibt sich die Paketverzögerung ti wie folgt aus der gemessenen Roundtrip-Zeit τi , τi 2 0.4 0.2 Paketverzögerung ti ≈ 0.6 T + TB [2] “Real Time Streaming Protocol (RTSP)”, RFC 2326, Apr. 1998, URL: http://www.rfc-editor.org/rfc/ rfc2326.txt [3] “SDP: Session Description Protocol”, RFC 2327, Apr. 1998, URL: http://www.rfc-editor.org/rfc/ rfc2327.txt [4] “A More Loss-Tolerant RTP Payload Format for MP3 Audio”, RFC 3119, June 2001, URL: http://www. rfc-editor.org/rfc/rfc3119.txt t Abbildung 4: Qualitativer Verlauf der Wahrscheinlichkeitsfunktion für die Paketverzögerung [5] “RTP: A Transport Protocol for Real-Time Applications”, RFC 3550, July 2003, URL: http://www. rfc-editor.org/rfc/rfc3550.txt Fazit [6] “RTP Profile for Audio and Video Conferences with Minimal Control”, RFC 3551, July 2003, URL: http: //www.rfc-editor.org/rfc/rfc3551.txt 25 der 27 Meßreihen wiesen eine maximale variable Paketverzögerung max(δi ) von unter 21 ms auf. Somit läßt sich der Jitter-Puffer des Empfängers so weit reduzieren, daß die Latenz des Gesamtsystems in einer Größenordnung liegt, die einen interaktiven Dienst realisierbar macht. Die Latenz des implementierten Systems, das ohne eine Installation zusätzlicher Software direkt im 250
