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 Klartextschlü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.
Diese Spezifikation definiert kein System zum Schutz von Inhalten oder zur digitalen Rechteverwaltung. 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 allgemeine API unterstützt einen einfachen Satz von Funktionen für die Inhaltsverschlüsselung, sodass den Seitenautoren Anwendungsfunktionen wie Authentifizierung und Autorisierung überlassen werden. Dies wird erreicht, indem eine systemspezifische Nachricht zum Inhaltsschutz von der Seite vermittelt wird, anstatt von einer Out-of-Band-Kommunikation zwischen dem Verschlüsselungssystem und einer Lizenz oder einem anderen Server auszugehen.
Für EME-Implementierungen werden die folgenden externen Komponenten verwendet:
- Schlüsselsystem: Ein Mechanismus zur Inhaltssicherung (Digital Rights Management, DRM). EME definiert mit Ausnahme von „Schlüsselsystem löschen“ keine Schlüsselsysteme selbst. Weitere Informationen dazu finden Sie weiter unten.
- Inhaltsentschlüsselungsmodul (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, um mit verfügbaren Datenabgleichsmechanismen zu interagieren.
- 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.
Beachten Sie, dass eine Anwendung, die EME verwendet, mit einem Lizenzserver interagiert, um Schlüssel zum Aktivieren der Entschlüsselung abzurufen. Die Nutzeridentität und -authentifizierung sind jedoch nicht Teil 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 EME?
So interagieren die Komponenten der erweiterten Medienwiedergabe, wie im Codebeispiel unten dargestellt:
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 empfiehlt sich, eine MediaKeys-Konfiguration auszuhandeln, bevor Sie ein Format und einen Codec auswählen. Wenn die Anwendung auf das verschlüsselte Ereignis wartet, MediaKeys jedoch anzeigt, dass sie das ausgewählte Format/Codec nicht verarbeiten kann, kann es zu spät für den Wechsel sein, ohne die Wiedergabe zu unterbrechen.
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 Lizenzserver-URL 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. Sie stellt eine CDM-Instanz dar und bietet Zugriff auf das 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.
Das CDM entschlüsselt das Medium mithilfe der Schlüssel in der Lizenz. Es kann ein gültiger Schlüssel aus einer beliebigen Sitzung innerhalb der mit dem Medienelement verknüpften MediaKeys verwendet werden. Das CDM greift auf den Schlüssel und die Richtlinie zu, indexiert nach Schlüssel-ID.
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.
Beachten Sie, dass mehrere Nachrichten zwischen dem CDM und dem Lizenzserver vorliegen können und die gesamte Kommunikation bei diesem Vorgang für den Browser und die Anwendung intransparent ist: Nachrichten können nur vom CDM und vom Lizenzserver gelesen werden, die Anwendungsebene kann jedoch sehen, welche Art von Nachricht vom CDM gesendet wird. Die Lizenzanfrage enthält einen Nachweis der Gültigkeit (und Vertrauensstellung) des CDM sowie einen Schlüssel für die Verschlüsselung der Inhaltsschlüssel in der resultierenden Lizenz.
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. Ein CDM kann sowohl die Dekodierung (Dekomprimierung) von Medien als auch die Entschlüsselung übernehmen. Es gibt mehrere mögliche Optionen für die CDM-Funktionalität:
- 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 Decodierung, 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 eine CDM mit dem Browser zusammen.
- CDM separat bereitstellen
- Ein CDM im 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 Überprü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')
);
}
Allgemeine Verschlüsselung
Mit gängigen Verschlüsselungslösungen können Contentanbieter ihre Inhalte einmal pro Container/Codec verschlüsseln und verpacken und mit einer Vielzahl von Schlüsselsystemen, CDMs und Clients verwenden, d. h. jedem CDM, das Common Encryption 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.
Schlüssel löschen
Obwohl EME die DRM-Funktionalität nicht definiert, müssen gemäß der Spezifikation derzeit alle Browser, die EME unterstützen, den Löschschlüssel implementieren. 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 in allen Browsern interoperabel, 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 zur Verwendung mit Clear Key kann für WebM gemäß der webm_crypt-Anleitung erfolgen. Kommerzielle Dienste sind ebenfalls verfügbar (zumindest für ISO BMFF/MP4) und es werden weitere Lösungen entwickelt.
Ähnliche Technologie 1: Media Source Extensions (MSE)
Das HTMLMediaElement ist ein Geschöpf von einfacher Schönheit.
Wir können Medien einfach durch Angabe einer src-URL laden, decodieren und abspielen:
<video src="foo.webm"></video>
Die Media Source API ist eine Erweiterung von HTMLMediaElement, die eine detailliertere Steuerung der Medienquelle ermöglicht, da mit JavaScript Streams zur Wiedergabe aus Video-Chunks erstellt werden können. 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 würden Videoblöcke über AJAX abgerufen werden.
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-Leitfaden.
Ä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 Anbieter von Inhalten 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 Inhaltsübermittlung mit dem Vorteil von HTTP, ohne die Nachteile eines herkömmlichen Streamingservers.
Die BBC bietet Teststreams mit DASH an:
Das Medium wird mehrmals und mit unterschiedlichen Bitraten codiert. Jede Codierung wird als Darstellung bezeichnet. Diese sind in mehrere Mediensegmente unterteilt. Der Client spielt ein Programm ab, indem er Segmente in der richtigen Reihenfolge aus einer Darstellung ü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. Inhalte sind so codiert, dass der Wechsel für den Client einfach ist. Zusätzlich zu einer Reihe von Mediensegmenten verfügt eine Darstellung im Allgemeinen auch über 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 Dateien mit unterschiedlichen Bitraten 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 Medienpräsentationsbeschreibung (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. Die Verwendung von MSE ermöglicht auch das Experimentieren mit alternativen Manifestformaten und Übermittlungsmechanismen, ohne dass Änderungen am Browser erforderlich sind. Der Shaka Player von Google implementiert einen DASH-Client mit EME-Unterstützung.
In Mozilla Developer Network finden Sie eine Anleitung zur Verwendung von WebM-Tools und FFmpeg, um Videos zu segmentieren und eine MPD-Datei zu erstellen.
Fazit
Die Nutzung des Internets zur Bereitstellung kostenpflichtiger Video- und Audioinhalte nimmt stark zu. Anscheinend kann jedes neue Gerät, egal ob Tablet, Spielekonsole, internetfähiger Fernseher oder Set-Top-Box, Medien der großen Contentanbieter über HTTP streamen. Ü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 die Verteilung geschützter Inhalte wahrscheinlich immer wichtiger, da die Browseranbieter die Unterstützung für APIs einschränken, auf die die meisten Medien-Plug-ins zurückgreifen.
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