© Yun Wang, 123rf.com

Weiter stromaufwärts wartet HTML 5, um Flash abzulösen – so liest man immer wieder. Zumindest im Videostreaming-Bereich sind bei der Migration aber noch einige Stromschnellen zu überwinden.

Dass Flash als Auslaufmodell gilt, davon haben auch die Kunden der Videostreaming-Dienstleister gehört und fordern seit einer Weile explizit HTML-5-Support. Doch egal, ob es um Video-on-Demand oder Livestreaming geht: Vor dem Durchbruch von HTML 5 stehen noch technische und rechtliche Barrieren.

Flash: Der Favorit

Die bisherige Situation ist ja ohne Frage absurd: Flash gehört einem einzelnen Unternehmen und ist seit Jahren die einzige relevante Technologie, wenn es darum geht, Multimedia-Inhalte im Internet zu streamen und plattformübergreifend zu präsentieren – Silverlight und Java sind längst nicht so erfolgreich.

Adobe verdient dabei nicht nur an den Flash-Entwicklern, sondern kassiert auch für den Einsatz des hauseigenen Flash Media Servers. Der bekommt aber nach und nach Konkurrenz von anderen Anbietern, zu denen auch Open-Source-Lösungen wie Red Five gehören. Für Anwender ist Flash zwar kostenlos, einen Preis zahlen sie dennoch: Dank zahlreicher Sicherheitslücken gefährdet die Software seit Jahren ihre Rechner.

Da Flash auf den Clients als Plugin für Browser existiert, müssen die Plattformen nicht nur dessen Vorhandensein sicherstellen, sondern auch – schon aus Sicherheitsgründen – einen separaten Update-Mechanismus anbieten. Einige Seiten zeigen ihre Inhalte gar nicht erst an, wenn der Nutzer nicht die neueste Flash-Variante verwendet. Unter Linux fällt auf, dass Flash die CPU(s) stark belastet, was in der Vergangenheit nicht selten zum Einfrieren des Browsers oder gar des kompletten Betriebssystems führte. Zu den technischen Beschwerden kommt, dass sich Flash-Inhalte nur sehr statisch in das Browserfenster integrieren und wenig zugänglich sind.

HTML 5: Der Herausforderer

Einige der unter dem Stichwort HTML 5 versammelten Technologien sollen nicht nur die erwähnten Probleme mit Flash beheben. Doch beim Standardisieren reden viele Big Player mit, was die Konsensfindung nicht vereinfacht, weil juristische Fragen die technischen oft überlagern: Auch deshalb ist HTML 5 – zumindest im Videobereich – ein Moving Target. Das »video« -Tag ermöglicht es immerhin, Filme und Streams einfach in eine Webseite einzubinden (Abbildung 1). Dabei entscheidet der Browser selbst, welches der angebotenen Formate er abspielt (Listing 1).

01 <video width="640" height="360" controls>
02   <source src="movie.mp4" type="video/mp4">
03   <source src="movie.ogg" type="video/ogg">
04   Your browser does not support the video tag.
05 </video>

Abbildung 1: Das »video«-Tag von HTML 5 soll Flash als De-facto-Standard für Videostreaming ablösen und ist bereits im Einsatz.

Falsche und echte Streams

Man unterscheidet grob zwei Übertragungsarten: Livestreaming und Video-on-Demand [1]. Ersteres findet (fast) in Echtzeit statt. Klassischerweise verwandelt ein Transcoder ein Kamerabild in ein und manchmal mehrere streambare Videosignale. Listing 2 zeigt, wie man mit Ffmpeg im Two-Pass-Verfahren ein plattformübergreifendes Mpeg-4-Video erstellt. Dabei ist es wichtig, Ffmpeg mit Support für die nötigen Codecs zu installieren oder die Software selbst entsprechend zu kompilieren. Das Video wird an einen Streamingserver geschickt, von dem es die Clients dann abholen. Es gibt Livestreaming-Szenarios, in denen das Ausgangsmaterial bereits vollständig vorliegt, meist handelt es sich aber um ein leicht verzögertes Livesignal.

01 ffmpeg -i eingabedatei -an -pass 1 -s 640x360 -aspect 16:9 -vcodec libx264 -vpre slow_firstpass -flags2 +wpred -sc_threshold 40 -b_strategy 1  -g 250 -keyint_min 25 -me_method esa -me_range 18 -subq 1 -partitions all -flags2 +dct8x8 -bf 5 -directpred auto -trellis 1 -flags2 +wpred -b 500k -bt 500k -qcomp 0.6 -threads 0 > /dev/null
02
03 ffmpeg -i eingabedatei -acodec libfaac -ar 44100 -ab 128k -async 2 -pass 2 -s 640x360 -vcodec libx264 -vpre slow_firstpass -flags2 +wpred -sc_threshold 40 -b_strategy 1  -g 250 -keyint_min 25 -refs 5 -me_method esa -me_range 18 -subq 5 -partitions all -flags2 +dct8x8 -bf 5 -directpred auto -trellis 1 -flags2 +wpred -b 500k -bt 500k -qcomp 0.6 -threads 2 output.mp4

Klinken sich sehr viele Nutzer in einen Livestream ein, ergibt der Einsatz des Origin-Edge-Verfahrens Sinn: Dabei ordnet der Administrator mehrere Streamingserver in einer Pyramiden-Struktur an (Abbildung 2), in der der Origin-Server den Ausgangspunkt bildet. Er gibt das Signal an die Edge-Server weiter, um möglichst vielen Teilnehmern den Zugriff auf den Stream zu erlauben.

Abbildung 2: Das Origin-Edge-Schema sorgt dafür, dass die Streamingserver möglichst viele Clients in guter Qualität bedienen.

Ein Load Balancer verteilt die Clients nach dem Round-Robin-Prinzip auf die Edge-Server, während der (oder die) Origin-Server unsichtbar im Hintergrund werkeln und ihr Videosignal wiederum von einem Transkoder beziehen.

VoD und Pseudostreaming

Neben dem Livestreaming gibt es noch progressive Downloads und Pseudostreaming, die oft gemeinsam unter dem Begriff Video-on-Demand (VoD) laufen. Der Anbieter verbreitet dabei fertige Videos über das HTTP-Protokoll, was vor allem für die Filmindustrie interessant ist. Zwar spielen die (oft Web-basierten) Clients die Videos bereits kurz nach dem Start ab, ohne sie herunterzuladen, doch handelt es sich nicht um Livestreams.

Um für dieses Verfahren in Frage zu kommen, modifiziert der Anbieter vielmehr seine Videodateien so, dass sich der Header am Anfang und nicht wie üblich am Ende der Datei befindet. Der Vorteil dieser Transformation: Hier muss kein kostspieliger Flash-Streamingserver zum Einsatz kommen, weil der Player den Header schnell identifiziert und mit dem Abspielen der Datei beginnt, sobald genügend Bilddaten vorliegen.

Ein Problem progressiver Downloads besteht darin, dass der Zuschauer nicht ohne Weiteres zu einem späteren Zeitpunkt im Film springen kann, hierfür kommt dann HTTP-Pseudostreaming zum Einsatz. Dabei bittet ein Client den HTTP-Server, ein Video ab einem bestimmten Zeitpunkt abzuspielen. Der Server generiert dann den Header des Videos neu, ändert dabei aber die Startposition und spielt den Film von der Stelle mit dem nächstbesten Keyframe ab.

Streamingserver

Wer im Internet professionelle Streaming-Technologie verwendet, setzt meist zwangsläufig auf Flash – und konfiguriert seine Server nicht unbedingt selbst. Content Delivery Networks (CDN) wie Akamai, Limelight, Edgecast oder Level 3 stellen die komplette Streaming-Infrastruktur (Video-on-Demand und Livestreaming) sowie die geforderte Bandbreite bereit und erhalten dann die Inhalte von den Kunden.

Beim Einsatz dieser schlüsselfertigen Server fallen zwar Kosten an, doch die liegen meist unter denen, die sich aus dem hohen Traffic summieren. Wer es eine Nummer kleiner möchte, wählt entweder einen kleineren Streamingdienst oder installiert selbst einen kommerziellen Streamingserver. Neben Adobes Flash Media Server gibt es weitere Anbieter, etwa Wowza, den Helix Universal Server oder die IIS Media Services von Microsoft.

Wer sich beim Livestreaming die Lizenzen sparen will, muss selbst Hand anlegen. Es gibt einige Server unter Open-Source-Lizenzen, dazu gehören zum Beispiel Red Five [2], der unter der Apache-2.0-Lizenz steht, Flash-Inhalte streamt und gerade in Version 1.0 erschienen ist, sowie Flumotion [3], der aber nur in einer Basisvariante unter der GPL frei verfügbar ist. Auch der Streamingserver Darwin [4] steht für den nicht kommerziellen Betrieb unter der Apple Public Source License, bringt aber keinen Support für Flash-Streaming mit.

Die Zuverlässigkeit und Handhabbarkeit der Open-Source-Lösungen ist jedoch eingeschränkt: So hat Red Five kürzlich den Origin-Edge-Support aus dem Kern des Servers entfernt und das Feature in ein Plugin verwandelt. Nun arbeiten Entwickler daran, die Funktion wieder zu reparieren. In der Regel ist der Konfigurationsaufwand höher, weil die großen Streaming-Anbieter keine freien Lösungen im Angebot haben und man beim Livestreaming die Origin-Edge-Struktur selbst konfigurieren muss. Doch könnten die freien Alternativen in Zukunft interessant werden.

Livestreaming über RTMP

Flash macht Livestreaming auf der Client-Seite recht einfach: Alle Plattformen – mit Ausnahme von I-OS 4, 5 und 6, Windows Phone 7 und 8 sowie Android 4.1 – bringen Support für Flash mit, auch wenn die Nutzer es mitunter selbst installieren müssen. Das Livestreaming setzt einen Streamingserver voraus, der das verwendete Mpeg-4-Format in Pakete zerlegt. Steckten in der alten Version von Flash häufig noch der Sorenson-Spark-Codec und später VP6, die beide nur über eine konstante Bitrate verfügten, transportiert das Flash-Format heute meist Mpeg 4 AVC (auch als Mpeg 4 part 10 bekannt) mit dem H.264-Codec, der eine variable Bitrate besitzt und Videos in hoher Qualität erlaubt.

Für Livestreaming setzt Adobe vornehmlich auf das proprietäre RTMP (Real Time Messaging Protocol). Über Port 1953 streamen die Server ein Videosignal im Mpeg-4-Format an alle Clients. RTMP ist TCP-basiert, die Spezifikation hat Adobe erst 2009 offengelegt, als ohnehin viele Details bekannt waren. RTMP lässt sich wahlweise mit TLS/SSL absichern (RTMPS) oder via RTMPT in HTTP einbetten und über Port 80 tunneln, falls ein Unternehmen den Port 1953 sperrt.

Nicht zuletzt bietet Adobe über RTMPE eine eigene Verschlüsselung an, die Digital Rights Management (DRM) erlauben soll (Abbildung 3). Sie gilt jedoch als unsicher, und Tools wie »rtmpdump« können das Protokoll mitschneiden und entschlüsseln. Daneben gibt es PRTMP (Protected RTMP), das Livesignale verschlüsselt, aber nur einen Origin-Server zulässt, was es für großflächiges Streaming ausschließt.

Abbildung 3: Nicht nur der Flashplayer unterstützt Adobes DRM, auch der JW Player 6 spielt ein Video nur nach einer Passwortabfrage ab, wenn der Stream-Anbieter es so einrichtet.

Apples HLS

I-OS bereitete den Livestreaming-Anbietern in der Vergangenheit schnell Probleme, da Apple bei Livestreaming und Video-on-Demand auf das offene HTTP-Protokoll HLS (HTTP Live Streaming) setzte und dafür auch einen Entwurf beim IETF einreichte [5]. Zunächst verwendet Apple ebenfalls den H.264-Videocodec und AAC oder MP3 für das Audiosignal, den ein Software Stream Segmenter dann in 10-Sekunden-Teile zerlegt und in einen Mpeg-2-Transportstream (».ts« ) verpackt. Ein Segment soll dabei mindestens einen Keyframe enthalten.

Eine passende Playlist (auch Indexdatei genannt) im »m3u8« -Format erzeugt der Segmenter ebenfalls. Sie enthält Metadaten und URIs zu den Fragmenten. Es genügt nun, die Indexdatei samt Fragmenten über einen gewöhnlichen Webserver (etwa Apache) und HTTP an die Clients zu verteilen. Da der Segmenter die Playlist beim Livestreaming dynamisch generiert, darf der Server höchstens ein Segment in den Cache schieben, da die Clients andernfalls auf eine veraltete Playlist stoßen.

Dank AES-128-Support unterstützt HLS auch eine Art Digital Rights Management, wobei der Client den Schlüssel für einen Stream nach einer gewöhnlichen HTTPS-Authentifizierung erhält. Daneben gibt es Lösungen von Drittanbietern.

Soll das Material auf dem iPhone und iPod Touch laufen, darf man nur H.264-Material bis zum Baseline Profile Level 3.0 zu verwenden. Das iPad 1 und 2 setzen maximal auf den Main Profile Level 3.1, das neue iPad beherrscht den High Profile Level 4.1 [6].

Adobes HDS

Ähnlich wie HLS klingt eine Technologie, die unter anderem in Adobes Flash Media Server zum Einsatz kommt: Für Video-on-Demand, aber auch für Livestreaming bietet Adobe unter dem Kürzel HDS (HTTP Dynamic Streaming) eine Methode an, die HTTP verwendet. Sie verschickt fragmentierte Mpeg-4-Dateien (F4F), wobei Adobe die Metadaten sowie Audio- und Videodaten eines Streams auseinanderdividiert. Das hat für sehr professionelle und umfangreiche Video-on-Demand-Lösungen Vorteile: Anstatt einen Film zehnmal zu speichern, um zehn Sprachfassungen abzudecken, genügt es, eine Video- und zehn Audiospuren zu archivieren.

Adobes Flash Media Server bietet zudem die Möglichkeit, über PHDS (Protected HDS) die Inhalte mit DRM zu schützen: Dabei bettet der Server Lizenzen in die Metadaten des Streams ein, die der Flashplayer 11 und Air 3 dann auslesen und umsetzen – ohne Flash funktioniert die Technik also nicht.

Adaptive Bitrate Streaming

Da die Qualität der Streams beim Video-on-Demand und beim Livestreaming aufgrund sich verändernder Bandbreite mitunter sehr stark variiert, bieten Apple und Adobe, aber auch Microsoft Möglichkeiten der Bandbreitenanpassung zwischen den Clients und Servern. Apples HTTP-Livestreaming (HLS) erlaubt es, eine der Indexdatei übergeordnete Master-Indexdatei zu erstellen. So lassen sich mehrere Streams gleichen Inhalts in unterschiedlichen Qualitätsstufen erzeugen, der Client wechselt bei eingeschränkter Bandbreite automatisch auf einen Stream minderer Qualität.

Adobes HDS trägt das dynamische Streaming ja bereits im Namen und bearbeitet Material, das die Video- und Audiocodecs VP6 und MP3 sowie H.264 und AAC verwendet. Der Origin-Server, der ein normaler Apache-Server sein darf, liefert den Clients die Filmsegmente in der angefragten Qualität zurück. Im Gegensatz zu HLS muss der Client nicht ständig eine neue Manifest-Datei herunterladen, weil HDS Sequenznummern in den Segmentanfragen unterbringt, was auch den Einsatz kleinerer Segmente von 2 bis 5 Sekunden erlaubt. Daneben bietet Adobe auch RTMP Dynamic Streaming an: Anders als bei HDS, wo der Encoder aus einem Ausgangssignal Streams unterschiedlicher Qualität erzeugt, muss der Streaming-Anbieter die Streams hier explizit selbst enkodieren.

Bei Microsoft läuft es ähnlich, mit dem Unterschied, dass die als Smooth Streaming bezeichnete Technologie anfänglich nur mit Silverlight und Windows Phone 7 funktionierte und der Dienst Teil der IIS Media Services Extension ist. Ab IIS Media Services 4.0 beherrscht Microsoft auch Smooth Streaming für Apples I-OS, nicht aber für Flash-Clients.

Mpeg-Dash

Der HTML-5-Ansatz für das dynamische Streamen von Inhalten heißt Dynamic Adaptive Streaming over HTTP (auch Mpeg-Dash genannt) und funktioniert ähnlich wie Apples HLS. Im Gegensatz zu den anderen Lösungen ist es aber bereits seit April 2012 ein internationaler Standard (ISO/IEC 23009-1:2012) und wird von Adobe bereits offiziell unterstützt, allerdings noch nicht von Apple und Microsoft.

Die Spezifikation schlägt als Containerformate Mpeg 4 und Mpeg-2-Transportstream vor, schert sich aber sonst nicht um den Audio- und Videocodec oder das darunterliegende Transportprotokoll. Zu den ersten Implementierungen gehören ein VLC-Plugin und eine Open-Source-Bibliothek namens Libdash [7]. Browser sollen Mpeg-Dash künftig über die Media Source Extensions [8] unterstützen. In Chromium 25 lässt sich ein experimenteller Mpeg-Dash-Support über »chrome://flags« aktivieren, was aber noch nicht für den Einsatz im professionellen Livestreaming genügt.

Resümierend lässt sich feststellen, dass Livestreaming über HTML 5 derzeit noch nicht funktioniert, weil Mpeg-Dash noch nicht so weit ist – wenigstens Video-on-Demand klappt. Apples HLS unterstützt bisher lediglich Safari und I-OS. Offiziell soll zwar auch Android HLS-Support mitbringen, doch in der Praxis ist selbst unter Android 4.1 keine Suche im Stream möglich, auch wenn das System wenigstens das Seitenverhältnis von Videos richtig erkennt.

Bleibt noch RTSP: Das Realtime Streaming Protocol wird gern als Fallback-Lösung für Android-Clients empfohlen, wenn diese weder Flash noch HLS beherrschen. Der Praxistest mit diversen Android-Systemen zeigt allerdings, dass auch RTSP nicht zuverlässig funktioniert. Am besten lassen sich diese Streams noch über ein VLC-Plugin betrachten, aber das erfordert von den Nutzern wiederum die Installation einer Zusatzsoftware.

Die große Migration

Immerhin unterstützen bereits 80 Prozent aller Systeme das »video« -Tag von HTML 5 – eine Ausnahme bilden die IE-Versionen 6, 7 und 8 sowie einige exotische Browser. Doch das Video-Element birgt verschiedene Attribute, mit denen die Browser schon weniger gut klarkommen. Ein Test [9] von Longtail Video, dem Hersteller des JW Player, offenbarte im Januar 2013, wo es noch hakt. So fehlte dem Internet Explorer 9 und 10 sowie den Browsern von I-OS 4, 5 und 6 die Unterstützung für das »preload« -Attribut, und nur die wenigsten Browser brachten Support für »poster« mit.

Das »video« -Element bringt von Hause aus zwar ein paar grundlegende Steuerfunktionen mit, doch häufig kontrollieren Javascript-basierte Player wie JW Player (Listing 3), Flowplayer, Video JS Player die Videos Server-seitig und greifen dafür auf das Javascript-API für das »video« -Tag zu. Insbesondere ältere Android-Versionen bieten für Buffering, Seeking, Loading und Playback nur sehr eingeschränkten Support an.

01 <div id="video"></div>
02 <script src="http://player.streampark.tv/jwplayer/jwplayer.js"></script>
03 <script type="text/javascript">
04 jwplayer('video').setup({
05     autostart: true,
06     sources: [
07     { file: "http://stream10.streampark.tv/bbb720.mp4" },
08     { file: "http://stream.streampark.tv/streampark/bbb720/playlist.m3u8" },
09     { file: "rtmp://stream.streampark.tv/streampark/mp4:bbb720.mp4" },
10     { file: "http://stream10.streampark.tv/td/bbb720.webm" }
11 ],
12 height:  360,
13 width: 640,
14 primary: "html5"
15 });
16 </script>

Im Bereich Barrierefreiheit unterstützen laut Longtail Video nur 43 Prozent der Browser Features wie »text track« und das zugehörige Web-VTT-Format. Hier gibt es noch einiges nachzuholen. Doch fast noch wichtiger wäre es, zunächst einen gemeinsamen Codec zu finden.

Einer für alle

Sah die HTML-5-Spezifikation [10] anfangs vor, den freien Theora-Codec im Ogg-Container plattformübergreifend zu verwenden, verschwand diese Idee recht bald sang- und klanglos aus der Spezifikation. Der angeblich Grund war, dass Theora Patente verletzen könne, was große Firmen wie Apple, die sich an der Codec-Findung beteiligen, unruhig machte. Die unbewiesene Patentbehauptung stammte von der Mpeg Licensing Administration (MPEG LA), einem Unternehmen, das offiziell Lizenzen für diverse Videocodecs vergibt. Zugleich hat es kein Problem damit, mit Mobile Medias Ideas ein Subunternehmen zu betreiben, das Beobachter als klassischen Patenttroll bezeichnen.

Aktuell unterstützen Microsoft und Apple mit ihren Browsern Internet Explorer und Safari das Mpeg-4-AVC-Format mit dem H.264-Codec, den auch Adobe und Apple einsetzen. Der Codec ist weit verbreitet, aber patentbelastet. Hersteller und Nutzer müssen ihn bei der MPEG LA lizenzieren. Dennoch unterstützen ihn Safari und der IE bisher. Google hat angekündigt, ihn aus Chrome zu entfernen, das aber noch nicht getan. Selbst Mozilla denkt darüber nach, künftig H.264 zu unterstützen, falls ein Drittanbieter einen Decoder dafür verfügbar macht.

Die bessere Lösung wäre sicher, wenn die Browserhersteller sich auf Webm einigen würden, dessen Containerformat dem von Matroska ähnelt. Mozilla, Opera und Chrome unterstützen Webm bereits, für den Internet Explorer 9 gibt es ein Plugin von Google (Abbildung 4).

Abbildung 4: Google bietet ein Plugin an, über das sich der Internet Explorer mit Webm erweitern lässt.

Den darin enthaltenen VP8-Codec hat Google von On2 gekauft und kürzlich von angeblichen Patentansprüchen der MPEG LA befreit [11], selbst gegen VP9 kann die MPEG LA künftig keine Ansprüche geltend machen. Auch wenn Webm bisher längst nicht so verbreitet ist wie H.264, könnte die Lizenzfreiheit die Sachlage komplett ändern.

Weite Teile der Open-Source-Community stehen hinter dem Codec, den Google unter einer BSD-Lizenz veröffentlicht und an dessen Entwicklung sich unter anderem Vorbis- und Theora-Entwickler Christopher Montgomery beteiligt. Es kann aber ebenso passieren, dass sich die Parteien nicht auf einen Codec einigen und fortan mehrere nutzen.

Wer also VoD mit HTML-5-Technologien umsetzt, sollte den Stream gleich in zwei Varianten anbieten: Im Mpeg-4-Format und als Webm-Container. Als Fallback-Lösungen kommen bevorzugt Flash und RTSP zum Einsatz, weil vor allem ältere Browser noch kein HTML-5-Video unterstützen.

Auf der Webseite http://html5test.com lässt sich prüfen, welche Videoformate der eigene Browser kennt. Das führt zu Überraschungen, wenn sich herausstellt, dass auch der Standardbrowser von Cyanogenmod 10.1 (Abbildung 5) – das auf Android 4.2.1 basiert – weder Webm noch Ogg noch Mpeg 4 beherrscht. Erst die Installation von Firefox bringt Ogg, Webm und Mpeg 4 aufs Smartphone.

Abbildung 5: Überraschung! Der Standardbrowser von Cyanogenmod 10.1 unterstützt offenbar keines der aktuellen Videoformate.

Tatsächlich sind einige Codecs Teil des Browsers, andere stecken in Plugins von Drittanbietern und wieder andere im Multimedia-Framework des Betriebssystems, etwa im Falle von Gstreamer. In einer perfekten Welt würden die Codecs hingegen für alle Browser auf allen Systemen in einem Browser-Add-on oder -Plugin stecken, das der Browser gleich mitinstalliert. Das würde es auch ermöglichen, neue Codecs auch auf älteren Rechnern einfach nachzurüsten.

Die Rechtefrage

Digital Rights Management ist für die Entwickler freier Software ein rotes Tuch. Ihre Argumente sind schlüssig: Sobald ein Client Bild und Ton abspielt, lassen sich davon Kopien erstellen – sei es als Screencast oder mit einer herkömmlichen Kamera unter Nutzung des Kopfhörersignals. Schutzfunktionen lassen sich meist hacken: Tools wie das erwähnte »rtmpdump« entschlüsseln RTMPS- und RTMPE-Streams, auch die Verschlüsselungen für DVDs (CSS) und Bluray (BD+ und AACS) sind längst ausgehebelt. Will ein findiger Hacker an die Inhalte kommen, wird ihm das auch gelingen. Trotzdem verlangen einige Kunden DRM, weshalb das Thema in der HTML-5-Debatte wieder hochkocht.

Encrypted Media Extension

Ende Februar 2013 haben Mitarbeiter von Microsoft, Netflix und Google einen Entwurf für eine Encrypted Media Extension auf den Weg gebracht [12], sie soll HTML 5 und DRM zusammenbringen. Netflix dürfte ein typischer DRM-Befürworter sein: Kann das Unternehmen Hollywood gegenüber glaubhaft versichern, dass die Inhalte beim HTML-5-Streaming sicher sind (oder zumindest so erscheinen), dürfte die Filmindustrie einer Verbreitung ihrer Inhalte zustimmen.

Die Autoren des Entwurfs wollen DRM aber nicht in HTML 5 selbst implementieren, weil das schlicht mit den Zielen von HTML 5 nicht vereinbar ist. In einem Bugreport zum Thema [13] bringt David Singer die Problematik auf den Punkt: HTML sei ein Präsentationslayer, das DRM-Problem gehöre nicht dorthin. Ein Redakteur des Entwurfs – der Google-Mitarbeiter (!) Ian Hickson – lehnte den DRM-Vorstoß mit dem lapidaren Satz “DRM is evil” ab, konkretisierte ihn jedoch später. Unter anderem führte er an, dass DRM mit einem offenen Standard nicht vereinbar sei und seine Implementierer in einigen Ländern rechtliche Konsequenzen befürchten müssten.

Die Encrypted Media Extension schlägt daher vor, das API des »HTMLMediaElements« auszubauen und damit die Wiedergabe geschützter Inhalte zu steuern. Stößt das »video« -Element von HTML 5 auf einen verschlüsselten Film, bittet es ein externes Content Decryption Module (CDM) darum, den Inhalt zu entschlüsseln. Das DRM-System soll dabei das komplette Spektrum von einfachen bis zu komplexen Schutzverfahren unterstützen. Das CDM, das den geheimen Schlüssel verwaltet, kann dabei Teil des Browsers sein oder als Bibliothek auf dem Betriebssystem lagern. Auf Samsungs ARM-Chromebook setzt Netflix das Verfahren bereits in die Praxis um und vertraut für den DRM-Teil offenbar auf eine mitgelieferte Bibliothek [14].

Open vs. DRM

An dieser Stelle ergibt sich allerdings ein fundamentales Problem für die freie Software: Ein vor dem Nutzer im Content Decryption Module verborgener Schlüssel widerspricht der Open-Source-Philosophie und verstößt zudem teilweise gegen die Lizenzbedingungen freier Software. Ein Lösungsvorschlag der Industrie besteht darin, das CDM in die Firmware einer externen Hardware einzubacken und dem Browser per API zugänglich zu machen. Offen ist die Frage, wie man trotz offenem Grafikstack dafür sorgen will, dass der Zuschauer die entschlüsselten Frames nicht abgreift.

Aufgrund dieser offenen Fragen bleibt abzuwarten, ob der Vorschlag zum W3C-Standard werden kann. Ist das nicht der Fall, könnte die Industrie einmal mehr ein eigenes Süppchen kochen oder einfach Fakten schaffen. Möglicherweise weichen die Unternehmen aber auch auf andere Wege aus, um ihre Inhalte zu schützen, etwa auf digitale Wasserzeichen. Selbst einige Tricks mit Javascript führen bei vielen Nutzern schon zum erhofften Effekt, aber DRM im klassischen Sinn ist beim Streaming mit Bordmitteln nicht möglich.

Fazit

Wer zurzeit im Livestreaming-Bereich von Flash zu HTML 5 wechseln möchte, kommt ohne Fallback-Lösungen nicht weit, wobei auch RTSP nur unter bestimmten Konditionen funktioniert. Bei Video-on-Demand gibt es hingegen die Möglichkeit, Videostreams in zwei oder mehr Formaten anzubieten, die dann in allen aktuellen Browsern laufen. Die Betonung liegt auf aktuell: In Behörden, Unternehmen und Organisationen sind oft noch Windows XP oder ältere Linux-Versionen im Einsatz. Deren Uralt-Browser kennen das »video« -Element oft gar nicht, sondern nur Flash.

Auf Mobilgeräten fehlt Flash vielfach, aber auch die HTML-5-Lage ist recht unklar. Insbesondere ältere Android-Systeme bereiten beim Livestreaming Probleme. Die Codec-Abdeckung bleibt Glückssache, weil die Hardwarehersteller mitunter selbstständig am Videosupport schrauben. Auf der anderen Seite gibt es fast täglich Neues zu den HTML-5-Features zu berichten, denn es passiert in diesem Bereich gerade sehr viel. Insofern bleibt die Hoffnung, dass Flash eines möglichst nahen Tages aus Altersschwäche friedlich entschlummert.