HTTP streaming. Segen oder Fluch? Flegen.

Inspiriert vom Artikel HTTP streaming aus dem CDN Strategy Blog sehe ich mich genötigt ein paar eigene Worte zum Thema HTTP streaming zu verbreiten.
In letzter Zeit haben mich mehrere Bekannte erregt kontaktiert mit Aussagen wie “der Tod der Streamingserver”, “da kann Adobe einpacken”, “endlich hält sich jmd. an die Standards” u.s.w.. Ich teile die Begeisterung zum Teil … und zum Teil auch nicht.
Vorerst: Was ist das “neue” HTTP streaming und wie unterscheidet es sich von herkömmlichen Technologien? Bei der herkömmlichen Streamingtechnologie (Windows Media Server, Flash Media Server / Wowza / Red5, QuickTime Streaming Server, Real Server …) fragt der Client in einem speziellen Protokoll nach dem Stream (rtmp, rtsp, mms). Der Datenaustausch findet wenn möglich in diesem speziellen Streaming-Protokoll über UDP statt und verursacht so sehr wenig Overhead an Daten (die Bandbreite wird also geschont). Darüberhinaus findet ein ständiger Datenaustausch zwischen Client und Server statt. Der Server versucht immer nur die gerade nötigen Pakete an den Client zu versenden. Wenn der Client an eine andere Stelle des Videos springt, dann erhöht der Server die Bandbreite kurzfristig stark um den Buffer des Clienten zu füllen (Burst). Danach wird die Bandbreite wieder auf das nötigste reduziert.
Die Übertragung im UDP Protokoll spart ca. 10% Bandbreite. Wenn Firewalls die Streaming Protokolle sperren ist es möglich den Stream automatisiert durch http zu tunneln (rtmpt bspw.).

HTTP streaming verwendet einen vollkommen anderen Ansatz. Die Film oder Audiodatei wird dabei in sehr viele kleine Schnipsel (Chunks) zerteilt. Der Client lädt sich eine “Playlist” Datei der Chunks herunter und fragt dann die benötigten Dateien via HTTP GET vom Server an. Der Client lädt zunächst den gesamten Header des Films herunter (der kann bei h264 und einem 30 minütigen Film einige 100 kb umfassen).
Das erste Problem für die Serverinfrastruktur ist, dass mit dieser Technologie sehr, sehr viele Requests auf kleine Files entstehen. Dabei ist es zunächst egal, ob die Chunks real als kleine Filmschnipsel vorliegen oder (sinnvollerweise) mit einem Byte-Range aus der Originaldatei abgefragt werden.
Ich habe noch nicht herausbekommen, was Adobe unter dem angekündigten HTTP streaming im kommenden Flash Player hauptsächlich für mobile Geräte versteht … wahrscheinlich wird es noch etwas proprietärer als man spontan vermuten möchte. Das IPhone unterstützt (seit FW 3.0) HTTPStreaming (Hier ein Link auf die Tech Specs). Auf ioncannon gibt es ein Tutorial wie man ein Video mit OpenSource Mitteln für gechunktes HTTP streaming vorbereitet.

Plug&Play ist etwas anderes. Auf der anderen Seite eröffnet dieser Ansatz die Möglichkeit eine Streaming-Infrastruktur ohne lästige Lizenzkosten zu realisieren. Meiner Einschätzung nach bietet HTTP streaming für große Spieler im Moment keine Möglichkeit die Kosten zu senken. Die benötigte Serverinfrastruktur für HTTP streaming (Transcoding, Verwaltung, Streaming, Logfiles, Statistiken) ist wahrscheinlich größer und komplexer (und daher auch teurer) als es mit bestehenden Streamingserver nötig ist. Trotzdem bietet HTTP streaming für Startups eine Möglichkeit einen Markt zu betreten der qua Investitionskosten einem kleinen Zirkel vorenthalten war.
Außerdem müssen wir proprietäre Protokolle natürlich schnellstmöglich aus dem Netz herausbekommen. Gerade an den relevanten Stellen “Video- und Audiostreaming gibt es endlich eine Alternative zu den bestehenden Lösungen – darüber können wir alle sehr froh sein.

One thought on “HTTP streaming. Segen oder Fluch? Flegen.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>