Was ist EME?

Encrypted Media Extensions bietet eine API, die es Webanwendungen ermöglicht, mit Inhaltsschutzsystemen zu interagieren, um die Wiedergabe von verschlüsselten Audio- und Videoinhalten zu ermöglichen.

EME wurde entwickelt, um die Verwendung derselben Anwendung und verschlüsselten Dateien in jedem Browser unabhängig vom zugrunde liegenden Schutzsystem zu ermöglichen. Ersteres wird durch die standardisierten APIs und Workflows ermöglicht, während Letzteres durch das Konzept der gemeinsamen Verschlüsselung ermöglicht wird.

EME ist eine Erweiterung der HTMLMediaElement-Spezifikation – daher auch der Name. Eine „Erweiterung“ bedeutet, dass die Browserunterstützung für EME optional ist: Wenn ein Browser keine verschlüsselten Medien unterstützt, kann er keine verschlüsselten Medien wiedergeben, aber EME ist für die Einhaltung der HTML-Spezifikationen nicht erforderlich. Aus der EME-Spezifikation:

Dieses Angebot erweitert HTMLMediaElement um APIs, um die Wiedergabe geschützter Inhalte zu steuern.

Die API unterstützt Anwendungsfälle von der einfachen Schlüsselentschlüsselung bis hin zu hochwertigen Videos (sofern eine entsprechende User-Agent-Implementierung erforderlich ist). Der Lizenz- und Schlüsselaustausch wird von der Anwendung gesteuert, was die Entwicklung zuverlässiger Wiedergabeanwendungen ermöglicht, die eine Reihe von Technologien zur Entschlüsselung von Inhalten und zum Schutz von Inhalten unterstützen.

Diese Spezifikation definiert weder ein Inhaltsschutzsystem noch ein System zur Verwaltung digitaler Rechte. Vielmehr wird eine gemeinsame API definiert, die verwendet werden kann, um solche Systeme sowie einfachere Systeme zur Inhaltsverschlüsselung zu finden, auszuwählen und mit ihnen zu interagieren. Die Implementierung der digitalen Rechteverwaltung ist für die Einhaltung dieser Spezifikation nicht erforderlich: Lediglich das Clear-Key-System muss als gemeinsame Grundlage implementiert werden.

Die allgemeine API unterstützt einfache Funktionen zur Inhaltsverschlüsselung, sodass Seitenautoren Anwendungsfunktionen wie Authentifizierung und Autorisierung erhalten. Dies wird dadurch erreicht, dass eine vom Inhaltsschutzsystem spezifische Nachricht von der Seite vermittelt wird, 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 zum Schutz von Inhalten (DRM-Mechanismus). Abgesehen von „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 auch EME keine CDMs, sondern bietet eine Schnittstelle für Anwendungen zur Interaktion mit verfügbaren CDMs.
  • Lizenzserver (Schlüsselserver): interagiert mit einem CDM, um Schlüssel zum Entschlüsseln von Medien bereitzustellen. Die Verhandlung mit dem Lizenzserver liegt in der Verantwortung der Anwendung.
  • Verpackungsdienst:Codiert und verschlüsselt Medien für die Verteilung/Nutzung.

Eine Anwendung, die EME verwendet, interagiert mit einem Lizenzserver, um Schlüssel für die Entschlüsselung abzurufen. Die Nutzeridentität und -authentifizierung sind jedoch nicht Teil von EME. Das Abrufen von Schlüsseln zum Aktivieren der Medienwiedergabe erfolgt (optional) nach der Authentifizierung eines Nutzers. Dienste wie Netflix müssen Nutzer innerhalb ihrer Webanwendung authentifizieren: Wenn sich ein Nutzer in der Anwendung anmeldet, ermittelt die Anwendung die Identität und die Berechtigungen des Nutzers.

Wie funktioniert EME?

So interagieren die Komponenten von EME gemäß dem nachfolgenden Codebeispiel:

Wenn mehrere Formate oder Codecs verfügbar sind, können sowohl MediaSource.isTypeSupported() als auch HTMLMediaElement.canPlayType() verwendet werden, um das richtige auszuwählen. Das 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 aber anzeigt, dass sie das ausgewählte Format/den ausgewählten Codec nicht verarbeiten kann, kann es schon zu spät sein, den Wechsel ohne Unterbrechung der Wiedergabe zu unterbrechen.

Es wird empfohlen, zuerst MediaKeys auszuhandeln und die ausgehandelte Konfiguration mit „MediaKeysSystemAccess.getConfiguration()“ zu ermitteln.

Wenn nur ein Format/Codec zur Auswahl steht, ist getConfiguration() nicht erforderlich. Es ist jedoch besser, zuerst MediaKeys einzurichten. Warten Sie nur dann auf das verschlüsselte Ereignis, wenn nicht festgestellt werden kann, ob der Inhalt verschlüsselt ist. In der Praxis ist das aber eher unwahrscheinlich.

  1. Eine Webanwendung versucht, Audio- oder Videoinhalte mit einem oder mehreren verschlüsselten Streams wiederzugeben.
  2. Der Browser erkennt, dass die Medien verschlüsselt sind (siehe dazu unten), und löst ein verschlüsseltes Ereignis mit Metadaten (initData) aus, die von den Medien zur Verschlüsselung abgerufen wurden.
  3. Die Anwendung verarbeitet das verschlüsselte Ereignis:

    1. Wenn dem Medienelement kein MediaKeys-Objekt zugeordnet wurde, wählen Sie zuerst mithilfe von navigator.requestMediaKeySystemAccess() ein verfügbares Schlüsselsystem aus, 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 Anwendung unabhängig von der Auswahl eines verfügbaren Schlüsselsystems 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, mit denen Schlüssel von einem Lizenzserver abgerufen werden.

    2. Nachdem das MediaKeys-Objekt erstellt wurde, weisen Sie es dem Medienelement zu: setMediaKeys() verknüpft das MediaKeys-Objekt mit einem HTMLMediaElement, sodass dessen Schlüssel während der Wiedergabe, d.h. während der Decodierung, verwendet werden können.

  4. Die Anwendung erstellt eine MediaKeySession durch Aufrufen von createSession() für die MediaKeys. Dadurch wird eine MediaKeySession erstellt, die die Lebensdauer einer Lizenz und ihrer Schlüssel darstellt.

  5. Die Anwendung generiert eine Lizenzanfrage. Dazu werden die im verschlüsselten Handler abgerufenen Mediendaten durch Aufrufen von „generateRequest()“ für die MediaKeySession an das CDM übergeben.

  6. Das CDM löst ein Nachrichtenereignis aus: eine Anfrage zum Abrufen eines Schlüssels von einem Lizenzserver.

  7. Das MediaKeySession-Objekt empfängt das Nachrichtenereignis und die Anwendung sendet eine Nachricht an den Lizenzserver (z. B. über XHR).

  8. Die Anwendung empfängt eine Antwort vom Lizenzserver und übergibt die Daten mithilfe der Methode "update()" der MediaKeySession an das CDM.

  9. Das CDM entschlüsselt die Medien mithilfe der Schlüssel in der Lizenz. Ein gültiger Schlüssel kann in jeder Sitzung innerhalb der mit dem Medienelement verknüpften MediaKeys verwendet werden. Das CDM greift auf den Schlüssel und die Richtlinie zu, die nach Schlüssel-ID indexiert sind.

Die Medienwiedergabe wird fortgesetzt.

Woher weiß der Browser, dass Medien verschlüsselt sind?

Diese Informationen befinden sich in den Metadaten der Mediencontainerdatei in einem Format wie ISO BMFF oder WebM. Für ISO BMFF bedeutet dies Header-Metadaten, das als Schutzschema-Informationsfeld bezeichnet wird. WebM verwendet das Matroska ContentEncryption-Element mit einigen WebM-spezifischen Ergänzungen. Richtlinien sind für jeden Container in einer EME-spezifischen Registry verfügbar.

Beachten Sie, dass sich mehrere Nachrichten zwischen dem CDM und dem Lizenzserver befinden können und die gesamte Kommunikation in diesem Prozess für den Browser und die Anwendung intransparent ist: Nachrichten werden nur vom CDM und vom Lizenzserver gelesen, obwohl die Anwendungsschicht sehen kann, 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, der zum Verschlüsseln der Inhaltsschlüssel in der resultierenden Lizenz verwendet werden muss.

Aber was tun CDMs eigentlich?

Eine EME-Implementierung bietet an sich keine Möglichkeit zum Entschlüsseln von Medien. Sie bietet einer Webanwendung lediglich eine API zur Interaktion mit Modulen zur Inhaltsentschlüsselung.

Was CDMs tatsächlich tun, ist in der EME-Spezifikation nicht definiert. Ein CDM kann sowohl die Decodierung (Dekomprimierung) als auch die Entschlüsselung übernehmen. Es gibt mehrere potenzielle Optionen für CDM-Funktionen (von der am wenigsten bis zum robustesten):

  • Nur Entschlüsselung, wodurch die Wiedergabe über die normale Medienpipeline ermöglicht wird, 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. GPU)

Es gibt mehrere Möglichkeiten, ein CDM für eine Webanwendung verfügbar zu machen:

  • Ein CDM mit dem Browser bündeln
  • Verteilen Sie ein CDM separat.
  • Erstellen Sie ein CDM in das Betriebssystem.
  • Fügen Sie ein CDM in die Firmware ein.
  • Betten Sie ein CDM in die Hardware ein.

Wie ein CDM zur Verfügung gestellt wird, wird in der EME-Spezifikation nicht definiert. In allen Fällen ist jedoch der Browser für die Überprüfung und Offenlegung des CDM verantwortlich.

EME verlangt kein bestimmtes Schlüsselsystem. Unter aktuellen Desktop- und mobilen Browsern unterstützt Chrome Widevine und IE11 unterstützt PlayReady.

Schlüssel von einem Lizenzserver abrufen

Bei einer typischen kommerziellen Nutzung werden Inhalte mit einem Paketdienst oder Tool verschlüsselt und codiert. Sobald die verschlüsselten Medien online verfügbar gemacht werden, kann ein Webclient einen in einer Lizenz enthaltenen Schlüssel von einem Lizenzserver abrufen und damit die Entschlüsselung und Wiedergabe der Inhalte ermöglichen.

Der folgende Code (passend aus den Spezifikationsbeispielen) 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 Inhaltsanbieter ihre Inhalte einmal pro Container/Codec verschlüsseln und verpacken und mit einer Vielzahl von Schlüsselsystemen, CDMs und Clients verwenden, d. h. mit jedem CDM, das Common Encryption unterstützt. Beispielsweise könnte ein mit Playready gepacktes Video in einem Browser mit einem Widevine-CDM abgespielt werden, das einen Schlüssel von einem Widevine-Lizenzserver abruft.

Im Gegensatz dazu funktionieren Legacy-Lösungen nur mit einem vollständigen vertikalen Stack, einschließlich eines einzelnen Clients, der oft auch eine Anwendungslaufzeit enthielt.

Die Common Encryption (CENC) ist ein ISO-Standard, mit dem ein Schutzschema für ISO BMFF definiert wird. Ein ähnliches Konzept gilt für WebM.

Schlüssel löschen

Obwohl EME keine DRM-Funktion definiert, schreibt die Spezifikation derzeit vor, dass alle Browser, die EME unterstützen, die Funktion „Clear Key“ implementieren müssen. Mit diesem System können Medien mit einem Schlüssel verschlüsselt und dann einfach durch Bereitstellung dieses Schlüssels wiedergegeben werden. Der Löschschlüssel 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 in allen Browsern, die EME unterstützen, vollständig interoperabel. Es ist auch praktisch, um EME-Implementierungen und Anwendungen mit EME zu testen, ohne einen Inhaltsschlüssel von einem Lizenzserver anfordern zu müssen. Unter simpl.info/ck finden Sie ein einfaches Beispiel für einen Löschschlüssel (Clear Key). Im Folgenden finden Sie eine Schritt-für-Schritt-Anleitung des Codes, die den oben beschriebenen Schritten entspricht, allerdings 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],
    }),
  );
}

Zum Testen dieses Codes benötigen Sie ein verschlüsseltes Video zur Wiedergabe. Die Verschlüsselung eines Videos für die Verwendung mit einem Klarschlüssel kann für WebM gemäß der Anleitung für webm_crypt erfolgen. Es sind auch kommerzielle Dienstleistungen verfügbar (mindestens für ISO BMFF/MP4) und weitere Lösungen werden entwickelt.

Das HTMLMediaElement ist einfach schön.

Medien können einfach geladen, decodiert und wiedergegeben werden, indem eine src-URL angegeben wird:

<video src="foo.webm"></video>

Die Media Source API ist eine Erweiterung von HTMLMediaElement, mit der sich die Quelle von Medien genauer steuern lässt, indem JavaScript ermöglicht wird, Streams für die Wiedergabe aus Videoblöcken zu erstellen. Dies ermöglicht wiederum Techniken wie adaptives Streaming und Zeitverschiebung.

Warum ist MSE für EME wichtig? Denn neben der Verbreitung geschützter Inhalte müssen kommerzielle Inhaltsanbieter in der Lage sein, die Inhaltsübermittlung an die Netzwerkbedingungen und andere Anforderungen anzupassen. Netflix ändert zum Beispiel die Stream-Bitrate 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 verschiedenen Bitraten codiert sind, aufschlüsseln und wiedergeben? Weitere Informationen finden Sie im Abschnitt zu DASH unten.

Sie können MSE unter simpl.info/mse in Aktion sehen. In diesem Beispiel wird ein WebM-Video mithilfe der File APIs in fünf Blöcke unterteilt. In einer Produktionsanwendung würden Videoblöcke ü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 jeden Block mit der Methode „attachBuffer()“ 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 in der MSE-Primer.

Geräteübergreifend, plattformübergreifend und Mobilgeräte – wie auch immer Sie es nennen – das Web wird oft unter den Bedingungen einer wechselbaren Konnektivität genutzt. Die dynamische, adaptive Bereitstellung ist entscheidend, um mit Bandbreitenbeschränkungen und Schwankungen in der Welt für mehrere Geräte umgehen zu können.

DASH (oder MPEG-DASH) wurde entwickelt, um in einer unzuverlässigen Welt die bestmögliche Medienübermittlung sowohl für Streaming als auch für Downloads zu ermöglichen. Verschiedene andere Technologien funktionieren ähnlich, beispielsweise HTTP Live Streaming (HLS) von Apple und Smooth Streaming von Microsoft. DASH ist jedoch die einzige Methode für das adaptive Bitratenstreaming über HTTP, das 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 mithilfe der vorhandenen HTTP-Infrastruktur ein Manifest parsen, Videosegmente mit einer geeigneten Bitrate herunterladen und bei Bedarf in ein Videoelement einspeisen.

Mit anderen Worten: DASH ermöglicht Anbietern von kommerziellen Inhalten das adaptive Streaming von geschützten Inhalten.

DASH hält, was auf der Dose steht:

  • Dynamisch:reagiert auf sich ändernde Bedingungen
  • Adaptiv:Passt sich an die entsprechende Audio- oder Video-Bitrate an.
  • Streaming:Nutzer können Inhalte streamen und herunterladen.
  • HTTP: ermöglicht die Inhaltsübermittlung mit dem Vorteil von HTTP ohne die Nachteile eines herkömmlichen Streaming-Servers.

Die BBC hat damit begonnen, Teststreams mit DASH anzubieten:

Das Medium wird mehrfach mit unterschiedlichen Bitraten codiert. Jede Codierung wird als Repräsentation bezeichnet. Diese sind in mehrere Mediensegmente unterteilt. Der Client spielt ein Programm ab, indem er Segmente der Reihe nach aus einer Darstellung über HTTP anfordert. Darstellungen können in Anpassungs-Sets von Darstellungen mit entsprechendem Inhalt gruppiert werden. Wenn der Client die Bitrate ändern möchte, kann er eine Alternative aus dem aktuellen Anpassungssatz auswählen und damit beginnen, Segmente von dieser Darstellung anzufordern. Der Inhalt ist so codiert, dass der Wechsel für den Client einfach ist. Neben einer Reihe von Mediensegmenten verfügt eine Darstellung in der Regel auch über ein Initialisierungssegment. Sie können sich dies als Header vorstellen, der Informationen zur Codierung, Frame-Größen usw. enthält. Ein Client muss diese für eine bestimmte Darstellung abrufen, bevor er Mediensegmente aus dieser Darstellung verwendet.

Zusammenfassung:

  1. Medien werden mit verschiedenen Bitraten codiert.
  2. Die Dateien mit den verschiedenen Bitraten werden von einem HTTP-Server zur Verfügung gestellt.
  3. Eine Client-Webanwendung wählt mithilfe von DASH die Bitrate aus, die 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 Anpassungssätze und Darstellungen mit Dauer und URLs beschrieben. Eine MPD-Datei 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>

Die XML-Datei stammt aus der MPD-Datei, die für den DASH-Demoplayer von YouTube verwendet wird.

Gemäß der DASH-Spezifikation könnte eine MPD-Datei theoretisch als Quelle für ein Video verwendet werden. Um Webentwicklern mehr Flexibilität zu geben, haben sich Browseranbieter jedoch dafür entschieden, die DASH-Unterstützung stattdessen bei JavaScript-Bibliotheken mit MSE wie dash.js zu überlassen. Durch die Implementierung von DASH in JavaScript kann der Anpassungsalgorithmus weiterentwickelt werden, ohne dass Browserupdates erforderlich sind. Mit MSE können auch alternative Manifestformate und Übermittlungsmechanismen getestet werden, 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 Anleitungen zur Verwendung von WebM-Tools und FFmpeg zum Segmentieren von Videos und Erstellen einer MPD-Datei.

Fazit

Die Nutzung des Internets zur Bereitstellung kostenpflichtiger Video- und Audioinhalte nimmt stark zu. Es scheint, dass jedes neue Gerät, ob Tablet, Spielekonsole, internetfähiger Fernseher oder Set-Top-Box, Medien von den großen Inhaltsanbietern über HTTP streamen kann. Mehr als 85 % mobiler und Desktop-Browser unterstützen <video> und <audio> inzwischen. Cisco schätzt, dass bis 2017 80 bis 90 % des weltweiten Internettraffics von Nutzern aussehen werden. In diesem Kontext wird die Browserunterstützung für die Verbreitung geschützter Inhalte wahrscheinlich an Bedeutung gewinnen, 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 Entwurf des Editors Common Encryption (CENC) Medienquellenerweiterungen: aktueller Entwurf des Editors DASH-Standard (Ja, PDF-Datei) DASH-Standard – Übersicht

Artikel

DTG-Webinar (teilweise obsolete) What is EME? von Henri Sivonen Primer für Media Source Extensions MPEG-DASH Test Streams: BBC R&D Blog post

Demos

Clear Key Demo: simpl.info/ck Demo für Media Source Extensions (MSE) Der Shaka Player von Google implementiert einen DASH-Client mit EME-Unterstützung

Feedback