Encrypted Media Extensions bietet eine API, mit der Webanwendungen mit Systemen zum Schutz von Inhalten interagieren können, um die Wiedergabe von verschlüsselten Audio- und Videoinhalten zu ermöglichen.
EME wurde entwickelt, damit dieselbe App und dieselben verschlüsselten Dateien in jedem Browser verwendet werden können, unabhängig vom zugrunde liegenden Schutzsystem. Ersteres wird durch die standardisierten APIs und den Ablauf ermöglicht, letzteres durch das Konzept der Common Encryption.
EME ist eine Erweiterung der HTMLMediaElement-Spezifikation – daher der Name. Da EME eine Erweiterung ist, ist die Browserunterstützung optional. Wenn ein Browser verschlüsselte Medien nicht unterstützt, kann er sie nicht abspielen. EME ist jedoch nicht erforderlich, um die HTML-Spezifikation zu erfüllen. Aus der EME-Spezifikation:
Dieser Vorschlag erweitert HTMLMediaElement und bietet APIs zur Steuerung der Wiedergabe geschützter Inhalte.
Die API unterstützt Anwendungsfälle von der einfachen Clear Key-Entschlüsselung bis hin zu hochwertigen Videos (bei entsprechender Implementierung des User-Agents). Der Lizenz-/Schlüsselaustausch wird von der Anwendung gesteuert, was die Entwicklung robuster Wiedergabeanwendungen ermöglicht, die eine Reihe von Technologien zur Inhaltsentschlüsselung und zum Schutz unterstützen.
In dieser Spezifikation wird kein System für den Inhaltsschutz oder die digitale Rechteverwaltung (Digital Rights Management, DRM) definiert. Stattdessen wird eine gemeinsame API definiert, die zum Erkennen, Auswählen und Interagieren mit solchen Systemen sowie mit einfacheren Systemen zur Inhaltsverschlüsselung verwendet werden kann. Die Implementierung von Digital Rights Management (DRM) ist für die Einhaltung dieser Spezifikation nicht erforderlich. Es muss nur das Clear Key-System als gemeinsame Baseline implementiert werden.
Die Common API unterstützt eine einfache Reihe von Funktionen zur Inhaltsverschlüsselung. Anwendungsfunktionen wie Authentifizierung und Autorisierung werden den Seitenautoren überlassen. Dies wird erreicht, indem die seitenbasierte Vermittlung von Nachrichten, die für das System zum Schutz von Inhalten spezifisch sind, erforderlich ist. Es wird also nicht von einer Out-of-Band-Kommunikation zwischen dem Verschlüsselungssystem und einem Lizenz- oder anderen Server ausgegangen.
EME-Implementierungen verwenden die folgenden externen Komponenten:
- Schlüsselsystem:Ein Mechanismus zum Schutz von Inhalten (DRM). EME definiert keine Key-Systeme selbst, mit Ausnahme von Clear Key (siehe unten).
- Content Decryption Module (CDM): Eine clientseitige Software oder ein clientseitiger Hardwaremechanismus, der die Wiedergabe verschlüsselter Medien ermöglicht. Wie bei Key Systems werden bei EME keine CDMs definiert, sondern eine Schnittstelle für Anwendungen bereitgestellt, über die sie mit verfügbaren CDMs interagieren können.
- Lizenzserver (Schlüsselserver):Interagiert mit einem CDM, um Schlüssel zum Entschlüsseln von Media bereitzustellen. Die Aushandlung mit dem Lizenzserver liegt in der Verantwortung der Anwendung.
- Verpackungsdienst:Codiert und verschlüsselt Medien für die Verteilung/Wiedergabe.
Eine Anwendung, die EME verwendet, interagiert mit einem Lizenzserver, um Schlüssel für die Entschlüsselung zu erhalten. Nutzeridentität und Authentifizierung sind jedoch nicht Teil von EME. Das Abrufen von Schlüsseln zur Medienwiedergabe erfolgt nach der optionalen Authentifizierung eines Nutzers. Dienste wie Netflix müssen Nutzer in ihrer Webanwendung authentifizieren. Wenn sich ein Nutzer in der Anwendung anmeldet, ermittelt die Anwendung die Identität und Berechtigungen des Nutzers.
Wie funktioniert EME?
So interagieren die Komponenten von EME entsprechend dem Codebeispiel unten:
Wenn mehrere Formate oder Codecs verfügbar sind, können Sie mit MediaSource.isTypeSupported() oder HTMLMediaElement.canPlayType() das richtige Format oder den richtigen Codec auswählen. Das CDM unterstützt jedoch möglicherweise nur einen Teil der Funktionen, die der Browser für unverschlüsselte Inhalte unterstützt. Am besten verhandeln Sie eine MediaKeys-Konfiguration, bevor Sie ein Format und einen Codec auswählen. Wenn die Anwendung auf das verschlüsselte Ereignis wartet, MediaKeys aber dann anzeigt, dass das ausgewählte Format/der ausgewählte Codec nicht verarbeitet werden kann, ist es möglicherweise zu spät, um ohne Unterbrechung der Wiedergabe zu wechseln.
Der empfohlene Ablauf besteht darin, zuerst MediaKeys auszuhandeln. Verwenden Sie dazu MediaKeysSystemAccess.getConfiguration(), um die ausgehandelte Konfiguration zu ermitteln.
Wenn nur ein Format/Codec zur Auswahl steht, ist getConfiguration() nicht erforderlich. Es ist jedoch weiterhin vorzuziehen, MediaKeys zuerst einzurichten. Der einzige Grund, auf das verschlüsselte Ereignis zu warten, besteht darin, dass nicht bekannt ist, ob die Inhalte verschlüsselt sind oder nicht. In der Praxis ist das jedoch unwahrscheinlich.
- Eine Webanwendung versucht, Audio oder Video mit einem oder mehreren verschlüsselten Streams abzuspielen.
- Der Browser erkennt, dass die Media verschlüsselt sind (siehe unten) und löst ein verschlüsseltes Ereignis mit Metadaten (initData) aus, die aus den Media zur Verschlüsselung abgerufen werden.
Die Anwendung verarbeitet den verschlüsselten Termin:
Wenn dem Media-Element kein MediaKeys-Objekt zugeordnet ist, wählen Sie zuerst ein verfügbares Schlüsselsystem aus. Verwenden Sie dazu navigator.requestMediaKeySystemAccess(), um zu prüfen, welche Schlüsselsysteme verfügbar sind. Erstellen Sie dann über ein MediaKeySystemAccess-Objekt ein MediaKeys-Objekt für ein verfügbares Schlüsselsystem. Die Initialisierung des MediaKeys-Objekts sollte vor dem ersten verschlüsselten Ereignis erfolgen. Die Lizenzserver-URL wird von der App unabhängig von der Auswahl eines verfügbaren Schlüsselverwaltungssystems abgerufen. Ein MediaKeys-Objekt stellt alle Schlüssel dar, die zum Entschlüsseln der Medien für ein Audio- oder Videoelement verfügbar sind. Sie stellt eine CDM-Instanz dar und bietet Zugriff auf das CDM, insbesondere zum Erstellen von Schlüsselsitzungen, die zum Abrufen von Schlüsseln von einem Lizenzserver verwendet werden.
Nachdem das MediaKeys-Objekt erstellt wurde, weisen Sie es dem Media-Element zu: setMediaKeys() verknüpft das MediaKeys-Objekt mit einem HTMLMediaElement, sodass seine Schlüssel während der Wiedergabe, d.h. während der Decodierung, verwendet werden können.
Die App erstellt eine MediaKeySession, indem sie createSession() für die MediaKeys aufruft. Dadurch wird eine MediaKeySession erstellt, die die Lebensdauer einer Lizenz und ihrer Schlüssel darstellt.
Die App generiert eine Lizenzanfrage, indem sie die im verschlüsselten Handler abgerufenen Media-Daten an das CDM übergibt. Dazu ruft sie generateRequest() für die MediaKeySession auf.
Das CDM löst ein Nachrichtenereignis aus: eine Anfrage zum Abrufen eines Schlüssels von einem Lizenzserver.
Das MediaKeySession-Objekt empfängt das Nachrichtenereignis und die Anwendung sendet eine Nachricht an den Lizenzserver (z. B. über XHR).
Die Anwendung empfängt eine Antwort vom Lizenzserver und übergibt die Daten mit der Methode „update()“ der MediaKeySession an das CDM.
Das CDM entschlüsselt die Medien mit den Schlüsseln in der Lizenz. Ein gültiger Schlüssel kann aus einer beliebigen Sitzung innerhalb der MediaKeys verwendet werden, die dem Media-Element zugeordnet sind. Das CDM greift über die Schlüssel-ID auf den Schlüssel und die Richtlinie zu.
Die Medienwiedergabe wird fortgesetzt.
Woher weiß der Browser, dass Medien verschlüsselt sind?
Diese Informationen befinden sich in den Metadaten der Media-Containerdatei, die ein Format wie ISO BMFF oder WebM hat. Bei ISO BMFF sind das Header-Metadaten, die als „Protection Scheme Information Box“ bezeichnet werden. WebM verwendet das Matroska-Element „ContentEncryption“ mit einigen WebM-spezifischen Ergänzungen. Für jeden Container in einer EME-spezifischen Registry sind Richtlinien verfügbar.
Zwischen dem CDM und dem Lizenzserver können mehrere Nachrichten ausgetauscht werden. Die gesamte Kommunikation in diesem Prozess ist für den Browser und die Anwendung nicht sichtbar: Nachrichten werden nur vom CDM und vom Lizenzserver verstanden. Die Anwendungsebene kann jedoch sehen, welche Art von Nachricht das CDM sendet. Die Lizenzanfrage enthält einen Nachweis der Gültigkeit des CDM (und der Vertrauensbeziehung) sowie einen Schlüssel, der zum Verschlüsseln der Inhaltsschlüssel in der resultierenden Lizenz verwendet wird.
Aber was machen CDMs eigentlich?
Eine EME-Implementierung bietet an sich keine Möglichkeit, Medien zu entschlüsseln. Sie stellt lediglich eine API für eine Webanwendung zur Interaktion mit Content Decryption Modules bereit.
Was CDMs tatsächlich tun, ist nicht in der EME-Spezifikation definiert. Ein CDM kann sowohl die Dekodierung (Dekomprimierung) von Medien als auch die Entschlüsselung übernehmen. Es gibt mehrere potenzielle Optionen für die CDM-Funktionalität, die nach Robustheit sortiert sind:
- Nur Entschlüsselung, um die Wiedergabe über die normale Media-Pipeline zu ermöglichen, z. B. über ein <video>-Element.
- Entschlüsselung und Decodierung, Übergabe von Videoframes an den Browser für das Rendern.
- Entschlüsselung und Decodierung, Rendering direkt in der Hardware (z. B. der GPU).
Es gibt mehrere Möglichkeiten, ein CDM für eine Web-App verfügbar zu machen:
- Ein CDM mit dem Browser bündeln
- Ein CDM separat verteilen
- Erstellen Sie ein CDM im Betriebssystem.
- Ein CDM in die Firmware einbinden
- Einbetten eines CDM in Hardware
Wie ein CDM zur Verfügung gestellt wird, ist nicht in der EME-Spezifikation definiert. In jedem Fall ist jedoch der Browser für die Prüfung und Bereitstellung des CDM verantwortlich.
EME schreibt kein bestimmtes Schlüsselsystem vor. Unter den aktuellen Desktop- und mobilen Browsern unterstützt Chrome Widevine und IE11 PlayReady.
Schlüssel von einem Lizenzserver abrufen
Bei der typischen kommerziellen Nutzung werden Inhalte mit einem Verpackungsdienst oder ‑tool verschlüsselt und codiert. Sobald die verschlüsselten Medien online verfügbar sind, kann ein Webclient einen Schlüssel (in einer Lizenz enthalten) von einem Lizenzserver abrufen und damit die Entschlüsselung und Wiedergabe der Inhalte ermöglichen.
Der folgende Code (angepasst aus den Beispielen für Spezifikationen) zeigt, wie eine Anwendung ein geeignetes Schlüsselsystem auswählen und einen Schlüssel von einem Lizenzserver abrufen kann.
var video = document.querySelector('video');
var config = [{initDataTypes: ['webm'],
videoCapabilities: [{contentType: 'video/webm; codecs="vp09.00.10.08"'}]}];
if (!video.mediaKeys) {
navigator.requestMediaKeySystemAccess('org.w3.clearkey',
config).then(
function(keySystemAccess) {
var promise = keySystemAccess.createMediaKeys();
promise.catch(
console.error.bind(console, 'Unable to create MediaKeys')
);
promise.then(
function(createdMediaKeys) {
return video.setMediaKeys(createdMediaKeys);
}
).catch(
console.error.bind(console, 'Unable to set MediaKeys')
);
promise.then(
function(createdMediaKeys) {
var initData = new Uint8Array([...]);
var keySession = createdMediaKeys.createSession();
keySession.addEventListener('message', handleMessage,
false);
return keySession.generateRequest('webm', initData);
}
).catch(
console.error.bind(console,
'Unable to create or initialize key session')
);
}
);
}
function handleMessage(event) {
var keySession = event.target;
var license = new Uint8Array([...]);
keySession.update(license).catch(
console.error.bind(console, 'update() failed')
);
}
Gängige Verschlüsselung
Mit Common Encryption-Lösungen können Contentanbieter ihre Inhalte einmal pro Container/Codec verschlüsseln und verpacken und sie mit einer Vielzahl von Schlüsselsystemen, CDMs und Clients verwenden, d. h. mit jedem CDM, das Common Encryption unterstützt. Beispielsweise kann ein mit PlayReady verpacktes Video in einem Browser mit einem Widevine-CDM wiedergegeben werden, das einen Schlüssel von einem Widevine-Lizenzserver abruft.
Das ist anders als bei älteren Lösungen, die nur mit einem vollständigen vertikalen Stack funktionieren, einschließlich eines einzelnen Clients, der oft auch eine Anwendungs-Laufzeitumgebung enthielt.
Common Encryption (CENC) ist ein ISO-Standard, der ein Schutzschema für ISO BMFF definiert. Ein ähnliches Konzept gilt für WebM.
Schlüssel löschen
EME definiert zwar keine DRM-Funktionen, die Spezifikation schreibt jedoch derzeit vor, dass alle Browser, die EME unterstützen, Clear Key implementieren müssen. Mit diesem System können Medien mit einem Schlüssel verschlüsselt und dann einfach durch Angabe dieses Schlüssels wiedergegeben werden. Clear Key kann in den Browser integriert werden. Es ist kein separates Entschlüsselungsmodul erforderlich.
Clear Key wird zwar wahrscheinlich nicht für viele Arten von kommerziellen Inhalten verwendet, ist aber vollständig mit allen Browsern kompatibel, die EME unterstützen. Außerdem ist es praktisch, um EME-Implementierungen und Anwendungen, die EME verwenden, zu testen, ohne einen Inhaltsschlüssel von einem Lizenzserver anfordern zu müssen. Ein einfaches Clear Key-Beispiel finden Sie unter simpl.info/ck. Unten finden Sie eine Anleitung zum Code, die den oben beschriebenen Schritten entspricht, jedoch ohne Interaktion mit dem Lizenzserver.
// Define a key: hardcoded in this example
// – this corresponds to the key used for encryption
var KEY = new Uint8Array([
0xeb, 0xdd, 0x62, 0xf1, 0x68, 0x14, 0xd2, 0x7b, 0x68, 0xef, 0x12, 0x2a, 0xfc,
0xe4, 0xae, 0x3c,
]);
var config = [
{
initDataTypes: ['webm'],
videoCapabilities: [
{
contentType: 'video/webm; codecs="vp8"',
},
],
},
];
var video = document.querySelector('video');
video.addEventListener('encrypted', handleEncrypted, false);
navigator
.requestMediaKeySystemAccess('org.w3.clearkey', config)
.then(function (keySystemAccess) {
return keySystemAccess.createMediaKeys();
})
.then(function (createdMediaKeys) {
return video.setMediaKeys(createdMediaKeys);
})
.catch(function (error) {
console.error('Failed to set up MediaKeys', error);
});
function handleEncrypted(event) {
var session = video.mediaKeys.createSession();
session.addEventListener('message', handleMessage, false);
session
.generateRequest(event.initDataType, event.initData)
.catch(function (error) {
console.error('Failed to generate a license request', error);
});
}
function handleMessage(event) {
// If you had a license server, you would make an asynchronous XMLHttpRequest
// with event.message as the body. The response from the server, as a
// Uint8Array, would then be passed to session.update().
// Instead, we will generate the license synchronously on the client, using
// the hard-coded KEY at the top.
var license = generateLicense(event.message);
var session = event.target;
session.update(license).catch(function (error) {
console.error('Failed to update the session', error);
});
}
// Convert Uint8Array into base64 using base64url alphabet, without padding.
function toBase64(u8arr) {
return btoa(String.fromCharCode.apply(null, u8arr))
.replace(/\+/g, '-')
.replace(/\//g, '_')
.replace(/=*$/, '');
}
// This takes the place of a license server.
// kids is an array of base64-encoded key IDs
// keys is an array of base64-encoded keys
function generateLicense(message) {
// Parse the clearkey license request.
var request = JSON.parse(new TextDecoder().decode(message));
// We only know one key, so there should only be one key ID.
// A real license server could easily serve multiple keys.
console.assert(request.kids.length === 1);
var keyObj = {
kty: 'oct',
alg: 'A128KW',
kid: request.kids[0],
k: toBase64(KEY),
};
return new TextEncoder().encode(
JSON.stringify({
keys: [keyObj],
}),
);
}
Um diesen Code zu testen, benötigen Sie ein verschlüsseltes Video, das abgespielt werden kann. Ein Video für die Verwendung mit Clear Key kann für WebM gemäß der Anleitung für webm_crypt verschlüsselt werden. Kommerzielle Dienste sind ebenfalls verfügbar (zumindest für ISO BMFF/MP4) und es werden weitere Lösungen entwickelt.
Zugehörige Technologie 1: Media Source Extensions (MSE)
Das HTMLMediaElement ist ein Objekt von schlichter Schönheit.
Wir können Medien laden, decodieren und abspielen, indem wir einfach eine Quell-URL angeben:
<video src="foo.webm"></video>
Die Media Source API ist eine Erweiterung von HTMLMediaElement, die eine genauere Steuerung der Medienquelle ermöglicht, indem JavaScript Streams für die Wiedergabe aus Video-„Chunks“ erstellen kann. Dies ermöglicht wiederum Techniken wie adaptives Streaming und Time-Shifting.
Warum ist MSE für EME wichtig? Denn neben der Verteilung geschützter Inhalte müssen kommerzielle Inhaltsanbieter die Inhaltsbereitstellung an Netzwerkbedingungen und andere Anforderungen anpassen können. Netflix ändert beispielsweise die Streaming-Bitrate dynamisch, wenn sich die Netzwerkbedingungen ändern. EME funktioniert mit der Wiedergabe von Media-Streams, die von einer MSE-Implementierung bereitgestellt werden, genauso wie mit Medien, die über ein src-Attribut bereitgestellt werden.
Wie kann ich Medien, die mit unterschiedlichen Bitraten codiert sind, in Chunks aufteilen und wiedergeben? Weitere Informationen finden Sie im Abschnitt zu DASH unten.
Unter simpl.info/mse können Sie MSE in Aktion sehen. In diesem Beispiel wird ein WebM-Video mit den File APIs in fünf Blöcke aufgeteilt. In einer Produktionsanwendung würden Videobereiche über AJAX abgerufen.
Zuerst wird ein SourceBuffer erstellt:
var sourceBuffer = mediaSource.addSourceBuffer(
'video/webm; codecs="vorbis,vp8"',
);
Der gesamte Film wird dann in ein Videoelement „gestreamt“, indem jeder Chunk mit der Methode appendBuffer() angehängt wird:
reader.onload = function (e) {
sourceBuffer.appendBuffer(new Uint8Array(e.target.result));
if (i === NUM_CHUNKS - 1) {
mediaSource.endOfStream();
} else {
if (video.paused) {
// start playing after first chunk is appended
video.play();
}
readChunk_(++i);
}
};
Zugehörige Technologie 2: Dynamic Adaptive Streaming over HTTP (DASH)
Ob Sie es nun Multi-Device, Multi-Plattform oder mobil nennen – das Web wird oft unter Bedingungen mit wechselnder Konnektivität genutzt. Die dynamische, adaptive Bereitstellung ist entscheidend, um mit Bandbreitenbeschränkungen und ‑variabilität in der Welt der verschiedenen Geräte zurechtzukommen.
DASH (auch MPEG-DASH) wurde entwickelt, um die bestmögliche Medienbereitstellung in einer unzuverlässigen Welt zu ermöglichen, sowohl für Streaming als auch für Downloads. Es gibt mehrere andere Technologien, die etwas Ähnliches leisten, z. B. HTTP Live Streaming (HLS) von Apple und Smooth Streaming von Microsoft. DASH ist jedoch die einzige Methode für adaptives Bitraten-Streaming über HTTP, die auf einem offenen Standard basiert. DASH wird bereits von Websites wie YouTube verwendet.
Was hat das mit EME und MSE zu tun? MSE-basierte DASH-Implementierungen können ein Manifest parsen, Videosegmente mit einer geeigneten Bitrate herunterladen und sie an ein Videoelement weiterleiten, wenn es benötigt wird. Dabei wird die vorhandene HTTP-Infrastruktur verwendet.
Mit DASH können Anbieter kommerzieller Inhalte also adaptives Streaming geschützter Inhalte durchführen.
DASH macht genau das, was der Name besagt:
- Dynamisch:Reagiert auf sich ändernde Bedingungen.
- Adaptiv:Die Audio- oder Videobitrate wird automatisch angepasst.
- Streaming:Ermöglicht das Streamen und Herunterladen.
- HTTP:Ermöglicht die Bereitstellung von Inhalten mit den Vorteilen von HTTP, ohne die Nachteile eines herkömmlichen Streaming-Servers.
Die BBC hat damit begonnen, Teststreams mit DASH bereitzustellen:
Die Media werden mehrmals mit unterschiedlichen Bitraten codiert. Jede Codierung wird als Darstellung bezeichnet. Diese werden in eine Reihe von Media-Segmenten unterteilt. Der Client spielt ein Programm ab, indem er Segmente in der richtigen Reihenfolge über HTTP von einer Darstellung anfordert. Darstellungen können in Adaptationssets mit Darstellungen mit gleichwertigen Inhalten gruppiert werden. Wenn der Client die Bitrate ändern möchte, kann er eine Alternative aus dem aktuellen Anpassungssatz auswählen und Segmente aus dieser Darstellung anfordern. Inhalte werden so codiert, dass der Client problemlos zwischen ihnen wechseln kann. Neben einer Reihe von Media-Segmenten hat eine Darstellung in der Regel auch ein Initialisierungssegment. Das kann als Header betrachtet werden, der Informationen zur Codierung, zu Framegrößen usw. enthält. Ein Client muss diese Informationen für eine bestimmte Darstellung abrufen, bevor er Mediensegmente aus dieser Darstellung nutzen kann.
Zusammenfassung:
- Media werden mit unterschiedlichen Bitraten codiert.
- Die Dateien mit unterschiedlichen Bitraten werden über einen HTTP-Server bereitgestellt.
- Eine Client-Web-App wählt aus, welche Bitrate mit DASH abgerufen und wiedergegeben werden soll.
Im Rahmen der Videosegmentierung wird programmatisch ein XML-Manifest erstellt, das als Media Presentation Description (MPD) bezeichnet wird. Hier werden Adaptation Sets und Darstellungen mit Dauer und URLs beschrieben. Eine MPD sieht so aus:
<MPD xmlns="urn:mpeg:DASH:schema:MPD:2011" mediaPresentationDuration="PT0H3M1.63S" minBufferTime="PT1.5S" profiles="urn:mpeg:dash:profile:isoff-on-demand:2011"
type="static">
<Period duration="PT0H3M1.63S" start="PT0S">
<AdaptationSet>
<ContentComponent contentType="video" id="1" />
<Representation bandwidth="4190760" codecs="avc1.640028" height="1080" id="1" mimeType="video/mp4" width="1920">
<BaseURL>car-20120827-89.mp4</BaseURL>
<SegmentBase indexRange="674-1149">
<Initialization range="0-673" />
</SegmentBase>
</Representation>
<Representation bandwidth="2073921" codecs="avc1.4d401f" height="720" id="2" mimeType="video/mp4" width="1280">
<BaseURL>car-20120827-88.mp4</BaseURL>
<SegmentBase indexRange="708-1183">
<Initialization range="0-707" />
</SegmentBase>
</Representation>
…
</AdaptationSet>
</Period>
</MPD>
(Dieses XML stammt aus der MPD-Datei, die für den YouTube DASH-Demoplayer verwendet wird.)
Laut DASH-Spezifikation könnte eine MPD-Datei theoretisch als Quelle für ein Video verwendet werden. Um Webentwicklern mehr Flexibilität zu bieten, haben sich Browseranbieter jedoch dafür entschieden, die DASH-Unterstützung JavaScript-Bibliotheken zu überlassen, die MSE verwenden, z. B. dash.js. Durch die Implementierung von DASH in JavaScript kann sich der Anpassungsalgorithmus weiterentwickeln, ohne dass Browser aktualisiert werden müssen. Mit MSE können auch alternative Manifestformate und Bereitstellungsmechanismen getestet werden, ohne dass Browseränderungen erforderlich sind. Der Shaka Player von Google ist ein DASH-Client mit EME-Unterstützung.
Das Mozilla Developer Network bietet eine Anleitung zur Verwendung von WebM-Tools und FFmpeg zum Segmentieren von Videos und Erstellen einer MPD.
Fazit
Die Nutzung des Internets zur Bereitstellung von kostenpflichtigen Video- und Audioinhalten nimmt enorm zu. Es scheint, dass jedes neue Gerät, egal ob Tablet, Spielekonsole, Smart-TV oder Set-Top-Box, Medien von den großen Content-Anbietern über HTTP streamen kann. Über 85 % der Mobil- und Desktopbrowser unterstützen jetzt <video> und <audio>. Cisco schätzt, dass Video bis 2017 80 bis 90 % des globalen Internetdatenverkehrs von Verbrauchern ausmachen wird. In diesem Zusammenhang wird die Browserunterstützung für die Verteilung geschützter Inhalte wahrscheinlich immer wichtiger, da Browseranbieter die Unterstützung für APIs, auf die die meisten Media-Plug-ins angewiesen sind, einschränken.
Weitere Informationen
Spezifikationen und Standards
EME-Spezifikation: Aktueller Editor-Entwurf Common Encryption (CENC) Media Source Extensions: Aktueller Editor-Entwurf DASH-Standard (ja, es ist eine PDF-Datei) Übersicht über den DASH-Standard
Artikel
DTG-Webinar (teilweise veraltet) Was ist EME? von Henri Sivonen Media Source Extensions (MSE) – Einführung MPEG-DASH-Teststreams: BBC R&D-Blogpost
Demos
Clear Key-Demo: simpl.info/ck Media Source Extensions (MSE)-Demo Der Shaka Player von Google implementiert einen DASH-Client mit EME-Unterstützung.