Şifrelenmiş Medya Uzantıları, şifrelenmiş ses ve videonun oynatılmasına izin vermek için web uygulamalarının içerik koruma sistemleriyle etkileşimde bulunmasını sağlayan bir API sunar.
EME, temel koruma sisteminden bağımsız olarak aynı uygulamanın ve şifrelenmiş dosyaların tüm tarayıcılarda kullanılabilmesini sağlayacak şekilde tasarlanmıştır. Standartlaştırılmış API'ler ve akış, standartlaştırılmış API'ler ve akış tarafından mümkünken, ikincisi olanaklar Ortak Şifreleme kavramıyla mümkün hale gelir.
EME, HTMLMediaElement spesifikasyonunun bir uzantısıdır. Adından da anlaşılmıştır. "Uzantı" olmak, EME için tarayıcı desteğinin isteğe bağlı olduğu anlamına gelir: Bir tarayıcı şifrelenmiş medyayı desteklemiyorsa şifrelenmiş medya oynatamaz, ancak HTML spesifikasyon uyumluluğu için EME gerekli değildir. EME spesifikasyonundan:
Bu teklif, korunan içeriğin oynatılmasını kontrol etmek için API'ler sağlayan HTMLMediaElement'in kapsamını genişletir.
API, basit ve kolay anlaşılır anahtar şifre çözmeden yüksek değerli videolara (uygun bir kullanıcı aracısı uygulaması ile) kadar çeşitli kullanım alanlarını destekler. Lisans/anahtar değişimi uygulama tarafından denetlenir. Bu sayede, çeşitli içerik şifre çözme ve koruma teknolojilerini destekleyen güvenilir oynatma uygulamalarının geliştirilmesi kolaylaşır.
Bu spesifikasyon bir içerik koruma veya Dijital Haklar Yönetimi sistemini tanımlamaz. Bunun yerine bu tür sistemleri ve daha basit içerik şifreleme sistemlerini keşfetmek, seçmek ve bunlarla etkileşim kurmak için kullanılabilecek ortak bir API tanımlar. Bu spesifikasyona uygunluk için Dijital Hak Yönetimi'nin uygulanması gerekmez. Ortak bir temel olarak yalnızca Açık Anahtar sisteminin uygulanması gerekir.
Ortak API, kimlik doğrulama ve sayfa yazarlarına yetkilendirme gibi uygulama işlevlerini bırakarak basit bir içerik şifreleme özellikleri kümesini destekler. Bunun için, şifreleme sistemi ile lisans veya başka bir sunucu arasında bant dışı iletişimin olduğunu varsaymak yerine, içerik koruma sistemine özgü mesajların sayfa tarafından uyumlulaştırılmasını zorunlu kılar.
EME uygulamalarında aşağıdaki harici bileşenler kullanılır:
- Anahtar Sistemi: İçerik koruma (DRM) mekanizması. EME, Anahtar Sistemler'in kendisini Temizlemez (Bu konuyla ilgili daha fazla bilgiyi aşağıda bulabilirsiniz).
- İçerik Şifre Çözme Modülü (CDM): Şifrelenmiş medyanın oynatılmasını sağlayan istemci tarafı yazılım veya donanım mekanizması. Key Systems'ta olduğu gibi EME de herhangi bir CDM tanımlamaz ancak uygulamaların kullanılabilir CDM'lerle etkileşim kurabileceği bir arayüz sağlar.
- Lisans (Anahtar) sunucusu: Medyanın şifresini çözecek anahtarlar sağlamak için bir CDM ile etkileşim kurar. Lisans sunucusuyla yapılan pazarlık, uygulamanın sorumluluğundadır.
- Paketleme hizmeti: Medyaları dağıtım/tüketim için kodlar ve şifreler.
EME kullanan bir uygulamanın, şifre çözmeyi etkinleştirmek için anahtarları almak üzere lisans sunucusuyla etkileşim kurduğunu ancak kullanıcı kimliği ve kimlik doğrulamasının, EME'nin bir parçası olmadığını unutmayın. Medya oynatmayı etkinleştirmek için anahtarlar, kullanıcının kimliği doğrulandıktan sonra (isteğe bağlı olarak) alınır. Netflix gibi hizmetler, kullanıcıların kimliklerini web uygulamaları içinde doğrulamalıdır: Bir kullanıcı uygulamada oturum açtığında kullanıcının kimliğini ve ayrıcalıkları uygulama tarafından belirlenir.
EME nasıl çalışır?
EME bileşenlerinin, aşağıdaki kod örneğine karşılık gelen nasıl etkileşimde bulundukları aşağıda açıklanmıştır:
Birden fazla biçim veya codec varsa doğru biçimi seçmek için MediaSource.isTypeSupported() ya da HTMLMediaElement.canPlayType() yöntemi kullanılabilir. Ancak CDM, tarayıcının şifrelenmemiş içerik için desteklediğinin yalnızca bir alt kümesini destekleyebilir. Biçim ve codec seçmeden önce bir MediaKeys yapılandırmasını görüşmek en iyisidir. Uygulama şifrelenmiş etkinliği bekler, ancak daha sonra MediaKeys seçilen biçimi/codec'i işleyemediğini gösterirse oynatmayı kesintiye uğratmadan geçiş yapmak için çok geç olabilir.
Önerilen akış, pazarlık yapılan yapılandırmayı bulmak için önce MediaKeysSystemAccess.getConfiguration() işlevini kullanarak MediaKeys üzerinde anlaşmaktır.
Aralarından seçim yapılacak yalnızca bir biçim/codec varsa getConfiguration() gerekmez. Yine de önce MediaKeys'in ayarlanması tercih edilir. Şifrelenmiş etkinliği beklemenizin tek nedeni, içeriğin şifrelenmiş olup olmadığını öğrenmenin mümkün olmamasıdır ancak pratikte bu pek mümkün değildir.
- Bir web uygulaması, bir veya daha fazla şifrelenmiş akışı olan ses veya videoları oynatmaya çalışır.
- Tarayıcı, medyanın şifrelendiğini algılar (bunun nasıl olduğunu öğrenmek için aşağıdaki kutuya bakın) ve şifrelemeyle ilgili medyadan alınan meta verilerle (initData) şifrelenmiş bir etkinlik tetikler.
Uygulama, şifrelenmiş etkinliği işler:
Medya öğesiyle hiçbir MediaKeys nesnesi ilişkilendirilmediyse önce hangi Anahtar Sistemlerinin kullanılabilir olduğunu kontrol etmek için navigator.requestMediaKeySystemAccess() işlevini kullanarak kullanılabilir bir Anahtar Sistemi seçin, ardından bir MediaKeySystemAccess nesnesi aracılığıyla kullanılabilir bir Anahtar Sistemi için MediaKeys nesnesi oluşturun. MediaKeys nesnesinin başlatılmasının, ilk şifrelenmiş etkinlikten önce gerçekleşmesi gerektiğini unutmayın. Uygulama, lisans sunucusu URL'sini mevcut bir anahtar sistemi seçmeden bağımsız olarak alır. MediaKeys nesnesi, bir ses veya video öğesindeki medyanın şifresini çözmek için kullanılabilen tüm anahtarları temsil eder. Bir CDM örneğini temsil eder ve özellikle lisans sunucusundan anahtar almak için kullanılan anahtar oturumları oluşturmak amacıyla CDN'ye erişim sağlar.
MediaKeys nesnesi oluşturulduktan sonra, bu nesneyi medya öğesine atayın: setMediaKeys(), MediaKeys nesnesini bir HTMLMediaElement nesnesiyle ilişkilendirir. Böylece, anahtarların oynatma sırasında, yani kod çözme sırasında kullanılabilmesi için.
Uygulama, MediaKeys'de createSession() yöntemini çağırarak bir MediaKeySession oluşturur. Bu işlem, bir lisansın ve anahtarlarının kullanım ömrünü temsil eden bir MediaKeySession oluşturur.
Uygulama, şifrelenmiş işleyicide elde edilen medya verilerini MediaKeySession'da generateRequest() yöntemini çağırarak CDM'ye geçirerek bir lisans isteği oluşturur.
CDM, bir mesaj etkinliği (bir lisans sunucusundan anahtar alma isteği) tetikler.
MediaKeySession nesnesi, mesaj etkinliğini alır ve uygulama, lisans sunucusuna bir mesaj gönderir (örneğin, XHR aracılığıyla).
Uygulama, lisans sunucusundan bir yanıt alır ve MediaKeySession'ın update() yöntemini kullanarak verileri CDM'ye iletir.
CDM, lisanstaki anahtarları kullanarak medyanın şifresini çözer. Medya öğesiyle ilişkilendirilmiş MediaKeys içindeki herhangi bir oturumda geçerli bir anahtar kullanılabilir. CDM, Anahtar Kimliğine göre dizine eklenen anahtara ve politikaya erişir.
Medya oynatma devam ettiriliyor.
Tarayıcı, medyanın şifrelendiğini nasıl anlar?
Bu bilgiler, ISO BMFF veya WebM gibi bir biçimde olacak medya kapsayıcı dosyasının meta verisinde bulunur. ISO BMFF için bu, koruma şeması bilgi kutusu denen başlık meta verisi anlamına gelir. WebM, WebM'ye özel bazı eklemelerle Matroska ContentEncryption öğesini kullanır. EME'ye özel bir kayıt defterindeki her container için yönergeler sağlanır.
CDM ile lisans sunucusu arasında birden fazla mesaj olabileceğini ve bu süreçteki tüm iletişimin tarayıcı ve uygulama için opak olduğunu unutmayın. Mesajlar yalnızca CDM ve lisans sunucusu tarafından anlaşılsa da uygulama katmanı, ne tür bir mesaj gönderdiğini görebilir. Lisans isteği, CDM'nin geçerliliğine (ve güven ilişkisine) dair kanıtın yanı sıra sonuçta elde edilen lisanstaki içerik anahtarlarını şifrelerken kullanılacak bir anahtar içerir.
Peki, CDM'ler gerçekte ne yapar?
EME uygulaması kendi başına medyaların şifresini çözmek için bir yol sağlamaz, yalnızca bir web uygulamasının İçerik Şifre Çözme Modülleriyle etkileşim kurması için bir API sağlar.
CDM'lerin gerçekte ne yaptığı, EME spesifikasyonu tarafından tanımlanmaz ve bir CDM, medyanın kodunu çözme (sıkıştırma açma) ve şifre çözme işlemlerini gerçekleştirebilir. CDM işlevi için, en az güçlü olandan en güçlü olana doğru birkaç olası seçenek vardır:
- Yalnızca şifre çözme: Normal medya ardışık düzeni kullanılarak (örneğin bir <video> öğesi aracılığıyla) oynatma etkinleştirilir.
- Şifre çözme ve kod çözme, video karelerini oluşturma işlemi için tarayıcıya iletme.
- Şifre çözme ve kod çözme, doğrudan donanımda oluşturma (örneğin, GPU).
Bir CDM'yi bir web uygulaması için kullanılabilir hale getirmenin birden çok yolu vardır:
- Tarayıcıyla bir CDM'yi gruplandırın.
- CDM'yi ayrı olarak dağıtın.
- İşletim sistemine bir CDM ekleyin.
- Donanım yazılımına bir CDM ekleyin.
- Donanıma bir CDM yerleştirin.
Bir CDM'nin nasıl kullanıma sunulduğu, EME spesifikasyonunda tanımlanmamıştır, ancak her durumda CDM'yi incelemek ve kullanıma sunmaktan sorumludur.
EME belirli bir anahtar sistemini zorunlu kılmaz. Mevcut masaüstü ve mobil tarayıcılar arasında Chrome Widevine'i, IE11 ise PlayReady'yi destekler.
Lisans sunucusundan anahtar alma
Tipik ticari kullanımda içerik bir paketleme hizmeti veya aracı kullanılarak şifrelenir ve kodlanır. Şifrelenmiş medya online olarak kullanıma sunulduktan sonra, web istemcisi lisans sunucusundan bir anahtar (lisans içinde yer alır) alabilir ve bu anahtarı içeriğin şifresinin çözülmesini ve oynatılmasını sağlamak için kullanabilir.
Spesifikasyon örneklerinden uyarlanmış aşağıdaki kod, bir uygulamanın nasıl uygun anahtar sistemini seçebileceğini ve lisans sunucusundan nasıl anahtar alabileceğini gösterir.
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')
);
}
Ortak şifreleme
Yaygın Şifreleme çözümleri, içerik sağlayıcıların içeriklerini container/codec başına bir kez şifreleyip paketlemelerini ve bunları çeşitli Anahtar Sistemleri, CDM'ler ve istemciler, yani Ortak Şifrelemeyi destekleyen tüm CDM'lerle kullanmalarını sağlar. Örneğin, Playready kullanılarak paketlenen bir video, Widevine lisans sunucusundan bir anahtar alan Widevine CDM kullanılarak tarayıcıda oynatılabilir.
Bu, genellikle bir uygulama çalışma zamanı içeren tek bir istemci de dahil olmak üzere yalnızca tam bir dikey yığınla çalışan eski çözümlerin tersidir.
Ortak Şifreleme (CENC), ISO BMFF için koruma şemasını tanımlayan bir ISO standardıdır. Benzer bir kavram WebM için de geçerlidir.
Anahtarı Temizle
EME, DRM işlevini tanımlamasa da, spesifikasyon şu anda EME'yi destekleyen tüm tarayıcıların Temizle Anahtarı uygulamasını gerektirmektedir. Bu sistemde medya, bir anahtarla şifrelenebilir ve daha sonra bu anahtarı sağlayarak oynatılabilir. Temizleme Anahtarı tarayıcıya yerleşik olabilir: Ayrı bir şifre çözme modülü kullanılmasını gerektirmez.
Pek çok ticari içerik türünde kullanılmaması muhtemel olsa da Clear Key, EME'yi destekleyen tüm tarayıcılarda tamamen birlikte çalışabilir. Ayrıca, EME uygulamalarını ve EME kullanan uygulamaları, lisans sunucusundan içerik anahtarı istemeye gerek kalmadan test etmek için de kullanışlıdır. simpl.info/ck adresinde basit bir Clear Key örneği bulabilirsiniz. Kodun adım adım açıklamalı kılavuzunu aşağıda bulabilirsiniz. Bu adım, lisans sunucusu etkileşimi olmadan yukarıda açıklanan adımlarla paraleldir.
// 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],
}),
);
}
Bu kodu test etmek için, oynatmak üzere şifrelenmiş bir videonun olması gerekir. Açık Anahtar ile kullanılmak üzere bir videonun şifrelenmesi, WebM için webm_crypt talimatlarına göre yapılabilir. Ticari hizmetler de mevcuttur (en azından ISO BMFF/MP4 için) ve başka çözümler geliştirilmektedir.
İlgili teknoloji 1: Medya Kaynağı Uzantıları (MSE)
HTMLMediaElement, basit güzelliğe sahip bir yaratık.
Yalnızca bir src URL'si sağlayarak medyayı yükleyebilir, kodunu çözebilir ve oynatabiliriz:
<video src="foo.webm"></video>
Media Source API'sı, JavaScript'in video "parçalarından" oynatmak üzere akışlar oluşturmasına izin vererek medya kaynağı üzerinde daha hassas bir denetim sağlayan HTMLMediaElement uzantısıdır. Bu da uyarlanabilir akış ve zaman değiştirme gibi teknikleri mümkün kılar.
MSE, EME için neden önemlidir? Çünkü ticari içerik sağlayıcıları, korunan içeriği dağıtmanın yanı sıra içerik yayınlamayı ağ koşullarına ve diğer gerekliliklere göre uyarlayabilmelidir. Örneğin Netflix, ağ koşulları değiştikçe akış bit hızını dinamik olarak değiştirir. EME, bir MSE uygulaması tarafından sağlanan medya akışlarının oynatılmasıyla, tıpkı bir src özelliği aracılığıyla sağlanan medyada olduğu gibi çalışır.
Farklı bit hızlarında kodlanmış medya nasıl parçalanır ve oynatılır? Aşağıdaki DASH bölümüne bakın.
MSE'yi simpl.info/mse adresinde çalışırken görebilirsiniz. Bu örnekte, bir WebM videosu Dosya API'leri kullanılarak beş bölüme ayrılmıştır. Bir üretim uygulamasında, video parçaları AJAX aracılığıyla alınır.
İlk olarak bir SourceBuffer oluşturulur:
var sourceBuffer = mediaSource.addSourceBuffer(
'video/webm; codecs="vorbis,vp8"',
);
Daha sonra tüm film, ek Buffer() yöntemi kullanılarak her bir parçaya eklenerek bir video öğesine "yayınlanır":
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);
}
};
MSE kılavuzunda MSE hakkında daha fazla bilgi edinin.
İlgili teknoloji 2: HTTP üzerinden Dinamik Adaptif Akış (DASH)
Çoklu cihaz, çok platform, mobil, kısacası ne dediğinize bakılmaksızın web genellikle değişebilen bağlantı koşulları altında deneyimlenir. Dinamik, uyarlanabilir sunum, çok cihazlı dünyada bant genişliği kısıtlamaları ve değişkenliğiyle başa çıkmak açısından çok önemlidir.
DASH (MPEG-DASH olarak da bilinir), hem akış hem de indirme için kesintili bir dünyada mümkün olan en iyi medya yayınını sağlamak üzere tasarlanmıştır. Apple'ın HTTP Canlı Akışı (HLS) ve Microsoft'un Smooth Streaming (Smooth Streaming) hizmetleri gibi başka pek çok teknoloji de benzer bir işleve sahiptir ancak DASH açık standarda dayalı olan HTTP üzerinden uyarlanabilir bit hızı akışı için kullanılan tek yöntemdir. DASH, YouTube gibi siteler tarafından zaten kullanılıyor.
Bunun EME ve MSE ile ilgisi nedir? MSE tabanlı DASH uygulamaları bir manifesti ayrıştırabilir, video segmentlerini uygun bir bit hızında indirebilir ve acıktığında, mevcut HTTP altyapısını kullanarak bunları bir video öğesine besleyebilir.
Başka bir deyişle DASH, ticari içerik sağlayıcılarının korunan içeriğin uyumlu akışını gerçekleştirmesini sağlar.
DASH ekranda ne diyor?
- Dinamik: Değişen koşullara tepki verir.
- Uyarlanabilir: Uygun bir ses veya video bit hızı sağlamak için uyarlanır.
- Yayın: Hem akış olarak hem de video indirmeye olanak tanır.
- HTTP: Geleneksel akış sunucusunun dezavantajları olmadan HTTP avantajıyla içerik yayınlamayı sağlar.
BBC, DASH'i kullanarak test akışları sağlamaya başladı:
Medya, farklı bit hızlarında birkaç kez kodlanır. Her kodlamaya Temsili denir. Bu segmentler bir dizi Medya Segmentine ayrılmıştır. İstemci, HTTP üzerinden bir gösterimden sırasıyla segmentler isteyerek bir program yürütür. Gösterimler, eşdeğer içeriğe sahip temsillerden oluşan Uyarlama Kümeleri halinde gruplandırılabilir. Müşteri bit hızını değiştirmek isterse mevcut uyarlama grubundan bir alternatif seçip bu temsilden segment istemeye başlayabilir. İçerik, istemcinin bu geçişi kolaylaştırmasını sağlayacak şekilde kodlanır. Birkaç medya segmentinin yanı sıra, bir temsilde genellikle bir Başlatma Segmenti de bulunur. Bu, kodlama, çerçeve boyutları vb. hakkında bilgiler içeren bir başlık olarak düşünülebilir. Müşterinin, belirli bir gösterimdeki medya segmentlerini kullanmadan önce bunu alması gerekir.
Özetlemek gerekirse:
- Medya, farklı bit hızlarında kodlanmış.
- Farklı bit hızı dosyaları bir HTTP sunucusundan kullanılabilir.
- DASH ile alınacak ve oynatılacak bit hızını istemci web uygulaması seçer.
Video segmentasyon süreci kapsamında Medya Sunumu Açıklaması (MPD) olarak bilinen bir XML manifesti programatik olarak oluşturulur. Bu, Uyarlama Kümeleri ve Gösterimlerini süreler ve URL'lerle açıklar. MPD şuna benzer:
<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>
(Bu XML, YouTube DASH demo oynatıcısı için kullanılan .mpd dosyasından alınmıştır.)
DASH spesifikasyonuna göre MPD dosyası teoride bir videonun src özelliği olarak kullanılabilir. Ancak web geliştiricilerine daha fazla esneklik sağlamak için tarayıcı tedarikçileri, DASH desteğini dash.js gibi MSE kullanan JavaScript kitaplıklarına kadar bırakmayı tercih etti. DASH'in JavaScript'te uygulanması, uyarlama algoritmasının tarayıcı güncellemeleri gerektirmeden gelişmesine olanak tanır. MSE'nin kullanılması, tarayıcı değişikliği gerektirmeden alternatif manifest biçimleri ve yayınlama mekanizmalarıyla denemeler yapılmasına da olanak tanır. Google'ın Shaka Player, EME destekli bir DASH istemcisi uygular.
Mozilla Geliştirici Ağı'nda videoyu segmentlere ayırmak ve bir MPD oluşturmak için WebM araçları ve FFmpeg'in nasıl kullanılacağı konusunda talimatlar bulunmaktadır.
Sonuç
Ücretli video ve ses sunmak için web'in kullanımı muazzam bir hızla artıyor. İster tablet, oyun konsolu, bağlı TV, ister set üstü kutu olsun her yeni cihaz, başlıca içerik sağlayıcılardan HTTP üzerinden medya akışı yapabiliyor. Mobil ve masaüstü tarayıcıların %85'inden fazlası artık <video> ve <audio> öğelerini desteklemektedir ve Cisco, 2017 yılına kadar videonun global tüketici internet trafiğinin yüzde 80 ila 90'ını oluşturacak. Bu bağlamda, tarayıcı tedarikçilerinin, çoğu medya eklentisinin ihtiyaç duyduğu API'lere yönelik destekleri azalttığı için korunan içerik dağıtımına yönelik tarayıcı desteğinin giderek daha önemli hale gelmesi bekleniyor.
Daha fazla bilgi
Özellikler ve standartlar
EME spesifikasyonu: en yeni Düzenleyici Taslağı Common Encryption (CENC) Medya Kaynağı Uzantıları: en yeni Düzenleyici'nin Taslağı DASH standardı (evet, PDF biçimindedir) DASH standardına genel bakış
Makaleler
DTG Webinar'ı (kısmen eski) EME nedir?, Henri Sivonen Media Source Extensions (Medya Kaynağı Uzantıları) yardımcısı MPEG-DASH Test Streams: BBC R&D blog yayını
Demolar
Anahtar demosu: simpl.info/ck Medya Kaynağı Uzantıları (MSE) demosu Google Shaka Player, EME destekli bir DASH istemcisi uyguluyor