Rozszerzenia szyfrowanych multimediów udostępniają 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/kluczy jest kontrolowana przez aplikację, co ułatwia tworzenie niezawodnych aplikacji do odtwarzania, które obsługują różne technologie szyfrowania i ochrony treści.
Ta specyfikacja nie definiuje systemu ochrony treści ani systemu zarządzania prawami cyfrowymi. Zamiast tego definiuje on interfejs API, który może służyć do wykrywania, wybierania i interakcji z takimi systemami, a także z prostszymi systemami szyfrowania treści. Aby spełniać wymagania tej specyfikacji, nie trzeba stosować 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 systemów kluczy, z wyjątkiem Clear Key (więcej informacji na ten temat znajdziesz poniżej).
- Moduł odszyfrowywania treści (CDM): oprogramowanie lub sprzętowy mechanizm po stronie klienta umożliwiający 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.
Zalecamy najpierw wynegocjowanie kluczy MediaKeys, używając funkcji MediaKeysSystemAccess.getConfiguration(), aby uzyskać informacje o wynegocjowanej konfiguracji.
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 określenia, czy treści są zaszyfrowane, czy nie. W praktyce jest to jednak 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 uruchamia 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 potem 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 dostępne do odszyfrowywania multimediów dla elementu 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 sesję MediaKey, wywołując createSession() na interfejsie MediaKeys. Spowoduje to utworzenie sesji klucza multimedialnego, która reprezentuje czas trwania licencji i jej kluczy.
Aplikacja generuje żądanie licencji, przekazując dane multimediów uzyskane w zaszyfrowanym obsłudze do CDM, wywołując metodę generateRequest() w MediaKeySession.
CDM uruchamia zdarzenie wiadomości: żą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 za pomocą metody update() sesji 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 media. 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óry będzie w formacie takim jak 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ć wysyłanych wiele wiadomości, a cała komunikacja w ramach tego procesu jest niewidoczna dla przeglądarki i aplikacji: wiadomości są zrozumiałe tylko dla CDM i serwera licencji, chociaż warstwa aplikacji może zobaczyć, jakiego typu wiadomość 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 sama w sobie nie zapewnia sposobu na odszyfrowanie multimediów: udostępnia jedynie interfejs API, który umożliwia aplikacji internetowej interakcję z modułami odszyfrowywania treści.
To, co tak naprawdę robi CDM, nie jest zdefiniowane w specyfikacji EME. 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 deszyfrowanie, umożliwiające odtwarzanie za pomocą normalnego kanału 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);
CDM można udostępnić aplikacji internetowej na kilka sposobów:
- Dołącz CDM do przeglądarki.
- rozpowszechniać CDM osobno;
- Wbudowanie CDM w system operacyjny.
- Dołącz CDM do oprogramowania układowego.
- umieszczać CDM w sprzęcie;
Specyfikacja EME nie określa sposobu udostępniania CDM, ale w każdym przypadku przeglądarka jest odpowiedzialna za weryfikację i udostępnianie CDM.
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 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
Rozwiązania wspólnego szyfrowania umożliwiają dostawcom treści szyfrowanie i pakowanie treści raz na kontener lub kodek oraz korzystanie z nich z różnymi systemami kluczy, CDM i klientami, czyli z dowolnym CDM obsługującym wspólne szyfrowanie. 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 podaniu tego klucza. Clear Key może być wbudowany w przeglądarkę: nie wymaga korzystania z 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 na poziomie elementu i aplikacji korzystających z szyfrowania na poziomie elementu 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 znajdziesz instrukcje dotyczące kodu, które są równoległe do czynności opisanych powyżej, ale 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: Media Source Extensions (MSE)
Element HTMLMediaElement jest przykładem prostego piękna.
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, ponieważ pozwala JavaScriptowi tworzyć strumienie do odtwarzania z „kawałków” filmu. Umożliwia to stosowanie takich technik jak adaptacyjny streaming i przesuwanie w czasie.
Dlaczego MSE jest ważne dla EME? Ponieważ oprócz rozpowszechniania treści chronionych dostawcy treści komercyjnych muszą być w stanie dostosować dostarczanie treści do warunków sieci 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 udostępnianych przez implementację MSE, tak jak w przypadku multimediów udostępnianych za pomocą atrybutu 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 dzielony na 5 kawałków za pomocą interfejsów File API. W wersji produkcyjnej fragmenty filmu byłyby pobierane za pomocą 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. Dynamiczna, adaptacyjna transmisja jest kluczowa w przypadku ograniczeń przepustowości i zmienności w świecie wielu 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. Kilka innych technologii działa w podobny sposób, np. transmisja na żywo przez HTTP (HLS) firmy Apple i płynne przesyłanie danych firmy Microsoft, ale DASH to jedyna metoda strumieniowego przesyłania danych z adaptacyjną szybkością transmisji bitów przez HTTP, która opiera się na otwartym standardzie. Interfejs DASH jest już używany w witrynach takich 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 technologii adaptacyjnej.
DASH spełnia swoje zadania:
- Dynamiczny: reaguje na zmieniające się warunki.
- Adaptacyjna: dostosowuje się, aby zapewnić odpowiednią szybkość transmisji bitów dźwięku lub wideo.
- Streaming: umożliwia przesyłanie strumieniowe i pobieranie.
- HTTP: umożliwia dostarczanie treści z zaletami protokołu HTTP, bez wad tradycyjnego serwera strumieniowego.
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, przesyłając żądania segmentów w kolejności od reprezentacji za pomocą 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óżnymi szybkościami transmisji.
- Pliki o różnych szybkościach transmisji danych są dostępne na serwerze HTTP.
- Aplikacja internetowa klienta wybiera, jaką szybkość transmisji danych ma pobrać i odtworzyć za pomocą DASH.
W ramach procesu podziału filmu na segmenty tworzony jest programowo plik manifestu XML, czyli opis prezentacji multimedialnej (MPD). 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 kod XML został pobrany z pliku .mpd używanego w demo YouTube DASH).
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 JavaScript pozwala na ulepszanie algorytmu adaptacji bez konieczności aktualizowania przeglądarki. Korzystanie z MSE umożliwia też eksperymentowanie z alternatywnymi formatami pliku manifestu i mechanizmami dostarczania bez konieczności wprowadzania zmian w przeglądarce. Odtwarzacz Shaka firmy Google implementuje klienta DASH z obsługą EME.
Mozilla Developer Network zawiera 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ądarki w zakresie dystrybucji treści chronionych będzie zyskiwać na znaczeniu, ponieważ producenci przeglądarek ograniczają obsługę interfejsów API, z których korzysta 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