Encrypted Media Extensions bietet eine API, mit der Webanwendungen mit Content-Schutzsystemen interagieren können, um die Wiedergabe verschlüsselter Audio- und Videoinhalte zu ermöglichen.
EME soll es ermöglichen, dieselbe App und verschlüsselte Dateien in jedem Browser zu verwenden, unabhängig vom zugrunde liegenden Schutzsystem. Ersteres wird durch die standardisierten APIs und den Ablauf ermöglicht, während letzteres durch das Konzept der Common Encryption ermöglicht wird.
EME ist eine Erweiterung der HTMLMediaElement-Spezifikation – daher der Name. Da es sich um eine Erweiterung handelt, ist die Browserunterstützung für EME optional: Wenn ein Browser keine verschlüsselten Medien unterstützt, kann er sie nicht wiedergeben. EME ist jedoch nicht für die Einhaltung der HTML-Spezifikation erforderlich. Aus der EME-Spezifikation:
Mit diesem Vorschlag wird HTMLMediaElement erweitert und APIs zur Steuerung der Wiedergabe geschützter Inhalte bereitgestellt.
Die API unterstützt Anwendungsfälle von der einfachen Entschlüsselung mit einem Klarschlüssel bis hin zu hochwertigen Videos (bei entsprechender User-Agent-Implementierung). Der Lizenz-/Schlüsselaustausch wird von der Anwendung gesteuert, was die Entwicklung robuster Wiedergabeanwendungen ermöglicht, die eine Reihe von Technologien zur Entschlüsselung und zum Schutz von Inhalten unterstützen.
In dieser Spezifikation wird kein System für den Schutz von Inhalten oder die digitale Rechteverwaltung definiert. Stattdessen wird eine gemeinsame API definiert, mit der solche Systeme sowie einfachere Inhaltsverschlüsselungssysteme gefunden, ausgewählt und verwendet werden können. Die Implementierung der digitalen Rechteverwaltung ist für die Einhaltung dieser Spezifikation nicht erforderlich: Es muss nur das Clear Key-System als gemeinsame Baseline implementiert werden.
Die gemeinsame API unterstützt eine einfache Reihe von Funktionen zur Inhaltsverschlüsselung. Anwendungsfunktionen wie Authentifizierung und Autorisierung werden den Seitenautoren überlassen. Dazu wird gefordert, dass systemspezifische Nachrichten für den Inhaltsschutz über die Seite vermittelt werden, anstatt eine Out-of-Band-Kommunikation zwischen dem Verschlüsselungssystem und einer Lizenz oder einem anderen Server anzunehmen.
EME-Implementierungen verwenden die folgenden externen Komponenten:
- Schlüsselsystem: Ein Mechanismus zur Inhaltssicherung (Digital Rights Management, DRM). Außer Clear Key werden Schlüsselsysteme von EME nicht definiert. Weitere Informationen
- Content Decryption Module (CDM): Ein clientseitiger Software- oder Hardwaremechanismus, der die Wiedergabe verschlüsselter Medien ermöglicht. Wie bei Key Systems definiert EME keine Datenabgleichsmechanismen, sondern bietet eine Schnittstelle für Anwendungen, über die sie mit verfügbaren Datenabgleichsmechanismen interagieren können.
- Lizenz- (Schlüssel-)Server: Interagiert mit einem CDM, um Schlüssel zum Entschlüsseln von Medien bereitzustellen. Die Verhandlung mit dem Lizenzserver liegt in der Verantwortung der Anwendung.
- Paketierungsservice:Codiert und verschlüsselt Medien für die Bereitstellung/Nutzung.
Eine Anwendung, die EME verwendet, interagiert mit einem Lizenzserver, um Schlüssel zur Dekodierung abzurufen. Nutzeridentität und Authentifizierung sind jedoch keine Bestandteile von EME. Die Abruf von Schlüsseln zur Aktivierung der 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, bestimmt die Anwendung die Identität und Berechtigungen des Nutzers.
Wie funktioniert die erweiterte Medienwiedergabe?
So interagieren die Komponenten der erweiterten Medienwiedergabe, was dem Codebeispiel unten entspricht:
Wenn mehrere Formate oder Codecs verfügbar sind, können MediaSource.isTypeSupported() oder HTMLMediaElement.canPlayType() verwendet werden, um das richtige auszuwählen. Die CDM unterstützt jedoch möglicherweise nur einen Teil dessen, was der Browser für unverschlüsselte Inhalte unterstützt. Es ist am besten, eine MediaKeys-Konfiguration auszuhandeln, bevor du ein Format und einen Codec auswählst. Wenn die Anwendung auf das verschlüsselte Ereignis wartet, MediaKeys aber 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.
Wir empfehlen, zuerst MediaKeys auszuhandeln und mit MediaKeysSystemAccess.getConfiguration() die ausgehandelte Konfiguration abzurufen.
Wenn nur ein Format/Codec zur Auswahl steht, ist getConfiguration() nicht erforderlich. Es ist jedoch empfehlenswert, zuerst MediaKeys einzurichten. Der einzige Grund, auf das verschlüsselte Ereignis zu warten, ist, wenn nicht bekannt ist, ob die Inhalte verschlüsselt sind oder nicht. In der Praxis ist das jedoch unwahrscheinlich.
- Eine Webanwendung versucht, Audio- oder Videoinhalte mit einem oder mehreren verschlüsselten Streams abzuspielen.
- Der Browser erkennt, dass die Medien verschlüsselt sind (siehe Kasten unten), und löst ein verschlüsseltes Ereignis mit Metadaten (initData) aus, die aus den Medien zur Verschlüsselung stammen.
Die Anwendung verarbeitet das verschlüsselte Ereignis:
Wenn dem Medienelement kein MediaKeys-Objekt zugeordnet ist, wähle zuerst ein verfügbares Schlüsselsystem aus. Verwende dazu navigator.requestMediaKeySystemAccess(), um zu prüfen, welche Schlüsselsysteme verfügbar sind. Erstelle 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 App ruft die URL des Lizenzservers unabhängig von der Auswahl eines verfügbaren Schlüsselsystems ab. Ein MediaKeys-Objekt stellt alle Schlüssel dar, die zum Entschlüsseln der Medien für ein Audio- oder Videoelement verfügbar sind. Er stellt eine CDM-Instanz dar und bietet Zugriff auf die CDM, insbesondere zum Erstellen von Schlüsselsitzungen, mit denen Schlüssel von einem Lizenzserver abgerufen werden.
Nachdem das MediaKeys-Objekt erstellt wurde, weisen Sie es dem Medienelement zu: Mit setMediaKeys() wird das MediaKeys-Objekt mit einem HTMLMediaElement verknüpft, damit seine Schlüssel während der Wiedergabe, d.h. während der Dekodierung, verwendet werden können.
Die App erstellt eine MediaKeySession, indem sie die Methode createSession() auf den 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 Mediendaten an die CDM weitergibt, indem sie generateRequest() auf der MediaKeySession aufruft.
Die 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 update()-Methode der MediaKeySession an die CDM.
Der CDM entschlüsselt die Medien mit den Schlüsseln in der Lizenz. Es kann ein gültiger Schlüssel aus einer beliebigen Sitzung innerhalb der mit dem Medienelement verknüpften MediaKeys verwendet werden. Die CDM greift auf den Schlüssel und die Richtlinie zu, die anhand der Schlüssel-ID indexiert sind.
Die Medienwiedergabe wird fortgesetzt.
Woher weiß der Browser, dass Medien verschlüsselt sind?
Diese Informationen sind in den Metadaten der Mediencontainerdatei enthalten, die in einem Format wie ISO BMFF oder WebM vorliegen muss. Bei ISO BMFF sind das Header-Metadaten, die im Informationsfeld für das Schutzschema enthalten sind. WebM verwendet das Matroska-Element „ContentEncryption“ mit einigen WebM-spezifischen Ergänzungen. Für jeden Container in einer EME-spezifischen Registry werden Richtlinien bereitgestellt.
Beachte, dass es zwischen dem CDM und dem Lizenzserver mehrere Nachrichten geben kann. Die gesamte Kommunikation in diesem Prozess ist für den Browser und die Anwendung undurchsichtig: Nachrichten werden nur vom CDM und vom Lizenzserver verstanden, obwohl die App-Ebene sehen kann, welche Art von Nachricht das CDM sendet. Die Lizenzanfrage enthält einen Nachweis der Gültigkeit der 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 bereit, mit der diese mit Content Decryption Modules interagieren kann.
Die tatsächliche Funktionsweise von CDMs wird in der EME-Spezifikation nicht definiert. Eine CDM kann sowohl die Dekodierung (Dekomprimierung) von Medien als auch die Entschlüsselung übernehmen. Es gibt mehrere Optionen für die CDM-Funktionen, die von der am wenigsten bis zur am robustesten reichen:
- Nur Entschlüsselung, ermöglicht die Wiedergabe über die normale Medienpipeline, z. B. über ein <video>-Element.
- Entschlüsselung und Decodierung, Weitergabe von Videoframes an den Browser zum Rendern.
- Entschlüsselung und Dekodierung, Rendering direkt in der Hardware (z. B. der GPU).
Es gibt mehrere Möglichkeiten, eine CDM für eine Webanwendung verfügbar zu machen:
- Binde ein CDM mit dem Browser zusammen.
- CDM separat bereitstellen
- CDM in das Betriebssystem einbinden
- CDM in die Firmware aufnehmen
- Ein CDM in Hardware einbetten
Wie eine CDM verfügbar gemacht wird, wird in der EME-Spezifikation nicht definiert. In jedem Fall ist der Browser für die Prüfung und Freigabe der CDM verantwortlich.
EME schreibt kein bestimmtes Schlüsselsystem vor. Unter den aktuellen Desktop- und Mobilbrowsern unterstützt Chrome Widevine und IE11 PlayReady.
Schlüssel von einem Lizenzserver abrufen
Bei der kommerziellen Nutzung werden Inhalte in der Regel 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 mit dem Schlüssel die Entschlüsselung und Wiedergabe der Inhalte ermöglichen.
Der folgende Code (aus den Beispielen in der Spezifikation adaptiert) 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 Lösungen für die gemeinsame Verschlüsselung können Contentanbieter ihre Inhalte einmal pro Container/Codec verschlüsseln und verpacken und mit einer Vielzahl von Schlüsselsystemen, CDMs und Clients verwenden, also mit jeder CDM, die die gemeinsame Verschlüsselung unterstützt. Beispielsweise kann ein mit Playready verpacktes Video in einem Browser mit einer Widevine-CDM wiedergegeben werden, die einen Schlüssel von einem Widevine-Lizenzserver abholt.
Das ist im Gegensatz zu älteren Lösungen, die nur mit einem vollständigen vertikalen Stack funktionieren, einschließlich eines einzelnen Clients, der oft auch eine Anwendungslaufzeit umfasste.
Common Encryption (CENC) ist ein ISO-Standard, der ein Schutzschema für ISO BMFF definiert. Ein ähnliches Konzept gilt für WebM.
Clear Key
Obwohl EME keine DRM-Funktionen definiert, schreibt die Spezifikation 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 eingebunden werden und erfordert kein separates Entschlüsselungsmodul.
Clear Key wird wahrscheinlich nicht für viele Arten von kommerziellen Inhalten verwendet, ist aber vollständig interoperabel mit allen Browsern, die EME unterstützen. Es eignet sich auch zum Testen von EME-Implementierungen und EME-Anwendungen, ohne dass ein Inhaltsschlüssel von einem Lizenzserver angefordert werden muss. Ein einfaches Beispiel für einen Clear Key findest du unter simpl.info/ck. Unten findest du eine Schritt-für-Schritt-Anleitung für den 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ötigst du ein verschlüsseltes Video, das du abspielen kannst. Das Verschlüsseln eines Videos für die Verwendung mit Clear Key kann für WebM gemäß der Anleitung für webm_crypt erfolgen. 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 einfaches, aber schönes Element.
Wir können Medien einfach laden, decodieren und abspielen, indem wir eine src-URL angeben:
<video src="foo.webm"></video>
Die Media Source API ist eine Erweiterung von HTMLMediaElement, die eine detailliertere Steuerung der Medienquelle ermöglicht. Mit JavaScript können Streams zur Wiedergabe aus Video-Chunks erstellt werden. Dies ermöglicht wiederum Techniken wie adaptives Streaming und Zeitverschiebung.
Warum ist MSE für EME wichtig? Denn neben der Bereitstellung geschützter Inhalte müssen Anbieter kommerzieller Inhalte die Bereitstellung von Inhalten an Netzwerkbedingungen und andere Anforderungen anpassen können. Netflix ändert beispielsweise die Streambitrate dynamisch, wenn sich die Netzwerkbedingungen ändern. EME funktioniert mit der Wiedergabe von Medienstreams, die von einer MSE-Implementierung bereitgestellt werden, genau wie bei Medien, die über ein src-Attribut bereitgestellt werden.
Wie kann ich Medien, die mit unterschiedlichen Bitraten codiert wurden, in einzelne Segmente aufteilen und abspielen? Weitere Informationen finden Sie im Abschnitt DASH unten.
Du kannst MSE unter simpl.info/mse in Aktion sehen. In diesem Beispiel wird ein WebM-Video mithilfe der File APIs in fünf Blöcke aufgeteilt. In einer Produktionsanwendung werden Video-Chunks über AJAX abgerufen.
Zuerst wird ein SourceBuffer erstellt:
var sourceBuffer = mediaSource.addSourceBuffer(
'video/webm; codecs="vorbis,vp8"',
);
Der gesamte Film wird dann an 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);
}
};
Weitere Informationen zu MSE finden Sie im MSE-Einstiegsleitfaden.
Ähnliche Technologie 2: Dynamic Adaptive Streaming over HTTP (DASH)
Ob für mehrere Geräte, mehrere Plattformen oder Mobilgeräte – das Web wird oft unter Bedingungen mit wechselnder Konnektivität genutzt. Die dynamische, adaptive Auslieferung ist entscheidend, um Bandbreiteneinschränkungen und Variabilität in der Welt der vielen Geräte zu bewältigen.
DASH (auch MPEG-DASH genannt) wurde entwickelt, um die bestmögliche Medienübermittlung in einer schwankenden Welt zu ermöglichen, sowohl für Streaming als auch für Downloads. Es gibt mehrere andere Technologien, die etwas Ähnliches tun, z. B. HTTP Live Streaming (HLS) von Apple und Smooth Streaming von Microsoft. DASH ist jedoch die einzige Methode für das Streaming mit adaptiver Bitrate ü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 einem Videoelement zuführen, wenn es benötigt wird – und zwar mithilfe der vorhandenen HTTP-Infrastruktur.
Mit DASH können kommerzielle Contentanbieter also geschützte Inhalte adaptiv streamen.
DASH hält, was es verspricht:
- Dynamisch: reagiert auf sich ändernde Bedingungen.
- Adaptiv:Die Audio- oder Videobitrate wird angepasst.
- Streaming:Ermöglicht sowohl Streaming als auch Download.
- HTTP: Ermöglicht die Bereitstellung von Inhalten mit den Vorteilen von HTTP, ohne die Nachteile eines herkömmlichen Streamingservers.
Die BBC bietet Teststreams mit DASH an:
Die Medien 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 der Darstellung nacheinander über HTTP anfordert. Darstellungen können in Anpassungsgruppen von Darstellungen mit ähnlichen 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. Die Inhalte sind so codiert, dass diese Umstellung für den Client einfach ist. Neben einer Reihe von Mediensegmenten enthält 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 verwenden kann.
Zusammenfassung:
- Medien werden mit unterschiedlichen Bitraten codiert.
- Die verschiedenen Bitratedateien werden von einem 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. Darin werden Anpassungssätze und Darstellungen mit Dauern 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>
Diese XML-Datei stammt aus der .mpd-Datei, die für den YouTube DASH-Demoplayer verwendet wird.
Gemäß der DASH-Spezifikation kann eine MPD-Datei theoretisch als „src“ für ein Video verwendet werden. Um Webentwicklern jedoch mehr Flexibilität zu bieten, haben Browseranbieter die DASH-Unterstützung stattdessen JavaScript-Bibliotheken mit MSE wie dash.js überlassen. Durch die Implementierung von DASH in JavaScript kann der Anpassungsalgorithmus weiterentwickelt werden, ohne dass Browserupdates erforderlich sind. Mit MSE können Sie auch mit alternativen Manifestformaten und Bereitstellungsmechanismen experimentieren, ohne dass Änderungen am Browser erforderlich sind. Der Shaka Player von Google implementiert einen DASH-Client mit EME-Unterstützung.
Im Mozilla Developer Network findest du eine Anleitung dazu, wie du mit WebM-Tools und FFmpeg ein Video segmentierst und eine MPD erstellst.
Fazit
Die Nutzung des Webs für die Bereitstellung kostenpflichtiger Video- und Audioinhalte nimmt rasant zu. Es scheint, als ob jedes neue Gerät, sei es ein Tablet, eine Spielekonsole, ein internetfähiger Fernseher oder eine Set-Top-Box, Medien von den wichtigsten Inhaltsanbietern über HTTP streamen kann. Über 85 % der mobilen und Desktop-Browser unterstützen jetzt <video> und <audio>. Cisco schätzt, dass Videos bis 2017 80 bis 90 % des globalen Internettraffics von Verbrauchern ausmachen werden. In diesem Zusammenhang wird die Browserunterstützung für den Vertrieb geschützter Inhalte wahrscheinlich immer wichtiger werden, da Browseranbieter die Unterstützung für APIs einschränken, auf die die meisten Medien-Plug-ins angewiesen sind.
Weitere Informationen
Spezifikationen und Standards
EME-Spezifikation: aktueller Editor's Draft Common Encryption (CENC) Media Source Extensions: aktueller Editor's Draft DASH-Standard (ja, es ist eine PDF-Datei) Übersicht über den DASH-Standard
Artikel
DTG-Webinar (teilweise veraltet) What is EME? von Henri Sivonen Media Source Extensions-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