Konvergenz durch HTTP Adaptive Streaming - Medien für TV, Auto, und Smartphone

Transkript

1 Konvergenz durch HTTP Adaptive Streaming - Medien für TV, Auto, und Smartphone BICCtalk Multiformatkonvergenz 9. July, 2012, Garching Dr.-Ing. Nikolaus Färber Fraunhofer IIS Fraunhofer IIS 1 Nikolaus Färber

2 1. Motivation Medien für TV, Auto und Smartphone Fraunhofer IIS 2 Nikolaus Färber

3 1. Motivation Heute: Files from Home Formatanpassung Mediathek Speicher Fernsehsender itunes ADAMS User Profile Device Profile Session Status Internet Heim Mobilfunk Fraunhofer IIS 3 Nikolaus Färber

4 1. Motivation Heute: Files from Home Mediathek Fernsehsender itunes ADAMS User Profile Device Profile Session Status Internet Heim Mobilfunk Fraunhofer IIS 4 Nikolaus Färber

5 1. Motivation Morgen: Streams from Cloud Mediathek Fernsehsender itunes ADAMS User Profile Device Profile Session Status Internet Heim Mobilfunk Fraunhofer IIS 5 Nikolaus Färber

6 1. Motivation Morgen: Streams from Cloud Mediathek Fernsehsender itunes ADAMS User Profile Device Profile Session Status Internet?????? Heim Mobilfunk Fraunhofer IIS 6 Nikolaus Färber

7 1. Motivation Förderprojekt MIfoP und ADAMS IRT Geißendörfer & Leschinsky GmbH SpaceNet Loewe BMW Audi WebTun Fraunhofer ESK Fraunhofer IIS Fraunhofer IIS 7 Nikolaus Färber

8 Gliederung Konvergenz durch HTTP Adaptive Streaming 1. Motivation Medien im Heim, Auto und Smartphone Files from Home vs. Streams from Cloud 2. HTTP Adaptive Streaming Funktionsweise Proprietäre und standardisierte Lösungen 3. Mobilfunkkanal Sind wir schon soweit? Nominal vs. reale Datenrate Zeitliche Schwankung Mittlere Anzahl Pufferunterläufe Fraunhofer IIS 8 Nikolaus Färber

9 2. HTTP Adaptive Streaming Progressive Download Heute vorherrschend für Web Video Abspielen während des Herunterladens Abwarten eines sicheren Pufferfüllstandes Unterbrechung falls Kanalbitrate einbricht ( Pufferunterlauf ) Kanalbitrate R c Pufferstand B Medienbitrate R m Fraunhofer IIS 9 Nikolaus Färber

10 2. HTTP Adaptive Streaming Adaptive Streaming Erlaubt kontinuierliches Abspielen trotz Kanalschwankung Anpassung der Medienbitrate an die Kanalbitrate Geringere Wartezeiten Weniger Unterbrechungen Kanalbitrate R c Steuerung Pufferstand B Medienbitrate R m Fraunhofer IIS 10 Nikolaus Färber

11 2. HTTP Adaptive Streaming Adaptive Streaming Das grundlegende Konzept von Adaptive Streaming is bereits aus der Forschung und Industrie Pioneering work before 2000: Real Network Sure Streams [1] 2000: Microsoft Multiple Bit Rate (Windows Media Player 6.4) 2001: RD-Optimization Framework by P. Chou [2] 2004: 3GPP PSS Adaptive Streaming (3GPP TS , Rel-6) 2006: HTTP based MP4 file transfer by Färber [3] Diese basieren jedoch vorwiegend auf UDP und RTP Relativ neu ist HTTP-basiertes Adaptive Streaming [1] Conklin, Video coding for streaming media delivery on the Internet, IEEE Trans. on Circuits and Systems for Video Technology, Vol. 11, No. 3, March [2] Chou 2006, Rate-Distortion Optimized Streaming of Packetized Media, IEEE Trans. on Multimedia, Vol. 8, No. 2, April 2006 (submitted 2001). [3] Färber 2006, Adaptive progressive download based on the MPEG-4 file format, Journal of Zhejiang University. Science A 7 (2006), Supplement 1, pp Fraunhofer IIS 11 Nikolaus Färber

12 2. HTTP Adaptive Streaming Kurz und Bündig Was: in zwei Sätzen: HTTP Live [Adaptive] Streaming sends audio and video as a series of small files, typically of about 10 seconds duration, called media segment files. An index file, or playlist, gives the clients the URLs of the media segment files. [1] Warum: in einem Satz: Why not adapt media delivery to the Internet instead of trying to adapt the entire Internet to streaming protocols?"[2] [1] Apple Inc., HTTP Live Streaming Overview [2] Microsoft Corp., IIS Smooth Streaming Technical Overview Fraunhofer IIS 12 Nikolaus Färber

13 2. HTTP Adaptive Streaming Was: Funktionsweise R m3 R m2 R m1 Server Client HTTP GET R c bit rate R m3 R m2 R m1 time Fraunhofer IIS 13 Nikolaus Färber

14 2. HTTP Adaptive Streaming Warum: Vorteile 1. Kontinuierliche Wiedergabe durch Adaption 2. Live-Streaming 3. Wiederverwendung der HTTP Infrastruktur 4. Skalierbarkeit 5. Client Driven 6. Überwindung von Firewalls 7. Implizite Kanalschätzung 8. TCP friendly Fraunhofer IIS 14 Nikolaus Färber

15 2. HTTP Adaptive Streaming Notwendigkeit für Standards Apple HLS 2008 Microsoft SS GPP 2009 OIPF 2009 Adobe DS 2009 MPEG 2010 W3C 2011 Konvergenz zu MPEG DASH? Viele Firmen und Organisationen haben Lösungen auf dem Prinzip von HTTP Adaptive Streaming entwickelt und spezifiziert Marktfragmentierung ist ein Problem für den Nutzer und das Ecosystem MPEG DASH versucht Konvergenz durch offenen Standard zu erreichen Fraunhofer IIS 15 Nikolaus Färber

16 2. HTTP Adaptive Streaming Was spezifiziert MPEG DASH? HTTP Server MPD = in scope of DASH HTTP 1.1 DASH Client DASH spezifiziert Syntax der Playlist DASH spezifiziert NICHT: Codecs Container Verhalten des Clients Systemstandards müssen DASH anpassen bevor Interoperabilität gegeben ist! Fraunhofer IIS 16 Nikolaus Färber

17 2. HTTP Adaptive Streaming DASH Promoters Group MM Application DASH MPD H.264, AAC MP4 HTTP Fraunhofer IIS 17 Nikolaus Färber

18 2. HTTP Adaptive Streaming MPEG DASH: Media Presentation Description (MPD) Media Presentation Description (MPD) Period-1: start=0s, Adaptation-Set-1: H.264 Video Representation-1: 320x480, 500 kbps init-seg seg-1 seg-2 seg-3 Representation-2: 640x960, 1000 kbps init-seg seg-1 seg-2 seg-3 Representation-3: 768x1024, 2000 kbps init-seg seg-1 seg-2 seg-3 Adaptation-Set-2: AAC Audio, English Representation-1: stereo, 128 kbps init-seg seg-1 seg-2 seg-3 seg-4 Representation-2: 5.1 surround, 160 kbps init-seg seg-1 seg-2 seg-3 seg-4 Adaptation-Set-3: AAC Audio, German Period-2: start=1800s Adapt-1 Rep-1: Rep-2: Adapt-2 Rep-1: Period-3: start=1860s time Fraunhofer IIS 18 Nikolaus Färber

19 2. HTTP Adaptive Streaming MPEG DASH: Beispiel einer MPD <?xml version="1.0" encoding="utf-8"?> <MPD xmlns:xsi=" xmlns="urn:mpeg:dash:schema:mpd:2011" xsi:schemalocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" type="static" mediapresentationduration="pt658s" minbuffertime="pt1s" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011"> <BaseURL>./</BaseURL> <Period>  <AdaptationSet mimetype="audio/mp4" codecs="mp4a.40.5 subsegmentalignment="true" subsegmentstartswithsap="1"> <Representation id="2" bandwidth="32000"> <BaseURL>ed_36000_fragmented_segmented.mp4</BaseURL> </Representation> <Representation id="3" bandwidth="48000"> <BaseURL>ed_48000_fragmented_segmented.mp4</BaseURL> </Representation> <Representation id="4" bandwidth="64000"> <BaseURL>ed_64000_fragmented_segmented.mp4</BaseURL> </Representation> </AdaptationSet> </Period> </MPD> Fraunhofer IIS 19 Nikolaus Färber

23 Gliederung Konvergenz durch HTTP Adaptive Streaming 1. Motivation Medien im Heim, Auto und Smartphone Files from Home vs. Streams from Cloud 2. HTTP Adaptive Streaming Funktionsweise Proprietäre und standardisierte Lösungen 3. Mobilfunkkanal Sind wir schon soweit? Nominal vs. reale Datenrate Zeitliche Schwankung Mittlere Anzahl Pufferunterläufe Fraunhofer IIS 23 Nikolaus Färber

24 3. Mobilfunkkanal Maximale Bitraten nach Spezifikation Aber was geht wirklich in der Praxis? Fraunhofer IIS 24 Nikolaus Färber

25 3. Mobilfunkkanal Real Verfügare Bitrate: MobiPerf Network Performance Measure App for ios & Android Upload/download speed Latenz IP-Adressen, DNS, Gesammelte Daten abrufbar Netzzugangsart (2G, 3G, WiFi) Netzbetreiber Ort (GPS location) Zeit Fraunhofer IIS 25 Nikolaus Färber

26 3. Mobilfunkkanal MobiPerf: Heat Map Fraunhofer IIS 26 Nikolaus Färber

27 3. Mobilfunkkanal MobiPerf: Verfügbare Bitrate CDF p(r c <R max ) Bitrate R max [kbps] Basierend auf ~ Messungen in US/EU/Asien 16 sec TCP bulk data transfer Fraunhofer IIS 27 Nikolaus Färber

28 3. Mobilfunkkanal MobiPerf: Verfügbare Bitrate CDF p(r c <R max ) Bitrate R max [kbps] 3G (UMTS): 50% > 0.8 Mbps Fraunhofer IIS 28 Nikolaus Färber

29 3. Mobilfunkkanal Zeitliche Dynamik und Korrelation 3 h Autofahrt in Erlangen und Umland (~20 km 2 ) im Mai 2012 Autobahn, Landstrasse, Stadt Laptop mit T-Mobile USB Surf-Stick Meist 3G, auch EDGE 1 MByte Download alle 5 Sekunden TCP Slow Start unterbunden >2000 Messpunkte >2 BGyte Daten Fraunhofer IIS 29 Nikolaus Färber

30 3. Mobilfunkkanal Bitrate über der Zeit 5 Kanalbitrate: [Mbps] R c [Mbps] Zeit: time t [min] Fraunhofer IIS 30 Nikolaus Färber

31 3. Mobilfunkkanal Verfügbare Bitrate 1 CDF, CDF prob(r<rmax) p(r c ) MobiPerf 2010 Erlangen % > 2.1 Mbps Bitrate bit Rmax R max [Mbps] Fraunhofer IIS 31 Nikolaus Färber

32 2. Mobilfunkkanal Progressive Download Verhalten Verhalten durch zwei wesentliche Parameter bestimmt Medienbitrate Max. Puffer Beurteilungskriterium: Anzahl der Pufferunterlauf / Zeit Simulation basierend auf Messdaten Kanalbitrate R c Pufferstand B Max. Puffer B max Medienbitrate R m Fraunhofer IIS 32 Nikolaus Färber

33 3. Mobilfunkkanal Pufferunterläufe pro 10 Min 2.5 Qualität: E{ R v } [Mbps] Progressive Download: Fixe Bitrate = 1.8 Mbps Max. Puffer = 20 Sek. E{Pufferunterlauf} = Zuverlässigkeit: E{ Pufferunterläufe } [1/10min] Fraunhofer IIS 33 Nikolaus Färber

34 3. Mobilfunkkanal Pufferunterläufe pro 10 Min Max. Puffer B max = 20 Sek Qualität: E{ R v } [Mbps] Videobitrate: R v [Mbps] Zuverlässigkeit: E{ Pufferunterläufe } [1/10min] Fraunhofer IIS 34 Nikolaus Färber

35 3. Mobilfunkkanal Pufferunterläufe pro 10 Min Qualität: E{ R v } [Mbps] Max. Puffer B max = {20,30,40,50,60} Sek Zuverlässigkeit: E{ Pufferunterläufe } [1/10min] Fraunhofer IIS 35 Nikolaus Färber

36 3. Mobilfunkkanal Pufferunterläufe pro 10 Min Qualität: E{ R v } [Mbps] Max. Puffer B max = {20,30,40,50,60} Sek Adaptive Streaming: E{ Bitrate} = 2.06 Mbps E{ Pufferunterläufe } = 0.14/10min Puffer = 50 Sek. E{ Switch } = Zuverlässigkeit: E{ Pufferunterläufe } [1/10min] Fraunhofer IIS 36 Nikolaus Färber

37 3. Mobilfunkkanal Pufferunterläufe pro 10 Min 2.5 Qualität: E{ R v } [Mbps] Bei gleicher Zuverlässigkeit und gleicher Puffergröße 4x höhere Bitrate Zuverlässigkeit: E{ Pufferunterläufe } [1/10min] Fraunhofer IIS 37 Nikolaus Färber

38 4. Ausblick ADAMS Testplattform für Apple HLS Fraunhofer IIS 38 Nikolaus Färber

39 Zusammenfassung Konvergenz durch HTTP Adaptive Streaming Mediensynchronisation über die Cloud Files from Home Streams from Cloud Voraussetzung: Always On Streaming HTTP Adaptive Streaming: Einfach aber gut! Playlist + HTTP Download von Filesegmenten MPEG DASH als offener Standard zur Konvergenz (?) Mobilfunkkanal 50% > 0.8 Mbps (MobiPerf) bzw. 2.1 Mbps (Erlangen) Adaptive Streaming im Auto über 3G: 1 Abbruch bei 10 Videos a 10 Minuten mit 2 Mbps Ohne Adaption müsste Bitrate 4x reduziert werden Praxistest im Forschungsprojekt ADAMS Fraunhofer IIS 39 Nikolaus Färber

40 Fraunhofer IIS 40 Nikolaus Färber Ende