ข้อมูลเบื้องต้นเกี่ยวกับส่วนขยายสื่อที่เข้ารหัส

Sam Dutton

Encrypted Media Extensions (EME) มี API ที่ช่วยให้เว็บแอปพลิเคชันโต้ตอบกับระบบการป้องกันเนื้อหาได้ เพื่ออนุญาตให้เล่นเสียงและวิดีโอที่เข้ารหัส

EME ได้รับการออกแบบมาเพื่อให้ใช้แอปและไฟล์ที่เข้ารหัสเดียวกันในเบราว์เซอร์ใดก็ได้ โดยไม่คำนึงถึงระบบการป้องกันพื้นฐาน การดำเนินการแบบแรกเกิดขึ้นได้เพราะ API และขั้นตอนมาตรฐาน ส่วนการดำเนินการแบบหลังเกิดขึ้นได้เพราะแนวคิดการเข้ารหัสทั่วไป

EME เป็นส่วนขยายของข้อกำหนด HTMLMediaElement จึงเป็นที่มาของชื่อ การเป็น "ส่วนขยาย" หมายความว่าการรองรับ EME ของเบราว์เซอร์นั้นไม่บังคับ หากเบราว์เซอร์ไม่รองรับสื่อที่เข้ารหัส เบราว์เซอร์จะเล่นสื่อที่เข้ารหัสไม่ได้ แต่ไม่จำเป็นต้องใช้ EME เพื่อให้เป็นไปตามข้อกำหนดของข้อกำหนด HTML จากข้อมูลจำเพาะ EME

การใช้งาน EME ใช้คอมโพเนนต์ภายนอกต่อไปนี้

  • ระบบคีย์: กลไกการป้องกันเนื้อหา (DRM) EME ไม่ได้กำหนดระบบคีย์เอง ยกเว้น Clear Key (ดูข้อมูลเพิ่มเติมด้านล่าง)
  • Content Decryption Module (CDM): กลไกซอฟต์แวร์หรือฮาร์ดแวร์ฝั่งไคลเอ็นต์ที่เปิดใช้การเล่นสื่อที่เข้ารหัส เช่นเดียวกับระบบคีย์ EME ไม่ได้กำหนด CDM ใดๆ แต่มีอินเทอร์เฟซสำหรับแอปพลิเคชันเพื่อโต้ตอบกับ CDM ที่มีให้
  • เซิร์ฟเวอร์ใบอนุญาต (คีย์): โต้ตอบกับ CDM เพื่อระบุคีย์สำหรับถอดรหัสสื่อ การเจรจากับเซิร์ฟเวอร์ใบอนุญาตเป็นความรับผิดชอบของแอปพลิเคชัน
  • บริการแพ็กเกจ: เข้ารหัสและเข้ารหัสสื่อเพื่อการจัดจำหน่าย/การใช้งาน

โปรดทราบว่าแอปพลิเคชันที่ใช้ EME จะโต้ตอบกับเซิร์ฟเวอร์ใบอนุญาตเพื่อรับคีย์เพื่อเปิดใช้การถอดรหัส แต่ข้อมูลประจำตัวผู้ใช้และการตรวจสอบสิทธิ์ไม่ได้เป็นส่วนหนึ่งของ EME การเรียกข้อมูลคีย์เพื่อเปิดใช้การเล่นสื่อจะเกิดขึ้นหลังจากตรวจสอบสิทธิ์ผู้ใช้ (ไม่บังคับ) บริการต่างๆ เช่น Netflix ต้องมีการตรวจสอบสิทธิ์ผู้ใช้ภายในเว็บแอปพลิเคชันของตน เมื่อผู้ใช้ลงชื่อเข้าใช้แอปพลิเคชัน แอปพลิเคชันจะระบุตัวตนและสิทธิ์ของผู้ใช้

EME ทำงานอย่างไร

ต่อไปนี้คือวิธีที่องค์ประกอบของ EME โต้ตอบกัน ซึ่งสอดคล้องกับตัวอย่างโค้ดต่อไปนี้

  1. เว็บแอปพลิเคชันพยายามเล่นเสียงหรือวิดีโอที่มีสตรีมที่เข้ารหัสอย่างน้อย 1 รายการ
  2. เบราว์เซอร์จะรับรู้ว่าสื่อได้รับการเข้ารหัส (ดูวิธีการที่ช่องด้านล่าง) และเรียกเหตุการณ์ encrypted ที่มีข้อมูลเมตา (initData) ที่ได้มาจากสื่อเกี่ยวกับการเข้ารหัส
  3. แอปพลิเคชันจัดการเหตุการณ์ encrypted ดังนี้
    1. หากไม่มีออบเจ็กต์ MediaKeys ที่เชื่อมโยงกับองค์ประกอบสื่อ ให้เลือกระบบคีย์ที่ใช้ได้ก่อนโดยใช้ navigator.requestMediaKeySystemAccess() เพื่อตรวจสอบว่าระบบคีย์ใดบ้างที่ใช้ได้ จากนั้นสร้างออบเจ็กต์ MediaKeys สำหรับระบบคีย์ที่ใช้ได้ผ่านออบเจ็กต์ MediaKeySystemAccess โปรดทราบว่าการเริ่มต้นวัตถุ MediaKeys ควรเกิดขึ้นก่อนเหตุการณ์ encrypted รายการแรก แอปจะรับ URL ของเซิร์ฟเวอร์ใบอนุญาตโดยอิสระจากการเลือกระบบคีย์ที่ใช้ได้ ออบเจ็กต์ MediaKeys แสดงคีย์ทั้งหมดที่ใช้ถอดรหัสสื่อสำหรับองค์ประกอบเสียงหรือวิดีโอได้ อินสแตนซ์นี้แสดงอินสแตนซ์ CDM และให้สิทธิ์เข้าถึง CDM โดยเฉพาะสำหรับการสร้างเซสชันคีย์ ซึ่งจะใช้เพื่อรับคีย์จากเซิร์ฟเวอร์ใบอนุญาต
    2. เมื่อสร้างออบเจ็กต์ MediaKeys แล้ว ให้กำหนดออบเจ็กต์นั้นให้กับองค์ประกอบสื่อ: setMediaKeys() จะเชื่อมโยงออบเจ็กต์ MediaKeys กับ HTMLMediaElement เพื่อให้ใช้คีย์ของออบเจ็กต์ดังกล่าวระหว่างการเล่นได้ เช่น ระหว่างการถอดรหัส
  4. แอปสร้าง MediaKeySession โดยการเรียก createSession() ใน MediaKeys ซึ่งจะสร้าง MediaKeySession ที่แสดงถึงอายุการใช้งานของใบอนุญาตและคีย์
  5. แอปจะสร้างคำขอใบอนุญาตโดยการส่งข้อมูลสื่อที่ได้รับในตัวแฮนเดิล encrypted ไปยัง CDM โดยการเรียกใช้ generateRequest() ใน MediaKeySession
  6. CDM จะเรียกเหตุการณ์ message: คำขอรับคีย์จากเซิร์ฟเวอร์ใบอนุญาต
  7. ออบเจ็กต์ MediaKeySession จะได้รับเหตุการณ์ message และแอปพลิเคชันจะส่งข้อความไปยังเซิร์ฟเวอร์ใบอนุญาต (เช่น ผ่าน XHR)
  8. แอปพลิเคชันจะได้รับการตอบกลับจากเซิร์ฟเวอร์ใบอนุญาตและส่งข้อมูลไปยัง CDM โดยใช้เมธอด update() ของ MediaKeySession
  9. CDM จะถอดรหัสสื่อโดยใช้คีย์ในใบอนุญาต สามารถใช้คีย์ที่ถูกต้องจากเซสชันใดก็ได้ภายใน MediaKey ที่เชื่อมโยงกับองค์ประกอบสื่อ CDM จะเข้าถึงคีย์และนโยบายที่จัดทําดัชนีตามรหัสคีย์
  10. การเล่นสื่อจะเล่นต่อ

โล่งอกไปที

โปรดทราบว่าอาจมีข้อความหลายรายการระหว่าง CDM กับเซิร์ฟเวอร์ใบอนุญาต และการสื่อสารทั้งหมดในกระบวนการนี้จะไม่แสดงต่อเบราว์เซอร์และแอปพลิเคชัน โดย CDM และเซิร์ฟเวอร์ใบอนุญาตเท่านั้นที่เข้าใจข้อความ แม้ว่าเลเยอร์แอปจะดูประเภทข้อความที่ CDM ส่งได้ก็ตาม คำขอใบอนุญาตมีหลักฐานยืนยันความถูกต้องของ CDM (และความสัมพันธ์ของความไว้วางใจ) รวมถึงคีย์ที่จะใช้เมื่อเข้ารหัสคีย์เนื้อหาในใบอนุญาตที่ได้

…แต่ CDM ทำงานอย่างไร

การใช้ EME ไม่ได้ให้วิธีถอดรหัสสื่อ แต่เป็นเพียงการให้ API สําหรับเว็บแอปพลิเคชันเพื่อโต้ตอบกับโมดูลการถอดรหัสเนื้อหา

ข้อมูลเกี่ยวกับสิ่งที่ CDM ทำงานจริงไม่ได้กำหนดไว้ในข้อกำหนด EME และ CDM อาจจัดการการถอดรหัส (การขยายไฟล์) ของสื่อและการถอดรหัสด้วย ฟังก์ชันการทำงานของ CDM มีตัวเลือกหลายอย่างตั้งแต่มีประสิทธิภาพน้อยที่สุดไปจนถึงมีประสิทธิภาพมากที่สุด ดังนี้

  • การถอดรหัสเท่านั้น ซึ่งจะเปิดใช้การเล่นโดยใช้ไปป์ไลน์สื่อปกติ เช่น ผ่านองค์ประกอบ <video>
  • การถอดรหัสและถอดรหัส การส่งเฟรมวิดีโอไปยังเบราว์เซอร์เพื่อแสดงผล
  • การถอดรหัสและการถอดรหัสการแสดงผลในฮาร์ดแวร์โดยตรง (เช่น GPU)

การทำให้ CDM พร้อมใช้งานสำหรับเว็บแอปทำได้หลายวิธีดังนี้

  • รวม CDM กับเบราว์เซอร์
  • เผยแพร่ CDM แยกกัน
  • สร้าง CDM ลงในระบบปฏิบัติการ
  • รวม CDM ไว้ในเฟิร์มแวร์
  • ฝัง CDM ในฮาร์ดแวร์

ข้อกำหนดเฉพาะของ EME ไม่ได้กำหนดวิธีทำให้ CDM พร้อมใช้งาน แต่ในทุกกรณีเบราว์เซอร์มีหน้าที่รับผิดชอบในการตรวจสอบและแสดง CDM

EME ไม่ได้บังคับใช้ระบบจัดการคีย์ใดระบบหนึ่ง โดยเบราว์เซอร์เดสก์ท็อปและอุปกรณ์เคลื่อนที่ในปัจจุบัน Chrome รองรับ Widevine และ IE11 รองรับ PlayReady

การรับคีย์จากเซิร์ฟเวอร์ใบอนุญาต

การใช้งานเชิงพาณิชย์ทั่วไปจะเข้ารหัสและเข้ารหัสเนื้อหาโดยใช้บริการหรือเครื่องมือแพ็กเกจ เมื่อสื่อที่เข้ารหัสพร้อมใช้งานทางออนไลน์แล้ว เว็บไคลเอ็นต์จะได้รับคีย์ (อยู่ในใบอนุญาต) จากเซิร์ฟเวอร์ใบอนุญาต และใช้คีย์ดังกล่าวเพื่อเปิดใช้การถอดรหัสและการเล่นเนื้อหา

โค้ดต่อไปนี้ (ปรับมาจากตัวอย่างข้อกำหนด) แสดงวิธีที่แอปพลิเคชันสามารถเลือกระบบคีย์ที่เหมาะสมและรับคีย์จากเซิร์ฟเวอร์ใบอนุญาต

var video = document.querySelector('video');

var config = [{initDataTypes: ['webm'],
  videoCapabilities: [{contentType: 'video/webm; codecs="vp9"'}]}];

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')
  );
}

การเข้ารหัสทั่วไป

โซลูชันการเข้ารหัสทั่วไปช่วยให้ผู้ให้บริการเนื้อหาเข้ารหัสและแพ็กเกจเนื้อหาได้ครั้งเดียวต่อคอนเทนเนอร์/โค้ด และนำไปใช้กับระบบจัดการคีย์, CDM และไคลเอ็นต์ที่หลากหลายได้ ซึ่งก็คือ CDM ที่รองรับการเข้ารหัสทั่วไป ตัวอย่างเช่น วิดีโอที่แพ็กโดยใช้ PlayReady สามารถเล่นในเบราว์เซอร์ได้โดยใช้ CDM ของ Widevine ที่ได้รับคีย์จากเซิร์ฟเวอร์ใบอนุญาตของ Widevine

ซึ่งแตกต่างจากโซลูชันเดิมที่จะทํางานได้กับสแต็กแนวตั้งที่สมบูรณ์เท่านั้น รวมถึงไคลเอ็นต์เดียวที่มักจะรวมรันไทม์แอปพลิเคชันด้วย

การเข้ารหัสทั่วไป (CENC) คือมาตรฐาน ISO ที่กําหนดรูปแบบการป้องกันสําหรับ ISO BMFF ซึ่งแนวคิดที่คล้ายกันนี้ใช้กับ WebM ด้วย

ล้างคีย์

แม้ว่า EME จะไม่กำหนดฟังก์ชันการทำงานของ DRM แต่ปัจจุบันข้อกำหนดเฉพาะกําหนดให้เบราว์เซอร์ทั้งหมดที่รองรับ EME ต้องใช้ Clear Key เมื่อใช้ระบบนี้ สื่อจะเข้ารหัสด้วยคีย์ จากนั้นเล่นกลับได้โดยระบุคีย์นั้น Clear Key สามารถฝังไว้ในเบราว์เซอร์ได้โดยไม่ต้องใช้โมดูลการถอดรหัสแยกต่างหาก

แม้ว่า Clear Key จะไม่น่าจะนำมาใช้กับเนื้อหาเชิงพาณิชย์หลายประเภท แต่ก็สามารถทำงานร่วมกันได้อย่างสมบูรณ์ในเบราว์เซอร์ทั้งหมดที่รองรับ EME นอกจากนี้ ยังสะดวกสำหรับการทดสอบการใช้งาน EME และแอปพลิเคชันที่ใช้ EME โดยไม่ต้องขอคีย์เนื้อหาจากเซิร์ฟเวอร์ใบอนุญาต ดูตัวอย่างคีย์ที่ชัดเจนแบบง่ายได้ที่ simpl.info/ck ด้านล่างนี้คือคำแนะนำเกี่ยวกับโค้ด ซึ่งคล้ายกับขั้นตอนที่อธิบายไว้ข้างต้น แต่จะไม่มีการโต้ตอบกับเซิร์ฟเวอร์ใบอนุญาต

// 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]
  }));
}

หากต้องการทดสอบโค้ดนี้ คุณต้องมีวิดีโอที่เข้ารหัสเพื่อเล่น การเข้ารหัสวิดีโอเพื่อใช้กับ Clear Key ทำได้ใน WebM ตามวิธีการสำหรับเว็บม_คริปต์ นอกจากนี้ เรายังมีบริการเชิงพาณิชย์ (สำหรับ ISO BMFF/MP4 เป็นอย่างน้อย) และกำลังพัฒนาโซลูชันอื่นๆ

ส่วนขยายแหล่งที่มาของสื่อ (MSE)

HTMLMediaElement เป็นองค์ประกอบที่เรียบง่ายแต่งดงาม

เราสามารถโหลด ถอดรหัส และเล่นสื่อได้ง่ายๆ เพียงระบุ URL ของ src

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

Media Source API เป็นส่วนขยายของ HTMLMediaElement ซึ่งช่วยให้ควบคุมแหล่งที่มาของสื่อได้ละเอียดยิ่งขึ้น โดยอนุญาตให้ JavaScript สร้างสตรีมสำหรับการเล่นจาก "ข้อมูลโค้ด" ของวิดีโอ ซึ่งจะช่วยให้ใช้เทคนิคต่างๆ ได้ เช่น สตรีมมิงแบบปรับเปลี่ยนได้และการเลื่อนเวลา

เหตุใด MSE จึงสำคัญต่อ EME เนื่องจากนอกเหนือจากการเผยแพร่เนื้อหาที่ได้รับการคุ้มครองแล้ว ผู้ให้บริการเนื้อหาเชิงพาณิชย์ยังต้องปรับการแสดงเนื้อหาให้เข้ากับสภาพเครือข่ายและข้อกำหนดอื่นๆ ด้วย ตัวอย่างเช่น Netflix จะเปลี่ยนอัตราบิตของสตรีมแบบไดนามิกเมื่อสภาพเครือข่ายเปลี่ยนแปลง EME ทำงานร่วมกับการเล่นสตรีมสื่อที่ได้จากการใช้งาน MSE เช่นเดียวกับที่ทำงานร่วมกับสื่อที่ระบุผ่านแอตทริบิวต์ src

วิธีแบ่งและเล่นสื่อที่เข้ารหัสด้วยอัตราบิตที่แตกต่างกัน ดูส่วน DASH ด้านล่าง

คุณสามารถดูการทำงานของ MSE ได้ที่ simpl.info/mse ในตัวอย่างนี้ วิดีโอ WebM จะแบ่งออกเป็น 5 ชิ้นโดยใช้ File API ในแอปพลิเคชันเวอร์ชันที่ใช้งานจริง ระบบจะดึงข้อมูลวิดีโอบางส่วนผ่าน Ajax

ก่อนอื่น ระบบจะสร้าง SourceBuffer ดังนี้

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

จากนั้นระบบจะ "สตรีม" ภาพยนตร์ทั้งเรื่องไปยังองค์ประกอบวิดีโอโดยการต่อข้อมูลแต่ละส่วนต่อท้ายโดยใช้เมธอด 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);
  }
};

ดูข้อมูลเพิ่มเติมเกี่ยวกับ MSE ในบทความ HTML5 Rocks

การสตรีมที่ปรับเปลี่ยนได้แบบไดนามิกผ่าน HTTP (DASH)

ไม่ว่าจะเรียกเว็บว่าอุปกรณ์หลายเครื่อง หลายแพลตฟอร์ม หรืออุปกรณ์เคลื่อนที่ ผู้ใช้มักจะพบปัญหาการเชื่อมต่อที่เปลี่ยนแปลงได้ การแสดงผลแบบไดนามิกที่ปรับเปลี่ยนได้เป็นสิ่งที่สําคัญในการรับมือกับข้อจํากัดของแบนด์วิดท์และความแปรปรวนในโลกที่อุปกรณ์หลากหลาย

DASH (หรือ MPEG-DASH) ได้รับการออกแบบมาเพื่อช่วยให้การส่งสื่อที่ดีที่สุดเท่าที่จะเป็นไปได้ในโลกที่อินเทอร์เน็ตไม่เสถียร ทั้งสำหรับการสตรีมและดาวน์โหลด เทคโนโลยีอื่นๆ อีกหลายอย่างทำงานคล้ายกัน เช่น HTTP Live Streaming (HLS) ของ Apple และ Smooth Streaming ของ Microsoft แต่ DASH เป็นวิธีเดียวในการสตรีมแบบปรับอัตราบิตผ่าน HTTP ที่อิงตามมาตรฐานแบบเปิด เว็บไซต์ต่างๆ เช่น YouTube ใช้ DASH อยู่แล้ว

การดำเนินการนี้เกี่ยวข้องกับ EME และ MSE อย่างไร การใช้งาน DASH ที่ใช้ MSE สามารถแยกวิเคราะห์ไฟล์ Manifest, ดาวน์โหลดส่วนของวิดีโอที่อัตราบิตที่เหมาะสม และส่งไปยังองค์ประกอบวิดีโอเมื่อต้องการโดยใช้โครงสร้างพื้นฐาน HTTP ที่มีอยู่

กล่าวคือ DASH ช่วยให้ผู้ให้บริการเนื้อหาเชิงพาณิชย์สามารถสตรีมเนื้อหาที่ได้รับการคุ้มครองแบบปรับเปลี่ยนได้

DASH ทำงานตามที่ระบุไว้ดังนี้

  • แบบไดนามิก: ตอบสนองต่อสภาพอากาศที่เปลี่ยนแปลง
  • แบบปรับขนาดได้: ปรับขนาดเพื่อให้อัตราบิตของเสียงหรือวิดีโอเหมาะสม
  • สตรีมมิง: อนุญาตให้สตรีมรวมถึงดาวน์โหลด
  • HTTP: ช่วยให้สามารถส่งเนื้อหาโดยใช้ประโยชน์จาก HTTP ได้โดยไม่ต้องมีข้อเสียของเซิร์ฟเวอร์สตรีมมิงแบบดั้งเดิม

BBC ได้เริ่มสตรีมทดสอบโดยใช้ DASH แล้ว โดยทำดังนี้

โดยสรุป

  1. สื่อได้รับการเข้ารหัสด้วยอัตราบิตที่แตกต่างกัน
  2. ไฟล์อัตราบิตต่างๆ จะพร้อมใช้งานจากเซิร์ฟเวอร์ HTTP
  3. เว็บแอปไคลเอ็นต์จะเลือกอัตราบิตที่จะดึงข้อมูลและเล่นด้วย DASH

ไฟล์ Manifest ของ XML หรือที่เรียกว่า Media Presentation Description (MPD) จะสร้างขึ้นแบบเป็นโปรแกรมโดยเป็นส่วนหนึ่งของกระบวนการแบ่งกลุ่มวิดีโอ ซึ่งจะอธิบายชุดการปรับเปลี่ยนและการแสดงผล พร้อมระยะเวลาและ URL MPD จะมีลักษณะดังนี้

<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>

(XML นี้นำมาจากไฟล์ .mpd ที่ใช้สำหรับโปรแกรมเล่นเดโม DASH ของ YouTube)

ตามข้อกำหนดของ DASH ในทางทฤษฎีแล้ว ไฟล์ MPD สามารถใช้เป็น src สำหรับวิดีโอได้ อย่างไรก็ตาม ผู้ให้บริการเบราว์เซอร์เลือกที่จะให้การสนับสนุน DASH ขึ้นอยู่กับไลบรารี JavaScript ที่ใช้ MSE เช่น dash.js เพื่อให้นักพัฒนาเว็บมีความยืดหยุ่นมากขึ้น การใช้ DASH ใน JavaScript จะช่วยให้อัลกอริทึมการปรับสภาพพัฒนาได้โดยไม่ต้องอัปเดตเบราว์เซอร์ การใช้ MSE ยังช่วยให้คุณทดสอบรูปแบบไฟล์ Manifest และกลไกการแสดงผลอื่นๆ ได้โดยไม่ต้องเปลี่ยนแปลงเบราว์เซอร์ Shaka Player ของ Google ใช้ไคลเอ็นต์ DASH ที่รองรับ EME

Mozilla Developer Network มีวิธีการเกี่ยวกับวิธีใช้เครื่องมือ WebM และ FFmpeg เพื่อแบ่งกลุ่มวิดีโอและสร้าง MPD

บทสรุป

การใช้เว็บเพื่อส่งวิดีโอและเสียงแบบชำระเงินเพิ่มขึ้นในอัตราที่สูงมาก ดูเหมือนว่าอุปกรณ์ใหม่ทุกเครื่อง ไม่ว่าจะเป็นแท็บเล็ต คอนโซลเกม ทีวีที่เชื่อมต่ออินเทอร์เน็ต หรือกล่องรับสัญญาณ จะสามารถสตรีมสื่อจากผู้ให้บริการเนื้อหารายใหญ่ผ่าน HTTP ได้ ปัจจุบันเบราว์เซอร์ในอุปกรณ์เคลื่อนที่และเดสก์ท็อปกว่า 85% รองรับ <video> และ <audio> และ Cisco คาดการณ์ว่าวิดีโอจะคิดเป็นสัดส่วน 80-90 เปอร์เซ็นต์ของการเข้าชมอินเทอร์เน็ตของผู้บริโภคทั่วโลกภายในปี 2017 ด้วยเหตุนี้ การสนับสนุนของเบราว์เซอร์สำหรับการเผยแพร่เนื้อหาที่ได้รับการคุ้มครองจึงมีแนวโน้มที่จะมีความสำคัญมากขึ้น เนื่องจากผู้ให้บริการเบราว์เซอร์ ลดการสนับสนุน API ที่ปลั๊กอินสื่อส่วนใหญ่ใช้

อ่านเพิ่มเติม

ข้อมูลจำเพาะและมาตรฐาน

บทความ