Şifrelenmiş Medya Uzantıları, web uygulamalarının şifrelenmiş ses ve videonun oynatılmasına izin vermek için içerik koruma sistemleriyle etkileşim kurmasını sağlayan bir API sağlar.
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. İlki standartlaştırılmış API'ler ve akış sayesinde, ikincisi ise Ortak Şifreleme kavramı sayesinde mümkün olur.
EME, HTMLMediaElement spesifikasyonunun bir uzantısıdır. "Uzantı" olması, EME için tarayıcı desteğinin isteğe bağlı olduğu anlamına gelir: Bir tarayıcı şifrelenmiş medyayı desteklemiyorsa şifrelenmiş medyayı oynatamaz ancak EME, HTML spesifikasyonuyla uyumluluk için gerekli değildir. EME spesifikasyonundan:
Bu teklif, korunan içeriğin oynatılmasını kontrol etmek için HTMLMediaElement'ın kapsamını genişleten API'ler sağlar.
API, basit açık anahtar şifre çözme işlemlerinden yüksek değerli videoya kadar uzanan kullanım alanlarını destekler (uygun bir kullanıcı aracısı uygulaması varsa). Lisans/anahtar değişimi uygulama tarafından kontrol edilir. Bu sayede, çeşitli içerik şifre çözme ve koruma teknolojilerini destekleyen güçlü oynatma uygulamalarının geliştirilmesi kolaylaştırılır.
Bu spesifikasyon, bir içerik koruma veya Dijital Hak Yönetimi sistemini tanımlamamaktadır. Daha ziyade, daha basit içerik şifreleme sistemlerinin yanı sıra bu tür sistemleri keşfetmek, seçmek ve bunlarla etkileşime geçmek için kullanılabilecek ortak bir API'yi tanımlar. Bu spesifikasyona uyum için Dijital Haklar Yönetimi'nin uygulanması gerekli değildir: Ortak bir temel olarak yalnızca Şeffaf Anahtar sisteminin uygulanması gerekir.
Ortak API, basit bir içerik şifreleme özelliği grubunu destekler. Kimlik doğrulama ve yetkilendirme gibi uygulama işlevleri sayfa yazarlarına bırakılır. Bu, şifreleme sistemi ile lisans veya başka bir sunucu arasında bant dışı iletişim varsaymak yerine, içerik koruma sistemine özgü mesajlaşmanın sayfa tarafından yönetilmesini zorunlu kılarak sağlanır.
EME uygulamaları aşağıdaki harici bileşenleri kullanır:
- Anahtar sistemi: İçerik koruma (DRM) mekanizması. EME, Anahtarları Temizle dışında Anahtar Sistemlerinin kendisini tanımlamaz (bu konuda 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ı. Anahtar Sistemlerinde olduğu gibi EME, herhangi bir CDM tanımlamaz. Bunun yerine uygulamaların mevcut CDM'lerle etkileşime geçebileceğ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 pazarlık yapmak uygulamanın sorumluluğundadır.
- Ambalajlama hizmeti: Medyayı dağıtım/tüketim için kodlar ve şifreler.
EME kullanan bir uygulamanın, şifre çözmeyi etkinleştirmek üzere anahtarları almak için lisans sunucusuyla etkileşime girdiğini 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ın alınması, kullanıcının kimliği (isteğe bağlı olarak) doğrulandıktan sonra gerçekleşir. Netflix gibi hizmetler, web uygulamaları içindeki kullanıcıların kimliğini doğrulamalıdır: Bir kullanıcı uygulamada oturum açtığında kullanıcının kimliğini ve ayrıcalıklarını uygulama belirler.
EME nasıl çalışır?
EME bileşenlerinin etkileşimi, aşağıdaki kod örneğine karşılık gelir:
Birden fazla biçim veya codec varsa doğru biçimi seçmek için MediaSource.isTypeSupported() veya HTMLMediaElement.canPlayType() öğelerinin ikisi de kullanılabilir. Ancak CDM, şifrelenmemiş içerik için tarayıcının desteklediği özelliklerin yalnızca bir alt kümesini destekleyebilir. En iyi yöntem, bir biçim ve codec seçmeden önce MediaKeys yapılandırması için pazarlık yapmaktır. Uygulama şifrelenmiş etkinliği beklerse 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ış, MediaKeysSystemAccess.getConfiguration() yöntemini kullanarak önce MediaKeys ile pazarlık yapmak ve pazarlık yapılan yapılandırmayı öğrenmektir.
Seçilebilecek tek bir biçim/kodek varsa getConfiguration() işlevine gerek yoktur. Ancak yine de önce MediaKeys'i ayarlamak tercih edilir. Şifrelenmiş etkinliği beklemenin tek nedeni, içeriğin şifrelenmiş olup olmadığını bilmenin mümkün olmamasıdır ancak pratikte bu olasılık düşüktür.
- Bir web uygulaması, bir veya daha fazla şifrelenmiş akış içeren ses ya da videoyu oynatmaya çalışır.
- Tarayıcı, medyanın şifrelenmiş olduğunu algılar (bu işlemin nasıl gerçekleştiği için aşağıdaki kutuya bakın) ve şifrelemeyle ilgili olarak medyadan alınan meta verileri (initData) içeren şifrelenmiş bir etkinlik tetikler.
Uygulama, şifrelenmiş etkinliği işler:
Medya öğesiyle ilişkilendirilmiş bir MediaKeys nesnesi yoksa öncelikle hangi anahtar sistemlerinin mevcut olduğunu kontrol etmek için navigator.requestMediaKeySystemAccess() işlevini kullanarak kullanılabilir bir anahtar sistemi seçin, ardından MediaKeySystemAccess nesnesi aracılığıyla kullanılabilir bir anahtar sistemi için MediaKeys nesnesi oluşturun. MediaKeys nesnesinin ilk şifrelenmiş etkinlikten önce başlatılması gerektiğini unutmayın. Lisans sunucusu URL'si, kullanılabilir bir anahtar sistemi seçilmesinden bağımsız olarak uygulama tarafından alınır. MediaKeys nesnesi, bir ses veya video öğesinin medyasını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 CDM'ye erişim sağlar.
MediaKeys nesnesi oluşturulduktan sonra bu nesneyi medya öğesine atayın: setMediaKeys(), MediaKeys nesnesini bir HTMLMediaElement ile ilişkilendirir.Böylece anahtarları oynatma sırasında (ör. kod çözme sırasında) kullanılabilir.
Uygulama, MediaKeys üzerinde createSession() çağrısı yaparak bir MediaKeySession oluşturur. Bu işlem, bir lisansın ve anahtarlarının kullanım süresini temsil eden bir MediaKeySession oluşturur.
Uygulama, MediaKeySession üzerinde generateRequest() işlevini çağırarak şifrelenmiş işleyicide elde edilen medya verilerini CDM'ye ileterek lisans isteği oluşturur.
CDM, bir mesaj etkinliği (lisans sunucusundan anahtar alma isteği) tetikler.
MediaKeySession nesnesi mesaj etkinliğini alır ve uygulama, lisans sunucusuna bir mesaj gönderir (ör. XHR aracılığıyla).
Uygulama, lisans sunucusundan bir yanıt alır ve MediaKeySession sınıfının update() yöntemini kullanarak verileri CDM'ye iletir.
CDM, lisanstaki anahtarları kullanarak medyanın şifresini çözer. Medya öğesiyle ilişkili MediaKeys içindeki herhangi bir oturumdan geçerli bir anahtar kullanılabilir. CDM, anahtar kimliğine göre dizine eklenen anahtara ve politikaya erişir.
Medya oynatmaya devam edilir.
Tarayıcı, medyanın şifrelenmiş olduğunu nasıl anlar?
Bu bilgiler, ISO BMFF veya WebM gibi bir biçimdeki medya kapsayıcı dosyasının meta verilerinde bulunur. ISO BMFF için bu, koruma şeması bilgi kutusu olarak adlandırılan başlık meta verileri anlamına gelir. WebM, WebM'ye özel bazı eklemelerle birlikte Matroska ContentEncryption öğesini kullanır. Her container için EME'ye özel bir kayıt defterinde 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 tarafından anlaşılamadığını unutmayın: Mesajlar yalnızca CDM ve lisans sunucusu tarafından anlaşılır. Ancak uygulama katmanı, CDM'nin 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 aslında ne yapar?
EME uygulaması, medya şifresinin çözülmesi için tek başına bir yöntem sağlamaz. Yalnızca bir web uygulamasının İçerik Şifre Çözme Modülleri ile etkileşim kurması için bir API sağlar.
CDM'lerin gerçekte ne yaptığı, EME spesifikasyonunda tanımlanmamıştır ve bir CDM, medyanın kodunu çözmeyi (sıkıştırma) ve şifre çözmeyi işleyebilir. En azından en güçlüye kadar CDM işlevi için birkaç olası seçenek vardır:
- Yalnızca şifre çözme. Örneğin, <video> öğesi aracılığıyla normal medya ardışık düzenini kullanarak oynatmayı etkinleştirir.
- Şifre çözme ve kod çözme, video karelerini oluşturma için tarayıcıya aktarma.
- Şifre çözme ve kod çözme, doğrudan donanımda (örneğin, GPU) oluşturma.
Bir CDM'yi web uygulamasına sunmanın birden fazla yolu vardır:
- Tarayıcıya bir CDM ekleyin.
- CDM'leri ayrı olarak dağıtın.
- İşletim sistemine bir CDM oluşturun.
- Donanım yazılımına CDM ekleyin.
- Donanıma CDM yerleştirme
CDM'nin nasıl kullanıma sunulacağı EME spesifikasyonunda tanımlanmaz ancak her durumda CDM'yi incelemekten ve göstermekten tarayıcı 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 internette kullanıma sunulduktan sonra web istemcisi, lisans sunucusundan bir anahtar (lisans içinde bulunur) edinebilir ve içeriğin şifresini çözmek ve oynatmak için bu anahtarı kullanabilir.
Aşağıdaki kodda (özellik örneklerinden uyarlanmıştır), bir uygulamanın nasıl uygun bir anahtar sistemi seçebileceği ve lisans sunucusundan anahtar alabileceği gösterilmektedir.
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 her kapsayıcı/codec için bir kez şifreleyip paketlemesini sağlar. Ardından bu içerikleri çeşitli Anahtar Sistemleri, CDM'ler ve istemcilerle (Ortak Şifreleme'yi destekleyen tüm CDM'ler) kullanabilir. Örneğin, PlayREAD kullanılarak paketlenmiş bir video, Widevine lisans sunucusundan anahtar alan Widevine CDM kullanılarak tarayıcıda oynatılabilir.
Bu, genellikle uygulama çalışma zamanı da içeren tek bir istemci de dahil olmak üzere yalnızca tam bir dikey yığınla çalışacak eski çözümlerin aksinedir.
Ortak Şifreleme (CENC), ISO BMFF için bir koruma şemasını tanımlayan bir ISO standardıdır. WebM için de benzer bir kavram geçerlidir.
Anahtarı Temizle
EME, DRM işlevini tanımlamasa da spesifikasyon şu anda EME'yi destekleyen tüm tarayıcıların Clear Key'i uygulaması gerektiğini zorunlu kılmaktadır. Bu sistem sayesinde medya bir anahtarla şifrelenip anahtar sağlanarak oynatılabilir. Anahtarı Temizle, tarayıcıda yerleşik olarak bulunabilir. Yani ayrı bir şifre çözme modülünün kullanılmasını gerektirmez.
Birçok ticari içerik türü için kullanılması olası olmasa da Clear Key, EME'yi destekleyen tüm tarayıcılarda tam olarak birlikte çalışabilir. Ayrıca, lisans sunucusundan içerik anahtarı istemek zorunda kalmadan EME uygulamalarını ve EME kullanan uygulamaları test etmek için de kullanışlıdır. simpl.info/ck adresinde basit bir Clear Key örneği bulunmaktadır. Aşağıda, lisans sunucusu etkileşimi olmadan yukarıda açıklanan adımlara paralel olan kodun adım adım açıklaması verilmiştir.
// 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 oynatılacak şifrelenmiş bir videoya ihtiyacınız vardır. Bir videoyu Clear Key ile kullanmak üzere şifrelemek için WebM'de webm_crypt talimatlarına göre işlem yapabilirsiniz. Ticari hizmetler de mevcuttur (en azından ISO BMFF/MP4 için) ve diğer çözümler geliştirilmektedir.
İlgili teknoloji 1: Medya Kaynağı Uzantılar (MSE)
HTMLMediaElement, basit bir güzelliğe sahip bir öğedir.
Sadece bir src URL'si sağlayarak medyaları yükleyebilir, kodunu çözebilir ve oynatabiliriz:
<video src="foo.webm"></video>
Media Source API, JavaScript'in video "bölümlerinden" oynatma için akış oluşturmasına izin vererek medya kaynağı üzerinde daha ayrıntılı kontrol sağlayan HTMLMediaElement uzantısıdır. Bu da uyumlu akış ve zaman kaydırma gibi teknikleri mümkün kılar.
MSE, EME için neden önemlidir? Ticari içerik sağlayıcılar, korumalı içerik dağıtmanın yanı sıra içerik yayınlamayı ağ koşullarına ve diğer şartlara uyarlayabilmeleri gerekir. Örneğin Netflix, ağ koşulları değiştikçe yayın bit hızını dinamik olarak değiştirir. EME, src özelliği aracılığıyla sağlanan medyayla olduğu gibi, MSE uygulaması tarafından sağlanan medya akışlarının oynatılmasında da çalışır.
Farklı bit hızlarında kodlanmış medyayı nasıl parçalara ayırabilir ve oynatabilirim? Aşağıdaki DASH bölümüne bakın.
MSE'yi simpl.info/mse adresinde görebilirsiniz. Bu örnekte, File API'leri kullanılarak bir WebM videosu beş parçaya bölünmüş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 filmin tamamı, her bir parçayı InsertBuffer() yöntemi ile eklenerek bir video öğesine "akış" hâle getirir:
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 yardım makalesinde MSE hakkında daha fazla bilgi edinebilirsiniz.
İlgili teknoloji 2: HTTP üzerinden Dinamik Adaptif Akış (DASH)
Birden çok cihazda, birden çok platformda, mobilde, kısacası ne olursa olsun web deneyimi genellikle değiştirilebilir bağlantı koşullarında yaşanır. Dinamik, uyarlanabilir yayınlama, çok cihazlı dünyadaki bant genişliği kısıtlamaları ve değişkenlikle başa çıkmak için çok önemlidir.
DASH (diğer adıyla MPEG-DASH), hem akış hem de indirme için kararsız 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 çözümü gibi birçok başka teknoloji de benzer işlemler gerçekleştiriyor. Ancak DASH, HTTP üzerinden açık standarda dayalı 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ı, mevcut HTTP altyapısını kullanarak bir manifest'i ayrıştırabilir, video segmentlerini uygun bit hızında indirebilir ve ihtiyaç duyduğunda bunları bir video öğesine besleyebilir.
Diğer bir deyişle, DASH, ticari içerik sağlayıcıların korumalı içerikleri uyarlanabilir şekilde yayınlamasına olanak tanır.
DASH, kutunun üzerinde yazan şekilde çalışıyor:
- Dinamik: Değişen koşullara yanıt verir.
- Uyarlanabilir: Uygun bir ses veya video bit hızı sağlamak için uyum sağlar.
- Akış: İndirmenin yanı sıra canlı yayına da olanak tanır.
- HTTP: Geleneksel bir akış sunucusunun dezavantajları olmadan, HTTP'nin avantajlarıyla içerik yayınlamayı sağlar.
BBC, DASH'ı kullanarak test yayınları sağlamaya başladı:
Medya, farklı bit hızlarında birkaç kez kodlanır. Her kodlamaya Temsil adı verilir. Bunlar birkaç medya segmentine ayrılır. Müşteri, sırayla HTTP üzerinden bir sunumdan segmentler isteyerek bir programı yürütür. Sunular, eşdeğer içerik barındıran temsillerin Uyarlama Kümeleri olarak gruplanabilir. Müşteri bit hızını değiştirmek isterse mevcut uyum setinden bir alternatif seçebilir ve bu temsilden segment istemeye başlayabilir. İçerik, istemcinin bu geçişi kolayca yapmasını sağlayacak şekilde kodlanır. Bir temsilde genellikle çeşitli medya segmentlerinin yanı sıra bir de başlatma segmenti bulunur. Bu, kodlama, kare boyutları vb. ile ilgili bilgiler içeren bir başlık olarak düşünülebilir. Bir müşterinin, belirli bir gösterimden medya segmentlerini almadan önce bu gösterimi elde etmesi gerekir.
Özetlemek gerekirse:
- Medya farklı bit hızlarında kodlanır.
- Farklı bit hızı dosyaları bir HTTP sunucusundan kullanılabilir.
- İstemci web uygulaması, DASH ile hangi bit hızının alınacağını ve oynatılacağını seçer.
Video segmentasyon sürecinin bir parçası olarak, Medya Sunumu Açıklaması (MPD) olarak bilinen bir XML manifesti programatik olarak oluşturulur. Bu, süreleri ve URL'leri içeren Uyarlama Kümeleri ve Temsilleri'ni açıklar. MPD şu şekilde görünür:
<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, bir MPD dosyası teorik olarak bir videonun src 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 bırakmayı tercih etti. DASH'ı JavaScript'te uygulamak, uyum algoritmasının tarayıcı güncellemeleri gerektirmeden gelişmesine olanak tanır. MSE'yi kullanmak, tarayıcı değişikliği gerektirmeden alternatif manifest biçimleri ve yayınlama mekanizmaları ile denemeler yapmaya da olanak tanır. Google'ın Shaka Player'ı, EME desteğine sahip bir DASH istemcisi uygular.
Videoyu segmentlere ayırmak ve MPD oluşturmak için WebM araçlarını ve FFmpeg'i kullanmayla ilgili talimatlar Mozilla Developer Network'te yer almaktadır.
Sonuç
Ücretli video ve ses yayınlamak için web'in kullanımı çok hızlı bir şekilde artıyor. Tablet, oyun konsolu, bağlı TV veya set üstü kutu gibi yeni cihazların tümü, büyük içerik sağlayıcılardan HTTP üzerinden medya aktarabiliyor. Mobil ve masaüstü tarayıcıların %85'inden fazlası artık <video> ve <audio> öğelerini destekliyor. Cisco, 2017'ye kadar videonun dünya genelindeki tüketici internet trafiğinin yüzde 80 ila 90'ını oluşturacağını tahmin ediyor. Bu bağlamda, tarayıcı tedarikçi firmaları çoğu medya eklentisinin kullandığı API'ler için destekleri azaltacağından, korumalı içerik dağıtımı için tarayıcı desteğinin giderek daha önemli hale gelmesi muhtemeldir.
Daha fazla bilgi
Özellikler ve standartlar
EME spesifikasyonu: En son Editörün Taslağı Ortak Şifreleme (CENC) Medya Kaynağı Uzantıları: En son Editörün Taslağı DASH standardı (evet, PDF'dir) DASH standardına genel bakış
Makaleler
DTG Web Semineri (kısmen geçersiz) Henri Sivonen tarafından yazılan EME nedir? Media Source Extensions primer MPEG-DASH Test Akışları: BBC AR-GE blog yayını
Demolar
Clear Key demosu: simpl.info/ck Media Source Extensions (MSE) demosu Google'ın Shaka Player EME desteğine sahip bir DASH istemcisi uygular