Encrypted Media Extensions udostępnia interfejs API, który umożliwia aplikacjom internetowym interakcję z systemami ochrony treści, aby umożliwić odtwarzanie zaszyfrowanych plików audio i wideo.
EME umożliwia korzystanie z tej samej aplikacji i zaszyfrowanych plików w dowolnej przeglądarce, niezależnie od systemu ochrony. Pierwsza opcja jest możliwa dzięki standardowym interfejsom API i standardowemu przepływowi danych, a druga – dzięki koncepcji wspólnego szyfrowania.
EME to rozszerzenie specyfikacji HTMLMediaElement, stąd nazwa. „Rozszerzenie” oznacza, że obsługa szyfrowania multimediów przez przeglądarkę jest opcjonalna: jeśli przeglądarka nie obsługuje szyfrowanych multimediów, nie będzie mogła odtwarzać szyfrowanych multimediów, ale szyfrowanie multimediów nie jest wymagane do zapewnienia zgodności ze specyfikacją HTML. Z specyfikacji EME:
Proponowane rozszerzenie HTMLMediaElement udostępnia interfejsy API do kontrolowania odtwarzania treści chronionych.
Interfejs API obsługuje różne przypadki użycia, od prostego odszyfrowywania klucza do filmów o wysokiej wartości (przy założeniu odpowiedniej implementacji klienta użytkownika). Wymiana licencji i kluczy jest kontrolowana przez aplikację, co ułatwia tworzenie niezawodnych aplikacji do odtwarzania, które obsługują szeroką gamę technologii odszyfrowywania i ochrony treści.
Ta specyfikacja nie definiuje systemu ochrony treści ani systemu zarządzania prawami cyfrowymi. Zamiast tego definiuje wspólny interfejs API, którego można używać do wykrywania takich systemów, wybierania ich i wchodzenia z nimi w interakcje, a także do prostszych systemów szyfrowania treści. Spełnienie tej specyfikacji nie wymaga wdrożenia zarządzania prawami cyfrowymi: jako wspólny standard należy wdrożyć tylko system Clear Key.
Interfejs wspólny API obsługuje prosty zestaw funkcji szyfrowania treści, pozostawiając funkcje aplikacji, takie jak uwierzytelnianie i autoryzacja, autorom stron. Jest to możliwe dzięki wymaganiu, aby wiadomości oparte na systemie ochrony treści były pośredniczone przez stronę, zamiast zakładać komunikację poza pasmem między systemem szyfrowania a licencją lub innym serwerem.
Implementacje EME korzystają z tych komponentów zewnętrznych:
- System kluczy: mechanizm ochrony treści (DRM). EME nie definiuje samych systemów Key Systems poza czystym kluczem (więcej informacji na ten temat znajdziesz poniżej).
- Content Decryption Module (CDM): mechanizm oprogramowania lub sprzętowy po stronie klienta, który umożliwia odtwarzanie zaszyfrowanych multimediów. Podobnie jak w przypadku Key Systems, EME nie definiuje żadnych CDM, ale udostępnia interfejs, który umożliwia aplikacjom interakcję z dostępnymi CDM.
- Serwer licencji (kluczy): komunikuje się z CDM, aby udostępniać klucze do odszyfrowywania multimediów. Negocjacje z serwerem licencji są obowiązkiem aplikacji.
- Usługa pakowania: koduje i szyfruje media na potrzeby dystrybucji i konsumpcji.
Pamiętaj, że aplikacja korzystająca z EME wchodzi w interakcję z serwerem licencji, aby uzyskać klucze umożliwiające odszyfrowywanie, ale tożsamość użytkownika i uwierzytelnianie nie są częścią EME. Pobieranie kluczy umożliwiających odtwarzanie multimediów odbywa się po (opcjonalnym) uwierzytelnieniu użytkownika. Usługi takie jak Netflix muszą uwierzytelniać użytkowników w swojej aplikacji internetowej: gdy użytkownik loguje się w aplikacji, aplikacja określa tożsamość i uprawnienia użytkownika.
Jak działa EME?
Oto jak komponenty EME współdziałają ze sobą w ramach przykładu kodu poniżej:
Jeśli dostępnych jest kilka formatów lub kodeków, do wybrania odpowiedniego można użyć funkcji MediaSource.isTypeSupported() lub HTMLMediaElement.canPlayType(). Jednak CDM może obsługiwać tylko podzbiór funkcji obsługiwanych przez przeglądarkę w przypadku niezaszyfrowanych treści. Konfigurację MediaKeys najlepiej negocjować przed wybraniem formatu i kodeka. Jeśli aplikacja czeka na zaszyfrowane zdarzenie, ale MediaKeys pokazuje, że nie może obsłużyć wybranego formatu lub kodeka, może być za późno na przełączenie bez przerywania odtwarzania.
Zalecane jest, aby najpierw negocjować MediaKeys, używając funkcji MediaKeysSystemAccess.getConfiguration(), aby uzyskać negocjowaną konfigurację.
Jeśli do wyboru jest tylko jeden format lub kodek, nie trzeba używać funkcji getConfiguration(). Wciąż jednak lepiej jest najpierw skonfigurować MediaKeys. Jedynym powodem, dla którego warto czekać na zaszyfrowane zdarzenie, jest brak możliwości sprawdzenia, czy treści są zaszyfrowane, ale w praktyce jest to mało prawdopodobne.
- Aplikacja internetowa próbuje odtworzyć dźwięk lub film zawierający co najmniej 1 zaszyfrowany strumień.
- Przeglądarka rozpoznaje, że treści multimedialne są zaszyfrowane (patrz ramka poniżej), i wywołuje zaszyfrowane zdarzenie z metadanymi (initData) uzyskanymi z treści multimedialnych na temat szyfrowania.
Aplikacja obsługuje zaszyfrowane zdarzenie:
Jeśli z elementem multimedialnym nie jest powiązany żaden obiekt MediaKeys, najpierw wybierz dostępny system kluczy, korzystając z metody navigator.requestMediaKeySystemAccess(), aby sprawdzić, jakie systemy kluczy są dostępne, a następnie utwórz obiekt MediaKeys dla dostępnego systemu kluczy za pomocą obiektu MediaKeySystemAccess. Pamiętaj, że inicjalizacja obiektu MediaKeys powinna nastąpić przed pierwszym zdarzeniem szyfrowania. Pobieranie adresu URL serwera licencji jest wykonywane przez aplikację niezależnie od wyboru dostępnego systemu kluczy. Obiekt MediaKeys reprezentuje wszystkie klucze do odszyfrowywania multimediów w elemencie audio lub wideo. Reprezentuje on instancję CDM i zapewnia dostęp do CDM, w szczególności do tworzenia sesji kluczy, które są używane do uzyskiwania kluczy z serwera licencji.
Po utworzeniu obiektu MediaKeys przypisz go do elementu media: setMediaKeys() łączy obiekt MediaKeys z elementem HTMLMediaElement, aby można było używać jego kluczy podczas odtwarzania, czyli podczas dekodowania.
Aplikacja tworzy MediaKeySession przez wywołanie createSession() w MediaKeys. Spowoduje to utworzenie sesji klucza multimedialnego, która reprezentuje czas trwania licencji i jej kluczy.
Aplikacja generuje żądanie licencji, przekazując do CDM dane multimedialne uzyskane w zaszyfrowanym module obsługi przez wywołanie generateRequest() w MediaKeySession.
CDM uruchamia zdarzenie komunikatu: żądanie uzyskania klucza z serwera licencji.
Obiekt MediaKeySession odbiera zdarzenie wiadomości, a aplikacja wysyła wiadomość do serwera licencji (np. za pomocą XHR).
Aplikacja otrzymuje odpowiedź od serwera licencji i przekazuje dane do CDM przy użyciu metody update() obiektu MediaKeySession.
CDM odszyfrowuje media za pomocą kluczy z licencji. Można użyć prawidłowego klucza z dowolnej sesji w MediaKeys powiązanej z elementem multimedialnym. CDM będzie mieć dostęp do klucza i zasady, indeksowanych za pomocą identyfikatora klucza.
Odtwarzanie multimediów wznowi się.
Skąd przeglądarka wie, że dane multimedialne są zaszyfrowane?
Te informacje znajdują się w metadanych pliku kontenera multimediów, które mają format, np. ISO BMFF lub WebM. W przypadku ISO BMFF oznacza to metadane nagłówka, czyli pole informacji o schemacie ochrony. WebM używa elementu Matroska ContentEncryption z kilkoma dodatkami specyficznymi dla WebM. W przypadku każdego kontenera w rejestrze EME podawane są wytyczne.
Pamiętaj, że między CDM a serwerem licencji może być wiele wiadomości, a cała komunikacja w ramach tego procesu jest nieprzejrzysta dla przeglądarki i aplikacji. Wiadomości są odczytywane tylko przez CDM i serwer licencji, ale warstwa aplikacji widzi, jaki typ wiadomości wysyła CDM. Prośba o licencję zawiera potwierdzenie ważności CDM (i związku zaufania), a także klucz do użycia podczas szyfrowania kluczy treści w wygenerowanej licencji.
Ale do czego służą CDM?
Implementacja EME nie zapewnia samo w sobie sposobu odszyfrowywania multimediów: po prostu udostępnia interfejs API aplikacji internetowej, który umożliwia interakcję z modułami odszyfrowywania treści.
Specyfikacja EME nie definiuje, co dokładnie robi CDM. CDM może obsługiwać dekodowanie (dekompresję) multimediów, a także odszyfrowywanie. W ramach CDM dostępnych jest kilka opcji, od najmniej do najbardziej zaawansowanej:
- tylko odszyfrowywanie, które umożliwia odtwarzanie przez zwykły potok multimediów, np. za pomocą elementu <video>;
- Odszyfrowanie i dekodowanie, przekazywanie ramek wideo do przeglądarki w celu renderowania.
- odszyfrowywanie i dekodowanie, renderowanie bezpośrednio na sprzęcie (np. na karcie graficznej);
Istnieje kilka sposobów udostępnienia CDM aplikacji internetowej:
- Dołącz CDM do przeglądarki.
- rozpowszechniać CDM osobno;
- Zaimplementuj CDM z systemem operacyjnym.
- Umieść CDM w oprogramowaniu.
- umieszczać CDM w sprzęcie;
Metoda udostępniania CDM nie jest określona w specyfikacji EME, ale w każdym przypadku za sprawdzenie i ujawnienie CDM odpowiada przeglądarka.
EME nie wymaga korzystania z określonego systemu kluczy. Wśród obecnych przeglądarek na komputery i urządzenia mobilne Chrome obsługuje Widevine, a Internet Explorer 11 – PlayReady.
Pobieranie klucza z serwera licencji
W przypadku typowego użytku komercyjnego treści są szyfrowane i kodowane za pomocą usługi lub narzędzia do pakowania. Gdy zaszyfrowane media zostaną udostępnione online, klient internetowy może uzyskać klucz (zawarty w licencji) od serwera licencji i użyć go do odszyfrowania i odtworzenia treści.
Poniższy kod (przekształcony z przykładów specyfikacji) pokazuje, jak aplikacja może wybrać odpowiedni system kluczy i uzyskać klucz z serwera licencji.
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')
);
}
Powszechne szyfrowanie
Typowe rozwiązania do szyfrowania umożliwiają dostawcom treści szyfrowanie i pakowanie treści raz na kontener/kodek oraz używanie ich w różnych systemach kluczy, systemach CDM i klientach: to znaczy z dowolnym CDM, który obsługuje Common Encryption. Na przykład film zapakowany przy użyciu Playready może być odtwarzany w przeglądarce przy użyciu CDM Widevine, który pobiera klucz z serwera licencji Widevine.
W przeciwieństwie do starszych rozwiązań, które działają tylko z pełnym pakietem usług, w tym z jednym klientem, który często obejmuje też środowisko uruchomienia aplikacji.
Wspólne szyfrowanie (CENC) to norma ISO, która określa schemat ochrony dla formatu ISO BMFF. Podobna koncepcja dotyczy formatu WebM.
Wyczyść klucz
Chociaż specyfikacja EME nie definiuje funkcji DRM, obecnie wymaga ona, aby wszystkie przeglądarki obsługujące EME implementowały Clear Key. Dzięki temu systemowi treści multimedialne można zaszyfrować za pomocą klucza, a następnie odtwarzać po prostu podając ten klucz. Wbudowany klucz Clear Key nie wymaga używania osobnego modułu odszyfrowywania.
Chociaż nie jest on używany w przypadku wielu rodzajów treści komercyjnych, Clear Key jest w pełni interoperacyjny we wszystkich przeglądarkach, które obsługują EME. Jest ona też przydatna do testowania implementacji szyfrowania EME i aplikacji korzystających z tego rozwiązania bez konieczności wysyłania żądania klucza treści do serwera licencji. Przykład prostego zastosowania Clear Key znajdziesz na stronie simpl.info/ck. Poniżej znajduje się przewodnik po kodzie, który jest równolegle do czynności opisanych powyżej, jednak bez interakcji z serwerem licencji.
// 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],
}),
);
}
Aby przetestować ten kod, musisz odtworzyć zaszyfrowany film. Szyfrowanie filmu do użytku z Clear Key można wykonać w przypadku formatu WebM zgodnie z instrukcjami dotyczącymi webm_crypt. Dostępne są też usługi komercyjne (co najmniej w przypadku ISO BMFF/MP4), a inne rozwiązania są w trakcie opracowywania.
Powiązana technologia 1: rozszerzenia źródła multimediów (MSE)
HTMLMediaElement to stworzenie o prostym pięknie.
Możemy wczytywać, dekodować i odtwarzać multimedia, podając tylko adres URL źródła:
<video src="foo.webm"></video>
Interfejs Media Source API jest rozszerzeniem elementu HTMLMediaElement, który umożliwia bardziej szczegółową kontrolę nad źródłem multimediów. Umożliwia on JavaScriptowi tworzenie strumieni do odtwarzania z „kawałków” filmu. Umożliwia to stosowanie takich technik jak strumieniowanie adaptacyjne i przesuwanie w czasie.
Dlaczego MSE jest ważny dla EME? Ponieważ oprócz dystrybucji treści chronionych prawem dostawcy treści komercyjnych muszą być w stanie dostosować sposób przesyłania treści do warunków sieciowych i innych wymagań. Na przykład Netflix dynamicznie zmienia bitrate strumienia w zależności od warunków sieci. EME działa z odtwarzaniem strumieni multimediów dostarczanych przez implementację MSE, tak samo jak w przypadku multimediów dostarczanych przez atrybut src.
Jak dzielić i odtwarzać media zakodowane z różnymi szybkościami transmisji? Zapoznaj się z sekcją DASH poniżej.
Funkcję MSE możesz zobaczyć na stronie simpl.info/mse. W tym przykładzie film WebM jest podzielony na 5 kawałków za pomocą interfejsów File API. W aplikacji produkcyjnej fragmenty wideo były pobierane za pomocą technologii AJAX.
Najpierw tworzony jest SourceBuffer:
var sourceBuffer = mediaSource.addSourceBuffer(
'video/webm; codecs="vorbis,vp8"',
);
Następnie cały film jest „przesyłany strumieniowo” do elementu wideo przez dołączanie każdego fragmentu za pomocą metody appendBuffer():
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);
}
};
Więcej informacji o MSE znajdziesz w artykule MSE – wprowadzenie.
Powiązana technologia 2. Dynamiczne adaptacyjne strumieniowe przesyłanie danych przez HTTP (DASH)
Wiele urządzeń, wiele platform, mobilne – niezależnie od tego, jak nazywasz internet, często korzystasz z niego w warunkach zmiennej łączności. Dynamiczne, adaptacyjne dostarczanie ma kluczowe znaczenie w przypadku radzenia sobie z ograniczeniami przepustowości i zmiennością przepustowości w świecie, w którym jest wiele urządzeń.
DASH (MPEG-DASH) ma zapewnić najlepszą możliwą jakość przesyłania multimediów w niestabilnym środowisku, zarówno w przypadku strumieniowego przesyłania, jak i pobierania. Podobnie jest w przypadku kilku innych technologii – takich jak HTTP Live Streaming (HLS) firmy Apple i Płynne strumieniowe przesyłanie danych przez Microsoft. Jednak DASH to jedyna metoda strumieniowego przesyłania danych przez HTTP, która opiera się na otwartym standardzie. Interfejs DASH jest już używany przez takie witryny jak YouTube.
Jaki jest związek między EME i MSE? Implementacje DASH oparte na MSE mogą analizować plik manifestu, pobierać segmenty wideo z odpowiednią szybkością transmisji bitów i przekazywać je do elementu wideo, gdy ten zażąda ich – za pomocą istniejącej infrastruktury HTTP.
Innymi słowy, DASH umożliwia dostawcom treści komercyjnych przesyłanie strumieniowe treści chronionych z wykorzystaniem adaptacyjnej transmisji strumieniowej.
DASH robi to, co jest w puszce:
- Dynamiczny: reaguje na zmieniające się warunki.
- Adaptacyjna: dostosowuje się, aby zapewnić odpowiednią szybkość transmisji bitów dźwięku lub wideo.
- Przesyłanie strumieniowe: umożliwia przesyłanie strumieniowe i pobieranie.
- HTTP: umożliwia dostarczanie treści za pomocą protokołu HTTP bez wad tradycyjnego serwera strumieniowego przesyłania danych.
BBC zaczęło testować strumienie korzystające z DASH:
Treści są kodowane kilka razy z różnymi szybkościami transmisji. Każde kodowanie jest nazywane reprezentacją. Są one podzielone na kilka segmentów multimediów. Klient odtwarza program, żądając segmentów w odpowiedniej kolejności do przedstawiciela korzystającego z protokołu HTTP. Reprezentacje mogą być grupowane w zestawy adaptacyjne reprezentacji zawierających równoważne treści. Jeśli klient chce zmienić bitrate, może wybrać alternatywę z bieżącego zestawu adaptacji i zacząć żądać segmentów z tej reprezentacji. Treści są kodowane w taki sposób, aby ułatwić klientowi ich przełączanie. Oprócz kilku segmentów multimedialnych reprezentacja zawiera zazwyczaj również segment inicjalizacji. Można to traktować jako nagłówek zawierający informacje o kodowaniu, rozmiarach klatek itp. Klient musi uzyskać te informacje dla danej reprezentacji przed wykorzystaniem segmentów multimediów z tej reprezentacji.
Podsumowując:
- Multimedia są kodowane z różną szybkością transmisji bitów.
- Pliki o różnej szybkości transmisji bitów są udostępniane z serwera HTTP.
- Aplikacja internetowa klienta wybiera, jaką szybkość transmisji danych ma pobrać i odtworzyć za pomocą DASH.
W ramach procesu segmentacji wideo plik manifestu XML, nazywany opisem Media PresentationDescription (MPD), jest tworzony automatycznie. Zawiera ona zestawy i reprezentacje adaptacyjne wraz z czasem trwania i adresami URL. Plik MPD wygląda tak:
<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>
(Ten plik XML pochodzi z pliku .mpd używanego na potrzeby odtwarzacza demonstracyjnego DASH w YouTube).
Zgodnie ze specyfikacją DASH plik MPD może teoretycznie służyć jako źródło wideo. Jednak aby zapewnić większą elastyczność programistom stron internetowych, dostawcy przeglądarek postanowili pozostawić obsługę DASH w bibliotekach JavaScript korzystających z MSE, takich jak dash.js. Wdrożenie DASH w języku JavaScript pozwala algorytmowi adaptacji rozwijać się bez konieczności aktualizowania przeglądarki. Użycie MSE umożliwia też eksperymentowanie z alternatywnymi formatami plików manifestu i mechanizmami wyświetlania bez konieczności zmiany przeglądarki. Firma Google Shaka Player wdraża klienta DASH z obsługą EME.
W Mozilla Developer Network znajdziesz instrukcje dotyczące używania narzędzi WebM i FFmpeg do dzielenia filmu na segmenty i tworzenia MPD.
Podsumowanie
Korzystanie z internetu do dostarczania płatnych filmów i dźwięku rośnie w bardzo szybkim tempie. Wygląda na to, że każde nowe urządzenie, niezależnie od tego, czy jest to tablet, konsola do gier, telewizor CTV czy dekoder, może przesyłać strumieniowo treści od głównych dostawców treści przez HTTP. Ponad 85% przeglądarek mobilnych i na komputery obsługuje teraz <video> i <audio>. Według szacunków Cisco do 2017 roku wideo będzie stanowić 80–90% globalnego ruchu internetowego konsumentów. W tym kontekście obsługa przeglądarek w przypadku dystrybucji treści chronionych prawdopodobnie nabiera coraz większego znaczenia, ponieważ dostawcy przeglądarek ograniczają obsługę interfejsów API używanych przez większość wtyczek multimedialnych.
Więcej informacji
Specyfikacje i standardy
Specyfikacja EME: najnowsza wersja robocza szyfrowania wspólnego (CENC) Rozszerzenia źródła multimediów: najnowsza wersja robocza standardu DASH (tak, to plik PDF) Przegląd standardu DASH
Artykuły
Webinar DTG (częściowo nieaktualny) Co to jest EME?, Henri Sivonen Media Source Extensions (rozszerzenia źródła multimediów) – wprowadzenie MPEG-DASH Test Streams: post na blogu BBC R&D
Prezentacje
Demonstracja Clear Key: simpl.info/ck Demonstracja rozszerzeń źródła multimediów (MSE) Odtwarzacz Shaka firmy Google implementuje klienta DASH z obsługą EME