Co to jest EME?

[Imię i nazwisko]

Rozszerzenia zaszyfrowanych multimediów udostępniają interfejs API, który umożliwia aplikacjom internetowym interakcję z systemami ochrony treści w celu odtwarzania zaszyfrowanych plików audio i wideo.

EME zostało zaprojektowane tak, aby umożliwić korzystanie z tej samej aplikacji i zaszyfrowanych plików w dowolnej przeglądarce, niezależnie od używanego systemu ochrony. Pierwszy z nich jest realizowany dzięki standardowym interfejsom API i przepływowi, natomiast drugi – Common Encryption.

EME jest rozszerzeniem specyfikacji HTMLMediaElement – stąd nazwa. Określenie „rozszerzenia” oznacza, że obsługa EME przez przeglądarkę jest opcjonalna: jeśli przeglądarka nie obsługuje zaszyfrowanych multimediów, nie będzie mogła odtwarzać zaszyfrowanych multimediów, ale kod EME nie jest wymagany ze względu na zgodność ze specyfikacją HTML. Ze specyfikacji EME:

Ta oferta rozszerza HTMLMediaElement o interfejsy API umożliwiające kontrolowanie odtwarzania treści chronionych.

Interfejs API obsługuje przypadki użycia od prostego odszyfrowywania jasnego klucza po wideo o wysokiej wartości (pod warunkiem 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 odszyfrowywania i ochrony treści.

Ta specyfikacja nie definiuje systemu ochrony treści ani systemu zarządzania prawami cyfrowymi. Definiuje natomiast wspólny interfejs API, który może być używany do wykrywania, wybierania i interakcji z takimi systemami, a także prostszych systemów szyfrowania treści. Wdrożenie zarządzania prawami cyfrowymi nie jest wymagane do zapewnienia zgodności z tą specyfikacją. Jako typową podstawę trzeba wdrożyć tylko system Clear Key.

Wspólny interfejs API obsługuje prosty zestaw funkcji szyfrowania treści, z pominięciem funkcji aplikacji, takich jak uwierzytelnianie i autoryzacja, dostęp do autorów stron. Jest to możliwe dzięki temu, że strona musi pośredniczyć w wiadomościach specyficznych dla systemu ochrony treści. Nie zakłada to przerwanej komunikacji między systemem szyfrowania a licencją lub innym serwerem.

Implementacje EME wykorzystują te komponenty zewnętrzne:

  • System kluczy: mechanizm ochrony treści (DRM). EME nie definiuje samych systemów kluczy z wyjątkiem funkcji Clear Key (więcej informacji na ten temat znajdziesz poniżej).
  • Moduł odszyfrowywania treści (CDM): program po stronie klienta lub mechanizm sprzętowy, który umożliwia odtwarzanie zaszyfrowanych multimediów. Podobnie jak w przypadku systemów kluczy, EME nie definiuje żadnych systemów CDM, ale udostępnia interfejs umożliwiający aplikacjom interakcję z dostępnymi systemami CDM.
  • Serwer licencji (klucz): współpracuje z CDM, aby dostarczać klucze do odszyfrowywania multimediów. Za negocjacje z serwerem licencji odpowiada aplikacja.
  • Usługa pakowania: koduje i szyfruje multimedia na potrzeby dystrybucji i używania.

Pamiętaj, że aplikacja korzystająca z EME współpracuje z serwerem licencji, aby uzyskać klucze umożliwiające odszyfrowywanie, ale tożsamość i uwierzytelnianie użytkowników nie są częścią EME. Pobranie kluczy potrzebnych do odtwarzania multimediów ma miejsce po (opcjonalnie) uwierzytelnieniu użytkownika. Usługi takie jak Netflix muszą uwierzytelniać użytkowników w ich aplikacjach internetowych: gdy użytkownik loguje się w aplikacji, aplikacja określa jego tożsamość i uprawnienia.

Jak działa EME?

Interakcje między komponentami EME odpowiadają przykładowemu kodowi poniżej:

Jeśli dostępnych jest wiele formatów lub kodeków, do wyboru odpowiedniego elementu możesz użyć obydwu formatów lub kodeków MediaSource.isTypeSupported() lub HTMLMediaElement.canPlayType(). CDM może jednak obsługiwać tylko niektóre funkcje, które przeglądarka obsługuje w przypadku niezaszyfrowanych treści. Przed wybraniem formatu i kodeka najlepiej wynegocjować konfigurację MediaKeys. Jeśli aplikacja czeka na zaszyfrowane zdarzenie, ale MediaKeys pokazuje, że nie obsługuje wybranego formatu/kodeku, być może za późno, aby przełączyć się bez przerywania odtwarzania.

Zalecanym przepływem jest najpierw negocjowanie MediaKeys za pomocą MediaKeysSystemAccess.getConfiguration() w celu znalezienia wynegocjowanej konfiguracji.

Jeśli do wyboru jest tylko jeden format/kodek, nie jest potrzebna metoda getConfiguration(). Jednak nadal lepiej jest najpierw skonfigurować MediaKeys. Zaczekaj na zaszyfrowane zdarzenie tylko wtedy, gdy nie można sprawdzić, czy treść jest zaszyfrowana, czy nie, ale w praktyce jest to mało prawdopodobne.

  1. Aplikacja internetowa próbuje odtworzyć dźwięk lub film, który ma co najmniej jeden zaszyfrowany strumień.
  2. Przeglądarka rozpoznaje, że multimedia są zaszyfrowane (szczegóły znajdziesz w polu poniżej) i uruchamia zaszyfrowane zdarzenie z metadanymi (initData) uzyskanymi z multimediów dotyczących szyfrowania.

  3. Aplikacja obsługuje zaszyfrowane zdarzenie:

    1. Jeśli z elementem multimedialnym nie został powiązany żaden obiekt MediaKeys, najpierw wybierz dostępny system kluczy za pomocą funkcji navigator.requestMediaKeySystemAccess(), aby sprawdzić dostępne systemy kluczy, a następnie utwórz obiekt MediaKeys dla dostępnego systemu kluczy za pomocą obiektu MediaKeySystemAccess. Pamiętaj, że inicjowanie obiektu MediaKeys powinno nastąpić przed pierwszym zaszyfrowanym zdarzeniem. Aplikacja uzyskuje adres URL serwera licencji niezależnie od tego, jaki jest dostępny system kluczy. Obiekt MediaKeys reprezentuje wszystkie klucze dostępne do odszyfrowywania multimediów dla elementu audio lub wideo. Reprezentuje instancję CDM i zapewnia dostęp do CDM, w szczególności na potrzeby tworzenia sesji kluczy, które służą do uzyskiwania kluczy z serwera licencji.

    2. Po utworzeniu obiektu MediaKeys przypisz go do elementu media: funkcja setMediaKeys() łączy obiekt MediaKeys z obiektem HTMLMediaElement, dzięki czemu jego kluczy można używać podczas odtwarzania, tj. dekodowania.

  4. Aplikacja tworzy obiekt MediaKeySession przez wywołanie metody createSession() w kluczu MediaKeys. Spowoduje to utworzenie sesji MediaKeySession, która odzwierciedla czas trwania licencji i jej klucze.

  5. Aplikacja generuje żądanie licencji, przekazując do CDM dane multimedialne uzyskane w zaszyfrowanym module obsługi przez wywołanie metody generateRequest() w ramach MediaKeySession.

  6. CDM uruchamia zdarzenie komunikatu: żądanie pozyskania klucza z serwera licencji.

  7. Obiekt MediaKeySession otrzymuje zdarzenie komunikatu, a aplikacja wysyła wiadomość do serwera licencji (np. za pomocą XHR).

  8. Aplikacja otrzymuje odpowiedź od serwera licencji i przekazuje dane do CDM przy użyciu metody update() obiektu MediaKeySession.

  9. CDM odszyfrowuje multimedia przy użyciu kluczy zawartych w licencji. Można użyć prawidłowego klucza z dowolnej sesji w ramach elementów MediaKey powiązanych z elementem multimedialnym. CDM uzyska dostęp do klucza i zasady, które są indeksowane według identyfikatora klucza.

Odtwarzanie multimediów zostanie wznowione.

Skąd przeglądarka wie, że multimedia są szyfrowane?

Te informacje znajdują się w metadanych kontenera multimediów, które są w formacie ISO BMFF lub WebM. Dla ISO BMFF oznacza to metadane nagłówka, nazywane polem informacji o schemacie zabezpieczeń. WebM używa elementu Matroska ContentEncryption z dodatkami specyficznymi dla tej platformy. Dla każdego kontenera w rejestrze EME dostępne są wytyczne.

Pamiętaj, że między CDM a serwerem licencji może być przesyłane wiele wiadomości, a cała komunikacja w tym procesie jest nieprzejrzysta do przeglądarki i aplikacji: wiadomości są rozumiene tylko przez CDM i serwer licencji, chociaż warstwa aplikacji może zobaczyć typ wiadomości wysyłanych przez CDM. Prośba o licencję zawiera potwierdzenie ważności CDM (i relacji opartej na zaufaniu), a także klucz do szyfrowania kluczy treści w utworzonej licencji.

Ale do czego służą strategie zarządzania relacjami z klientami (CDM)?

Implementacja EME sama w sobie nie umożliwia odszyfrowywania multimediów – udostępnia tylko interfejs API aplikacji internetowej, który wchodzi w interakcję z modułami odszyfrowywania treści.

Specyfikacja EME nie definiuje funkcji CDM. Może ono obsługiwać dekodowanie (dekompresję) multimediów oraz odszyfrowywanie. Istnieje kilka potencjalnych opcji zarządzania relacjami z klientami (CDM):

  • Tylko odszyfrowywanie, co umożliwia odtwarzanie za pomocą zwykłego potoku multimediów, na przykład za pomocą elementu <video>.
  • Odszyfrowywanie i dekodowanie, czyli przekazywanie klatek wideo do przeglądarki w celu renderowania.
  • Odszyfrowywanie i dekodowanie, renderowanie bezpośrednio na sprzęcie (np. w GPU).

Możesz udostępnić CDM dla aplikacji internetowej na kilka sposobów:

  • Połącz CDM z przeglądarką.
  • Rozpowszechniaj CDM oddzielnie.
  • Skompilowanie CDM w systemie operacyjnym.
  • Dołącz CDM do oprogramowania układowego.
  • umieszczanie CDM na sprzęcie;

Sposób udostępniania CDM nie jest zdefiniowany w specyfikacji EME, ale we wszystkich przypadkach za weryfikację i udostępnienie CDM odpowiada przeglądarka.

EME nie wymaga określonego systemu kluczy. Wśród obecnych przeglądarek na komputerach i urządzeniach mobilnych Chrome obsługuje Widevine, a IE11 – PlayReady.

Uzyskiwanie klucza z serwera licencji

W typowym użyciu komercyjnego treść jest szyfrowana i kodowana przy użyciu usługi opakowania lub narzędzia. Po udostępnieniu zaszyfrowanych multimediów 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 (dostosowany na podstawie 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')
      );
    }

Typowe szyfrowanie

Popularne rozwiązania w zakresie szyfrowania pozwalają dostawcom treści zaszyfrować i zapakować zawartość raz na kontener/kodek oraz używać jej z różnymi systemami kluczy, CDM i klientami, czyli z dowolnym CDM obsługującym Common Encryption. Na przykład film spakowany z użyciem Playready można odtworzyć w przeglądarce za pomocą dysku CDM typu Widevine, który uzyskał klucz z serwera licencji Widevine.

W przeciwieństwie do starszych rozwiązań, które działałyby tylko w pełnym stosie branżowym, w tym z jednym klientem, który często zawierał również środowisko wykonawcze aplikacji.

Common Encryption (CENC) to standard ISO definiujący schemat zabezpieczeń dla standardu ISO BMFF. Podobna koncepcja dotyczy WebM.

Wyczyść klucz

Chociaż EME nie definiuje funkcji DRM, obecnie zgodnie z specyfikacją wszystkie przeglądarki obsługujące EME muszą wdrożyć klarowny klucz. Za pomocą tego systemu można szyfrować multimedia za pomocą klucza, a potem odtwarzać treści za jego pomocą. Klucz Clear Key można wbudować w przeglądarkę: nie wymaga użycia osobnego modułu odszyfrowywania.

Chociaż klucz Clear Key nie jest używany w przypadku wielu typów treści komercyjnych, jest w pełni zintegrowany ze wszystkimi przeglądarkami obsługującymi EME. Jest on również przydatny do testowania implementacji EME i aplikacji używających EME bez konieczności żądania klucza treści z serwera licencji. Prosty przykład klucza Clear Key znajdziesz na simpl.info/ck. Poniżej znajdziesz prezentację kodu, która jest równoległa do kroków opisanych powyżej, ale nie wymaga 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 mieć zaszyfrowany film do odtworzenia. Film można zaszyfrować w celu użycia za pomocą funkcji Clear Key w przypadku WebM, zgodnie z instrukcjami dotyczącymi webm_crypt. Dostępne są również usługi komercyjne (co najmniej dla standardu ISO BMFF/MP4) i projektowane są inne rozwiązania.

HTMLMediaElement to stworzenie prostego piękna.

Możemy ładować, dekodować i odtwarzać multimedia, podając tylko adres URL źródła:

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

Interfejs API Media Source jest rozszerzeniem HTMLMediaElementu, które umożliwia dokładniejszą kontrolę nad źródłem multimediów, umożliwiając JavaScript tworzenie strumieni odtwarzanych z „fragmentów” filmu. To z kolei umożliwia użycie takich technik jak adaptacyjne przesyłanie strumieniowe i przesuwanie czasu.

Dlaczego MSE jest ważne dla EME? Oprócz dystrybucji treści chronionych należy mieć możliwość dostosowania dostawy treści do warunków sieciowych i innych wymagań. Na przykład Netflix dynamicznie zmienia szybkość transmisji strumieniowej, gdy zmienią się warunki sieciowe. EME działa z odtwarzaniem strumieni multimediów dostarczanych przez implementację MSE, tak jak w przypadku multimediów dostarczanych za pomocą atrybutu src.

Jak podzielić na fragmenty i odtworzyć multimedia zakodowane z różnymi szybkościami transmisji bitów? Zapoznaj się z sekcją DASH poniżej.

Działanie MSE można zobaczyć na stronie simpl.info/mse. Na potrzeby tego przykładu film WebM jest podzielony na 5 fragmentów za pomocą interfejsów API plików. W aplikacji produkcyjnej fragmenty filmów są pobierane za pomocą technologii AJAX.

Najpierw tworzony jest element SourceBuffer:

var sourceBuffer = mediaSource.addSourceBuffer(
  'video/webm; codecs="vorbis,vp8"',
);

Cały film jest następnie „przesyłany strumieniowo” do elementu wideo przez dołączanie do niego poszczególnych fragmentów przy użyciu metody addBuffer():

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 na temat MSE znajdziesz w przewodniku po MSE.

Wiele urządzeń, wiele platform, mobilne – jak to się nazywa, internet często funkcjonuje w zmiennych warunkach połączenia. Dynamiczne i adaptacyjne dostarczanie ma kluczowe znaczenie w przypadku ograniczeń przepustowości i zmienności na różnych urządzeniach.

DASH (inaczej MPEG-DASH) to technologia, która umożliwia najlepsze przesyłanie multimediów w niestabilnym świecie zarówno przy strumieniowaniu, jak i pobieraniu. Podobne funkcje są dostępne na przykład w kilku innych technologiach, np. Apple HTTP Live Streaming (HLS) czy Microsoft Smooth Streaming. Jednak DASH to jedyna metoda przesyłania strumieniowego z dostosowaną szybkością transmisji przez HTTP, która opiera się na otwartym standardzie. DASH jest już używany przez witryny takie jak YouTube.

Co ma to wspólnego z EME i MSE? Implementacje DASH oparte na MSE mogą analizować plik manifestu, pobierać segmenty filmu z odpowiednią szybkością transmisji bitów i przekazywać je do elementu wideo, gdy jest głodny, przy użyciu istniejącej infrastruktury HTTP.

Inaczej mówiąc, DASH umożliwia dostawcom treści komercyjnych adaptacyjne strumieniowanie chronionych treści.

DASH działa zgodnie z opisem na puszce:

  • Dynamiczna: reaguje na zmieniające się warunki.
  • Adaptacyjna: dostosowuje szybkość transmisji dźwięku lub obrazu.
  • Przesyłanie strumieniowe: umożliwia zarówno strumieniowanie, jak i pobieranie.
  • HTTP: umożliwia dostarczanie treści za pomocą protokołu HTTP, ale bez wad w przypadku tradycyjnego serwera strumieniowego.

BBC zaczyna udostępniać strumienie testowe za pomocą DASH:

Multimedia są kodowane wielokrotnie z różną szybkością transmisji bitów. Każde kodowanie jest nazywane reprezentacją. Są one podzielone na różne segmenty mediów. Klient uruchamia program, żądając od strony HTTP segmentów (po kolei) z reprezentacji. Reprezentacje można grupować w zestawy adaptacyjne zawierających równoważne treści. Jeśli klient chce zmienić szybkość transmisji bitów, może wybrać alternatywę z bieżącego zestawu adaptacji i zacząć wysyłać żądania segmentów z tej reprezentacji. Treści są kodowane w taki sposób, aby ułatwić klientowi wykonanie tej czynności. Oprócz wielu segmentów multimediów reprezentacja zwykle zawiera też segment inicjowania. Można go potraktować jako nagłówek zawierający informacje o kodowaniu, rozmiarach klatek itp. Klient musi uzyskać te informacje na potrzeby danej reprezentacji, zanim zacznie korzystać z segmentów multimediów z tej prezentacji.

Podsumujmy:

  1. Multimedia są kodowane z różną szybkością transmisji bitów.
  2. Pliki o różnej szybkości transmisji bitów są udostępniane z serwera HTTP.
  3. Aplikacja internetowa klienta wybiera szybkość transmisji bitów do pobrania i odtworzenia za pomocą DASH.

W ramach procesu segmentacji wideo automatycznie powstaje plik manifestu XML, który nosi nazwę Media PresentationDescription (MPD). Opisuje to zestawy i reprezentacje adaptacyjne, czasy trwania i adresy URL. Opis prezentacji multimedialnej (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 w pokazowym odtwarzaczu DASH w YouTube).

Zgodnie ze specyfikacją DASH plik MPD teoretycznie może zostać użyty jako źródło filmu. Aby jednak zapewnić programistom stron internetowych większą elastyczność, dostawcy przeglądarek zdecydowali się pozostawić obsługę DASH w przypadku bibliotek JavaScriptu, które używają MSE, np. dash.js. Implementacja DASH w JavaScript umożliwia algorytm adaptacyjny ewoluowanie bez konieczności aktualizowania przeglądarki. Używanie MSE umożliwia też eksperymentowanie z alternatywnymi formatami pliku manifestu i mechanizmami przesyłania bez konieczności wprowadzania zmian w przeglądarce. Shaka Player Google implementuje klienta DASH z obsługą EME.

Mozilla Developer Network zawiera instrukcje dotyczące używania narzędzi WebM i FFmpeg do segmentowania filmów i tworzenia MPD.

Podsumowanie

Wykorzystanie internetu do realizowania płatnych treści wideo i audio rośnie w ogromnym tempie. Wygląda na to, że każde nowe urządzenie, takie jak tablet, konsola do gier, telewizor Smart TV czy dekoder, może przesyłać strumieniowo treści multimedialne przez protokół HTTP. Ponad 85%przeglądarek mobilnych i na komputerach obsługuje już tagi <video> i <audio>. Według szacunków firmy Cisco do 2017 roku filmy będą stanowić 80–90% globalnego ruchu klientów w internecie. W tym kontekście obsługa rozpowszechniania treści chronionych przez przeglądarki staje się coraz ważniejsza, ponieważ dostawcy przeglądarek ograniczają obsługę interfejsów API, z których korzysta większość wtyczek multimedialnych.

Więcej informacji

Specyfikacje i standardy

Specyfikacja EME: wersja robocza redakcji Common Encryption (CENC) Rozszerzenia źródeł multimediów: wersja robocza redakcji standard DASH (tak, to plik PDF) Omówienie standardu DASH

Artykuły

Webinar na temat DTG (częściowo nieaktualne) Czym jest EME?, autor: Henri Sivonen Materiały dotyczące rozszerzeń źródeł multimediów – prezentacja Strumienie testowe MPEG-DASH: post na blogu BBC R&D

Przykłady

Prezentacja przejrzystego klucza: simpl.info/ck Prezentacja rozszerzeń źródeł multimediów (MSE) Shaka Player od Google wdraża klienta DASH z obsługą EME

Prześlij opinię