B 206/2012 IRT Adaptive-Streaming-Tests 2011

Transkript

1 B 206/2012 IRT Adaptive-Streaming-Tests 2011 Test adaptiver Streaming-Verfahren von Apple, Microsoft, Adobe und anderen zur On Demand-Distribution für PCs über das offene Internet auf Basis von HTTP bei variablem Übertragungskanal in den Formaten Web XS bis Web XXL für mobile und stationäre Nutzung. Martin Schmalohr, Plattformen für Rundfunkdienste (PD) Andreas Bosl, Informations- und Datendienste (ID) Aylin Vogl, Netzwerktechnologien (NT)

2 Bericht Nr. B 206/2012 IRT Adaptive-Streaming-Tests 2011 Test adaptiver Streaming-Verfahren von Apple, Microsoft, Adobe und anderen zur On Demand- Distribution für PCs über das offene Internet auf Basis von HTTP bei variablem Übertragungskanal in den Formaten Web XS bis Web XXL für mobile und stationäre Nutzung. Martin Schmalohr, Plattformen für Rundfunkdienste (PD) Andreas Bosl, Informations- und Datendienste (ID) Aylin Vogl, Netzwerktechnologien (NT) München, Januar 2012 Urheberrechtsvermerk Dieses Dokument und alle Inhalte sind urheberrechtlich geschützt. Alle Rechte vorbehalten. Vervielfältigung, Übersetzung, Verteilung, Mikroverfilmung, Übertragung, Darstellen, Veröffentlichung sowie Einspeicherung in und/oder Verarbeitung auf elektronischen Systemen darf nur mit vorheriger schriftlicher Erlaubnis des Instituts für Rundfunktechnik erfolgen. Urheberrecht, Warenzeichen oder andere Hinweise dürfen weder verändert noch entfernt werden Institut für Rundfunktechnik GmbH. Alle Rechte vorbehalten.

3 Inhaltsverzeichnis 1 Vorwort Verfahren Standardisierung Adaptive Streaming Tests Versuchsaufbau Videomaterial Kodierprofile Anpassungen Der ARD AV Standard Umschaltprofile Kanalprofile Konfiguration der Testsysteme Adobe HTTP Dynamic Streaming Apple HTTP Live Streaming Microsoft Smooth Streaming CodeShop Unified Streaming Platform (USP) Netview Technology itv solutions Messungen Umschaltprofile Adobe HTTP Dynamic Streaming Apple HTTP Live Streaming Microsoft Smooth Streaming Wartezeiten, konstantes Kanalprofil Wiedergabeverzögerung, Time To Play (TTP) Hochschaltverzögerung, Time To Ma (TTM) Navigationsgeschwindigkeit, Time To Seek (TTS) Schaltverhalten, variables Netzwerkprofil Adobe HTTP Dynamic Streaming Apple HTTP Live Streaming Microsoft Smooth Streaming CodeShop Netview itv solutions Zusammenfassung Messungen Verhalten Anwendung Ausblick

4 Inhaltsverzeichnis 9 Anhang Systeme Clients Server Encoder Hardware Messergebnisse Schaltverhalten Scriptcode (eemplarisch) Adobe HTTP Dynamic Streaming Apple HTTP Live Streaming Microsoft Epression Encoder CodeShop USP Netview itv solutions

5 Verzeichnis der Abbildungen Abbildung 1: Chunks und Qualitätsstufen mit Umschaltung bei HTTP Adaptive Streaming... 6 Abbildung 2: Aufbau des Host Systems der Server für fünf ADS Systeme... 9 Abbildung 3: Versuchsaufbau des ADS Tests Abbildung 4: Größenvergleich verwendeter HAS Profile Abbildung 5: Testmessung des WAN Emulators (Mobile, 128 kbit/s 7200 kbit/s) Abbildung 6: Testmessung des WAN Emulators (Home, 384 kbit/s kbit/s) Abbildung 7: Strobe Media Playback beim Abspielen einer Testsequenz Abbildung 8: M3U8 Struktur (Quelle: 20 Abbildung 9: Fehlerhaftes HAS Profil einer H.264 Wiedergabe in Microsoft Smooth Streaming Abbildung 10: Microsoft Silverlight Videoplayer mit Testsequenz im HAS Test Abbildung 11: Durchschnittliche Wartezeiten (TTP) in Sekunden Abbildung 12: Durchschnittliche Hochschaltverzögerung (TTM) in Sekunden Abbildung 13: Übersicht durchschnittlich gemessener Seek and Play (SAP) Werte der HTTP Adaptive Streaming Systeme Abbildung 14: Adobe HTTP Dynamic Streaming Profil Mobile (Messung 1) Abbildung 15: Adobe HTTP Dynamic Streaming Profil Home (Messung 1) Abbildung 16: Apple HTTP Live Streaming Profil Mobile (Messung 1) Abbildung 17: Microsoft Smooth Streaming Profil Mobile (Messung 1) Abbildung 18: CodeShop Profile Mobile Abbildung 19: Netview Profil Mobile (Messung 1) Abbildung 20: itv solutions Profil Home (Messung 1) Abbildung 21: itv solutions Profil Mobile (Messung 1) Abbildung 22: Adobe HTTP Dynamic Streaming Profil Home (Messung 1) Abbildung 23: Adobe HTTP Dynamic Streaming Profil Mobile (Messung 1) Abbildung 24: Apple HTTP Live Streaming Profil Home (Messung 1) Abbildung 25: Apple HTTP Live Streaming Profil Mobile (Messung 1) Abbildung 26: Microsoft Smooth Streaming Profil Home (Messung 1) Abbildung 27: Microsoft Smooth Streaming Profil Mobile (Messung 1) Abbildung 28: CodeShop USP Flash Player Profil Home Abbildung 29: CodeShop USP MS Smooth Streaming Profil Home Abbildung 30: CodeShop USP Messungen mit dem variablem Netzwerkprofil Mobile Abbildung 31: CodeShop USP Flash Player Profil Mobile Abbildung 32: CodeShop USP Silverlight Profil Mobile Abbildung 33: CodeShop USP Apple Profil Mobile Abbildung 34: Netview Profil Home (Messung 1) Abbildung 35: Netview Profil Mobile (Messung 1)

6 Versuchsaufbau 1 Vorwort Die Rundfunkanstalten der ARD produzieren zahlreiche Hörfunk und Fernsehangebote. Hinzu kommen die TV Angebote des ZDF sowie die Hörfunkprogramme von DeutschlandRadio. Zahlreiche dieser Inhalte werden den Teilnehmern über die Webseiten und die Mediatheken der Rundfunkanstalten zur Nachnutzung zur Verfügung gestellt. Die Inhalte sind sowohl über Personal Computer als auch mit Hilfe der neuen hybriden Rundfunkempfangsgeräte mit Internetanschluss (HbbTV) abrufbar. Audio und Video Streams werden dafür als Webdienst für verbreitete PC Plattformen wie Windows, Mac OS und Linu in Formaten wie MPEG4, H.264/AVC, AAC, MP3, Flash oder Windows Media zur Verfügung gestellt. Die Übertragung erfolgt über Download oder per Streaming mittels verschiedener Protokolle (RTP, MMS, RTMP/E, HTTP). Streaming findet im offenen Internet wegen der fehlenden, globalen Multicast Unterstützung und aufgrund von Engpässen im Upload von asymmetrischen DSL Zugängen bei P2P Verbindungen immer noch größtenteils im Unicast Betrieb statt. Bei schwankenden Leitungsqualitäten und Serverüberlastungen ergeben sich dadurch Wartezeiten oder Aussetzer in einer Videoübertragung. Man versucht, diese Engpässe durch Load Balancing und Caching von Content Delivery Networks (CDN) mit erheblichem Aufwand und hohen Kosten zu überbrücken. Um auch bei schwankenden Datenraten zwischen Client und Server eine flüssige Wiedergabe zu ermöglichen, werden neue, adaptive Verfahren eingesetzt, deren Kodierraten sich and wechselnde Kanalgegebenheiten anpassen. Unter Berücksichtigung des AV Standards der ARD wurden am IRT seit Mitte 2010 Tests verschiedener Verfahren für Adaptive Streaming (ADS) auf Basis des HTTP Protokolls (HAS) durchgeführt 1. Alle untersuchten Verfahren nutzen also das HTTP Protokoll für das Streaming der audio visuellen (AV) Inhalte. Die Tests wurde überwiegend im Rahmen des Förderprojektes ADAMS 2 durchgeführt. Ein Konsortium aus Forschungsinstituten und Unternehmen entwickelt im Forschungsprojekt ADAMS eine auf technischen Standards beruhende Lösung, so dass Nutzer ihr bevorzugtes Wiedergabegerät vom Fernseher über Smartphones und Tablets vom Heimberich bis hin zum Auto frei wählen können. Die ADAMS Architektur ermöglicht dabei das angepasste Streaming der Inhalte auf das jeweilige Endgerät und für die jeweilige Übertragungssituation. Die Übertragung zusätzlicher Informationen zur jeweiligen Sitzung ermöglicht eine nahtlose Fortsetzung der Wiedergabe beim Wechsel des Endgeräts (und/oder der Internetverbindung). Für die Tests standen die adptive Streaming Verfahren Smooth Streaming mit Silverlight von Microsoft, HTTP Live Streaming (HLS) mit Quicktime von Apple, Dynamic Streaming von Adobe sowie ein Player von NetView.no und die Unified Streaming Platform (USP) von CodeShop. Zusätzlich wurde eine nicht adaptive Lösung für Video on Demand (VoD) der Firma itv solutions für CE Geräte auf einer Settop Bo getestet. Für die Anwendbarkeit dieser Verfahren in den Mediatheken wurden geeignete Bewertungskriterien entwickelt. In den End To End Tests wurde jeweils eine Teststrecke mit Client und Server im Labornetz des IRT aufgebaut. Die Technologien wurden auch hinsichtlich der Konformität zur laufenden Standardisierung in MPEG, DVB, 3GPP oder dem Open IPTV Forum eingeordnet. 1 Wir führen hier die Abkürzungen ADS für Adaptive Streaming und HAS für HTTP ADS ein. 2 ADAMS ist ein von der bayerischen Landesregierung geförtes Forschung und Entwicklungsvorhaben. Das Proekt wird von der Fraunhofer ESK geleitet. Das Konsortioum unfasst zudem Fraunhofer IIS sowie die Firmen Audi, SpaceNet, Weptun, Geißendörfer & Leschinsky und das Institut für Rundfunktechnik. Unterstützt wird ADAMS von den assoziierten Partnern BMW Forschung & Technik und Loewe Opta. 5

7 Versuchsaufbau 2 Verfahren Bei Adaptiven Streaming (ADS) wird der Transport zur Laufzeit auf die individuellen Bedingungen der Leitung jedes einzelnen Benutzers angepasst. Die Bezeichnung adaptiv steht dabei für eine Anpassung der Audio oder Videoqualität während des gesamten Streaming und Abspielvorgangs. Der Einsatz des HTTP Protokolls hat den Vorteil, dass es von allen Internet fähigen Endgeräten nativ unterstützt wird. Dadurch kann im Gegensatz zu RTP auf Verfahren für das NAT Traversal zur Umgehung heimischer Firewalls wie STUN/TURN verzichtet werden. Zudem können HTTP Pakete im offenen Internet zur Optimierung der Netzwerk Performance von Proy oder Caching Servern zwischengespeichert werden. Dabei wird für jeden Benutzer eine passende Qualitätsstufe in Abhängigkeit von Pufferstand, Übertragungsrate, Auslastung des Endgeräts oder dessen Bildschirm Auflösung individuell ausgewählt. Abbildung 1 gibt die im Test eingesetzten Videoclips ( Chunks ) wieder. Abbildung 1: Chunks und Qualitätsstufen mit Umschaltung bei HTTP Adaptive Streaming Dies geschieht nicht nur einmalig vor dem Start der Wiedergabe, sondern fortwährend über den gesamten Abspielvorgang. Dadurch kann dem Benutzer auch bei schwankenden Übertragungsraten die höchstmögliche Qualität des Videos präsentiert werden, ohne dass die Wiedergabe pausiert oder unterbrochen werden muss. Die Anpassung der Wiedergabe findet in vorab festgelegten Qualitätsstufen statt. Zu diesem Zweck wird ein AV Datenstrom bei HAS in einzelne Segmente bzw. Chunks geteilt, welche typischerweise eine Abspieldauer von 1 bis 10 Sekunden aufweisen und in der Prais meist mit den Grenzen einer Group of Pictures (GOP) beginnen bzw. enden. Adaptive Streaming ist somit eine fleiblere Variante des Segmented Streaming, wie es auch für P2P Streaming eingesetzt wird. Sofern mehr als ein Stream je Inhalt mit beschreibenden Metadaten beispielsweise in Form eines Manifests angeboten wird, kann das Segmented Streaming auch adaptiv genutzt werden, wobei prinzipiell nicht nur eine Anpassung an variable Übertragungskanäle, sondern auch an sich verändernde Client Eigenschaften etc. denkbar wäre. Da bei HTTP das TCP Protokoll zugrunde liegt, findet bei HAS eine Fehlerkorrektur per (Retransmission) in der Netzwerkschicht statt. Daher ist jeder übertragene Chunk fehlerlos und wird grundsätzlich komplett dekodiert. Die Qualitätsstufe kann prinzipiell für jeden Chunk gewechselt werden. Aufeinanderfolgende Chunks müssen dann nahtlos aneinander gesetzt und als kontinuierlicher Datenstrom dekodiert werden. Gesteuert wird dies mit Hilfe einer Steuerdatei (Manifest), welche Informationen zu Reihenfolge, Referenz, Abspieldauer, Bitrate und Auflösung enthält. 6

8 Versuchsaufbau 3 Standardisierung HTTP Adaptive Streaming (HAS) wird in folgenden Gremien spezifiziert bzw. standardisiert: Open IPTV Forum: HTTP Adaptive Streaming (OIPF) IETF: HTTP Live Streaming 3 (Vorschlag Apple/Pantos) 3GPP und MPEG: Dynamic Adaptive Streaming over HTTP (3GP DASH) MPEG: Dynamic Adaptive Streaming over HTTP (MPEG DASH) DECE, HbbTV Forum: HbbTV (MPEG DASH) a) Progressive Download und Dynamic Adaptive Streaming über HTTP in 3GPP (3GP DASH) Adaptive Streaming wurde erstmals auf RTP Basis 5 in 3GPP als Teil der Packet Switching Streaming Services (PSS) standardisiert. Demgegenüber wurde Dynamic Adaptive Streaming over HTTP 6 (3GP DASH) wegen unterschiedlichen Server Anforderungen abgegrenzt. Um dem begrenzten Speicherplatz und den niedrigen Übertragungsraten von Mobiltelefonen gerecht zu werden, verwendet 3GP DASH als Containerformat 3GP 7 auf Basis des ISO Base Media File Format (ISO BMFF) 8. Als mögliche Video Codecs sind für 3GP MPEG 4 Part 2 (H.263) oder MPEG 4 Part 10 (H.264) und für Audio die Codecs AMR, AMR WB oder AAC LC und HE AAC definiert. b) HTTP Adaptive Streaming (HAS) im Open IPTV Forum (OIPF) Das Open IPTV Forum hat am in Release 2 eine Spezifikationen für HTTP Adaptive Streaming 9 veröffentlicht. Sie Basiert auf 3GP DASH mit weiteren eingrenzenden Anforderungen. Die unterstützten Container Formate 10 in OIPF sind MPEG 2 TS und MP4. In MPEG 2 TS werden folgende Codecs unterstützt: Video... H.264/MPEG 4 AVC, MPEG 2 Audio... HE AAC 11, MPEG 1 Audio Layer II, (Enhanced) AC312, DTS In MPEG 4 (MP4)werden folgende Codecs unterstützt: Video... H.264/MPEG 4 AVC Audio... HE AAC, MPEG 1 Audio Layer II, (Enhanced) AC3, DTS Für die Rechteverwaltung in MPEG 2 TS wird BBTS 13, bei MP4 wird (P)DCF 14 unterstützt. Die Strukturierung in den Segmenten Initialisation Segment, Media Segment und Self Initialisation Segment erfolgt analog zu 3GP DASH. 3 pantos http live streaming _Praesentation_Merkel.pdf 5 3GPP TS : Transparent end to end Packet switched Streaming Service (PSS); Protocols and codecs, GPP TS : Transparent end to end Packet switched Streaming Service (PSS); Progressive Download and Dynamic Adaptive Streaming over HTTP (3GP DASH), GPP, 3GPP TS : Transparent end to end packet switched streaming service (PSS); 3GPP file format (3GP)., ISO/IEC (ISO/IEC, ISO/IEC : Information technology Coding of audio visual objects Part 12: ISO base media file format, Volume 2a HTTP Adaptive Streaming V2.0 (OIPF, Release 2 Specification: HTTP Adaptive Streaming, Volume 2 Media Formats (OIPF, Release 2 Specification: Volume 2 Media Formats, Die High Effifiency Variante (HE) des Advanced Audio Conding Verfahrens (AAC) schließt die Unterstützung des einfachen, Low Compleity Decodings (LC AAC) ein. Daher wird im Folgenden HE AAC stellvertretend für HE/LC AAC verwendet. 12 Enchanced AC3: Verbesserte bzw. erweiterte Version des AC3 Codecs. 13 BBTS (Broadband Transport Stream) Community, Marlin Broadband Transport Stream Specification, (P)DCF (Packetized DRM Content Format). Community, OMArlin Specification,

9 Versuchsaufbau c) Dynamic Adaptive Streaming over HTTP (DASH) in MPEG Im Mai 2010 wurde in MPEG ein Aufruf für Voschläge ( Call for Proposals ) für Dynamic Adaptive Streaming over HTTP (DASH) veröffentlich. Die Ergebnisse wurden im Januar 2011 als Entwurf veröffentlicht. 15 November 2011 wurde DASH als Draft Standard fertiggestellt, welcher Anfang 2012 als internationaler Standard verabschiedet wird. MPEG DASH basiert auf 3GPP mit Erweiterungen für mobile Endgeräte und TV. Zusätzlich besteht die Möglichkeit, verschiedene Qualitätsstufen, sog. Representations, in Gruppen aufzuteilen. Als Containerformate werden MPEG 2 TS und ISO BMFF unterstützt. In beiden können folgende Codecs eingesetzt werden: Video... H.264/MPEG 4 AVC, MPEG 2 Audio... HE AAC, MPEG 1 Audio Layer II, (Enhanced) AC3, DTS Zu den standardisierten Verfahren für HTTP Adaptive Streaming in 3GPP und OIPF bzw. MPEG DASH und HbbTV 1.5 ist derzeit noch kein System am Markt verfügbar. Verschiedene Herstellern hybrider Settop Boen und Fernsehgerätehaben bereits Implementierungen nach entsprechend der MPEG DASH Spezifikation angekündigt. Auch für Codeshop USP und Videolan Client (VLC) bestehen derartige Ankündigungen. Zwar basieren alle bestehenden HAS Lösungen (ob standardisiert oder proprietär) überwiegend auf denselben Containerformaten und unterstützen ähnliche AV Kodierverfahren; die Notation und Struktur der Manifest Dateien unterscheidet sich jedoch teils erheblich, obwohl der Inhalt größtenteils derselbe ist. Apple setzt dabei auf einfache Webserver, einzelne Chunk Dateien und einem Manifest mit URLs zu allen Chunks, wobei wegen des MPEG 2 TS Containers ein Overhead entsteht, der bei Nutzung des ISO/MP4 Containers oder nativem Streaming über UDP/RTP üblicherweise geringer ausfällt 16. Mit geringem Aufwand sollte es aber möglich sein, auf dem Server zusätzlich eine Manifest Datei zu hinterlegen, welche auch zu 3GPP und OIPF konform ist. Die Chunks müssten dann jedoch im Hinblick auf die besondere Segmentierung für 3GPP und OIPF wohl neu erzeugt werden. 15 MPEG DASH ISO/IEC : Information technology Dynamic adaptive streaming over HTTP (DASH) Part 1: Media presentation description and segment formats, August Envivio: IP Streaming of MPEG 4; Native RTP vs MPEG 2 Transport Stream: For TS, the overhead consists of not just the transport packet headers, but also the PES headers and the bytes used to pad TS packets that carry the end of the PES packet, ( ) depend on the size of the PES packet ; Ale MacAulay, Boris Felts, Yuval Fisher, October 2005; papers/rtpvsts v4.pdf 8

10 Versuchsaufbau 4 Adaptive Streaming Tests 2011 Zum Zeitpunkt der Tests ab Mitte 2010 standen noch keine standardkonformen Implementierungen nach MPEG DASH, OIPF oder 3GPP zur Verfügung. Daher wurden die proprietären Lösungen folgender Anbieter am IRT getestet: Apple HTTP Live Streaming (Safari, Quicktime X, ios) Microsoft Smooth Streaming (Silverlight, PIFF) Adobe HTTP Dynamic Streaming (Flash) itv solutions 17 (Cloud7Movies) Codeshop Unified Streaming Server (USP für Apple, Microsoft, Adobe) Netview Player (NetView.no) Ziel der Untersuchungen war die Analyse und Evaluierung von adaptiven Systemen für Streaming und Download zur Distribution von Multimedia Live und On Demand Inhalten über das offene Internet hinsichtlich der Performance, Interoperabilität, Skalierbarkeit und Robustheit. Dazu wurde für jedes System im geschlossenen Labornetz eine eigene Übertragungsstrecke (End To End) mit Server und Client nach den Vorgaben des Herstellers und den Anforderungen aus dem AV Standard der ARD eigerichtet. Nach der Verifizierung der grundsätzlichen Funktionsfähigkeit jeder Strecke wurde für jeden der Tests ein entsprechendes Bandbreiten Profil zwischen Server und Client durchgespielt, um das typische Verhalten des Systems zu analysieren. 4.1 Versuchsaufbau Abbildung 2 zeigt den Aufbau der Testumgebung. Für die verschiedenen dedizierten Server Installationen wurde eine Virtualisierungslösung gewählt, die für die jeweiligen Gast Systeme der Server eine eigene Umgebung zur Verfügung stellt. Hierdurch ist es möglich, auf einer einzigen Hardware Plattform mehrere HAS Server mit ihren unterschiedlichen Betriebssysteme gleichzeitig laufen zu lassen. Zusätzlich wurde noch eine virtuelle Netzwerkkarte installiert, über die die einzelnen HAS Server mit einem ebenfalls virtuellen WAN Emulator verbunden werden können. Abbildung 2: Aufbau des Host Systems der Server für fünf ADS Systeme 18 Als Host Betriebssystem kam die Free Edition des XenServer von Citri zum Einsatz. Der XenServer basiert auf einem UNIX Betriebssystem mit der Open Source Virtualiserungs Software Xen. Die einzelnen Clients und der XenServer wurden mit normalen CAT 5 Leitungen über einen NetGear WNR854T Wireless Router per Gigabit Ethernet untereinander verbunden. Der Router fungiert dabei zusätzlich als WLAN 17 Optimierte, nicht adaptive Progressive Download Lösung für Video On Demand Anwendungen (VoD) 18 Die Streaming Lösung der Firma itv solutions wurde einem gesonderten Test unterzogen (vgl. Abschnitt 0) 9

11 Versuchsaufbau Zugangspunkt, DHCP 19 Server sowie Gateway für den Zugriff auf das Internet. Letzteres erfolgte über den WAN Port des Heimnetz Routers durch das Intranet des IRT hindurch auf einem dedizierten Subnetz. Abbildung 3: Versuchsaufbau des ADS Tests Die Übersicht in Tabelle 1 zeigt alle im Test installierten virtuellen Maschinen und deren schematischen Aufbau. Jedes zu testende HAS System wurde innerhalb einer eigenen virtuellen Maschine betrieben, um störende Auswirkungen auf die anderen Systeme auszuschließen. Auf Client Seite wurden für die Tests PC Konfigurationen unterschiedlicher Leistungsklassen und Betriebssysteme sowie zwei mobile Endgeräte ausgewählt, die für Endverbraucher gebräuchlich sind. Die Spanne reicht von einem Dell Inspiron 8100 Notebook mit Prozessor Intel Pentium III (1,13GHz) und Windows 2000 bis zum Intel Core i5 (3,33GHz) mit Windows Das Mittelfeld deckt ein handelsüblicher Büro Rechner mit Intel Core 2 Duo (2,66GHz) und Windows 7 64 ab. Eine Übersicht der verwendeten Hardware findet man in den Tabellen Für mobile Szenarien diente ein Apple ipad 3G (ios 4.2.1, 16GB) und ein Motorola Milestone (Android 2.2). Von Motorola stand zu den Tests kein Update des Betriebssystems auf Android 2.2 zur Verfügung. Dies ist jedoch für die Nutzung des Flash Plug In notwendig. Um dennoch Adobe Dynamic Streaming auf einem Smartphone testen zu können, wurde eine nicht offizielle Variante von Android 2.2 installiert und gleichzeitig die Rechenleistung ohne Stabilitätsverlust von 550 MHz auf 1 GHz erhöht, um eine optimale Performance sicherzustellen. Bei allen Geräten wurden vorab die benötigten, jeweils aktuellen Browser Plug Ins von Microsoft Silverlight und Adobe Flash installiert. Adobe HTTP Dynamic Streaming Apple HTTP Live Streaming Microsoft Smooth Streaming Codeshop USP Netview Player WAN Emulator Windows Windows Ubuntu Ubuntu OS Server 2008 R2 Server 2008 R Fedora Debian CPU 4 2,80Ghz 4 2,80Ghz 4 2,80Ghz 4 2,80Ghz 4 2,80Ghz 1 2,80Ghz RAM 4GB 4GB 4GB 4GB 4GB 512MB HDD 300GB 300GB 300GB 300GB 300GB 10GB Tabelle 1: Eigenschaften installierter virtuellen Maschinen der Gast Serversysteme Für den praisnahen Test des Schaltverhaltens der ADS Clientimplementierungen wurde die jeweils verfügbare Übertragungsrate des Netzwerks zwischen Client und Server zeitgesteuert eingeschränkt. Eine Stichprobe verfügbarer, professioneller WAN Emulatoren konnte zwar ausgewählte Zugangstechnologien wie ISDN, POTS oder UMTS bzgl. verschiedener Netzwerkparameter simulieren. Für diesen Test sollten jedoch zwischen Schwellen verschiedener Datenraten, welche typische DSL Zugänge verschiedener Güteklassen (1000, 2000, 6000, 16000) abbilden, anhand einer Zeitsteuerung hin und her geschaltet werden, um für jedes ADS System identische Kanalbedingungen über die Zeit zu erreichen. Dazu wurde das 19 DHCP (Dynamic Host Configuration Protocol): Ermöglicht die Zuweisung von Netzwerkkonfigurationen, etwa der IP Adresse, an einen Client innerhalb von Netzwerken. 10

12 Videomaterial Open Source Tool Dummynet ausgewählt, welches auf einer dedizierten virtuellen Maschine mit zwei virtuellen Netzwerkkarten lief. Dummynet ist Teil des in FreeBSD 20 und Mac OS X eingesetzten Paketfilters ipfw. Für die Benutzung von Dummynet wurde eine Minimalinstallation von Debian 5.0 als Betriebssystem vorgenommen. Nach der Installation von Dummynet und allen Abhängigkeiten 21, kann Dummynet während der Laufzeit über die Kommandozeile mit dem Befehl ipfw gesteuert werden. Dafür muss zuerst eine eingehende und ausgehende Pipe 22 angelegt werden. Danach können für diese Pipe Parameter wie Datenrate, Delay und Queue Size individuell eingestellt werden. Nachfolgendes Beispiel zeigt die Simulation einer 1 Mbit/s ADSL Leitung mit einer Hin und Rücklaufverzögerung von jeweils 20 Millisekunden. ipfw add pipe 1 out ipfw add pipe 2 in ipfw pipe 1 config bw 128Kbit/s queue 10 delay 20ms ipfw pipe 2 config bw 1024Kbit/s queue 30 delay 20ms Zusätzlich wurden die Netzwerkkarte mit Verbindung zum physikalischen Netzwerk und die virtuelle Netzwerkkarte, welche nur am virtuellen Netzwerk hängt, überbrückt. Zur einfacheren Durchführung der späteren Tests wurden zwei Shell 23 Skripte erstellt, welche eine beigesteuerte Kanalprofil Simulation realisieren. Dazu zählt ein Skript für Tests mit konstanter Bitrate und ein weiteres für Tests mit dem variablen Kanalprofil. Letzteres benötigt bei Aufruf die maimale und minimale Datenrate als Übergabe Wert. Aus den ma/min Werten berechnet das Skript, die für den Test benötigten Zwischenstufen. Zusätzlich werden Statusmeldungen und ein Countdown zur Nachverfolgung in der Kommandozeile in einem Log File ausgegeben. Um die aktuell genutzte Datenrate jedes HAS Systems messen zu können, wurde zusätzlich das Tool ifstat installiert, welches es ermöglicht, die aktuelle Übertragungsrate einfach und übersichtlich in einer Logdatei mitzuschreiben. 4.2 Videomaterial Für alle HAS Tests wurde jeweils eine Testsequenz pro Qualitätsstufe ausgewählt. Die Testsequenzen wurden mit den empfohlenen Tools der HAS Hersteller eigens für jedes HAS System enkodiert. Alternativ wurden auch freie Tools wie ffmpeg, 264, mp4bo u.a. eingesetzt, sofern dafür geeignete Presets verfügbar waren. Für die Erstellung der Testsequenzen wurden die nachfolgend dargestellten Videoclips zusammengeschnitten. Jeder Clip war 10 Sekunden lang und lag in der Quell Auflösung von Pieln vor (unkomprimierte AVI Clips im RGB Farbraum mit 25 Vollbildern pro Sekunde). SRC1: Crowd Run SRC2: Ducks Take Off SRC3: Old Town Cross SRC4: Tagesschau SRC5: Arena Show SRC6: Soccer 20 FreeBSD: eine freie Version des Uni Betriebssystems 21 Nach Anleitung linnub, Pipe: bezeichnet bei Dummynet einen Kanal zwischen zwei Punkten, dessen Eigenschaften angepasst werden können. 23 Shell: umgangssprachlich der Kommandozeileninterpreter von Uni oder Linu Systemen. 11

13 Kodierprofile SRC7: Running SRC8: Ice Hockey SRC9: Musical Die kurzen Quell Clips wurden mit Hilfe eines AviSynth Skripts 24 aneinander gereiht und mit VirtualDub 25 als unkomprimierte AVI Datei eportiert. Jede Reihe wird durch einen SMPTE Farbbalken (mit Timecode) von sechs Sekunden Dauer eingeleitet, wobei an den Clip Grenzen jeweils ein weißes Bild und ein schwarzes Bild als Blende eingefügt wurde. Um eine ausreichende Gesamtlänge von über 10 Minuten zu erreichen, wurde die gewählte Sequenz mehrmals wiederholt. Als Audiospur wurde ein Kammerton 26 mit 440 Hz über die gesamte Länge, sowie ein kurzer 1 khz Ton während der Weiß bzw. Schwarz Blende zur Prüfung der Audio/Video Synchronität (A/V Sync) mit einer Spracheinblendung zur seitenrichtigen Identifizierung der beiden Stereokanäle genutzt. Um die Bestimmung des Schaltverhaltens der HAS Systeme im Test nachvollziehen zu können, wurde zusätzlich ein Tet mit dem Label der jeweiligen Qualitätsstufe eingebettet. 4.3 Kodierprofile Abbildung 4: Größenvergleich verwendeter HAS Profile Die Auswahl der verschiedenen Auflösungen und Bitraten beruht auf den Vorgaben des ARD Handbuchs Webtechnik 27. Hierfür wurden am IRT getrennte Evaluierungen durchgeführt, um Parameterprofile mit dem jeweils optimalen Kompromiss zwischen Qualität, Bitrate und Prozessing zu finden. Die Vorgabe der ARD bei der Einführung von HAS für die Mediathek ist, möglich viele bereits vorhandene Kodierprofile zu verwenden, um den Produktionsaufwand und die Zusatzkosten auf einem vertretbaren Niveau zu halten. Daher wurden die Profile des AV Standards der ARD soweit möglich direkt für das Encoding im HAS Test eingesetzt Anpassungen Die für Adaptive Streaming entscheidende Segmentgröße wurde im Encoding für alle ADS Implementierungen auf eine einheitlich Größe von 2 Sekunden pro Chunk bzw. Segment eingestellt. Soweit nicht anders vom Hersteller vorgegeben wurden alle Representations bzw. Streams durchgehend mit konstanter Bitrate und fester, geschlossener Keyframe Distanz bzw. Group Of Pictures (closed GOP) von 1 s 24 AviSynth: freier Frameserver, kann Dateien einlesen, bearbeiten und diese als Datenstrom an andere Programme weiterleiten. 25 VirtualDub: freie Software zum Erstellen und Bearbeiten von Videodateien. 26 Kammerton: Ton, auf den Instrumente, meist in Orchestern, gemeinsam eingestimmt werden. 27 IRT, Handbuch zur Kodierung von Audio und Video in der ARD für das Web,

14 Kodierprofile kodiert, sofern möglich. Dies resultiert im Falle der Videoquellen mit 25 fps jeweils in 25 Vollbildern und mit 50 fps entsprechend 50 Vollbildern, wobei die maimale lokale Bitrate (vbv marate) für CBR gleich der durchschnittlichen Gesamt Datenrate (average bitrate, abr) entsprechend der in Abschnitt 4.4 angegebenen Bitrate der Tabellenspalten Video [kbps] eingestellt wurde. Weitergehende Parameter und Einstellungen zur Enkodierung und Segmentierung sind im Anhang auszugsweise abgedruckt (vgl. Abschnitt 9.8). Obwohl die Kodierung mit konstanter Bitrate (CBR) eine im Schnitt schlechtere subjektive Qualität mit sich bringt, wurde für die Tests CBR gewählt, um das Schaltverhalten der ADS Implementierungen zunächst unter optimalen Bedingungen zu prüfen. Grundsätzlich wird die Verwendung einer angepassten variablen Bitrate (constrained VBR) für Adaptive Streaming empfohlen, um die Vorteile der fehlergeschützen Segmentübertragung von HAS für eine bessere Kodiereffizenz nutzen zu können. Für constrained VBR müssen jedoch eigens geeignete Parameterwerte gefunden werden, die möglichst interoperabel über alle ADS Implementierungen gleichermaßen funktionieren. Dies konnte im Rahmen dieser Trest noch nicht umgesetzt werden. 13