การอัปเดตสื่อใน Chrome 69

François Beaufort
François Beaufort

ตัวถอดรหัสวิดีโอ AV1

Chromestatus Tracker | ข้อบกพร่อง Chromium

EME: การค้นหาการรองรับรูปแบบการเข้ารหัส

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

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

คีย์ encryptionScheme ใหม่อาจเป็นค่าใดค่าหนึ่งจาก 2 ค่าต่อไปนี้

  • 'cenc' การเข้ารหัสตัวอย่างแบบเต็มของโหมด AES-CTR และการเข้ารหัสตัวอย่างย่อย NAL วิดีโอ
  • 'cbcs' การเข้ารหัสรูปแบบ NAL ของวิดีโอบางส่วนในโหมด AES-CBC

หากไม่ระบุ ระบบจะระบุว่ารูปแบบการเข้ารหัสทั้งหมดยอมรับได้ โปรดทราบว่า Clear Key จะรองรับรูปแบบ 'cenc' เสมอ

ตัวอย่างด้านล่างแสดงวิธีค้นหาการกำหนดค่า 2 รายการที่มีรูปแบบการเข้ารหัสต่างกัน ในกรณีนี้ ระบบจะเลือกเพียงรายการเดียว

await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [
    {
      label: 'configuration using the "cenc" encryption scheme',
      videoCapabilities: [{
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cenc'
      }],
      audioCapabilities: [{
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cenc'
      }],
      initDataTypes: ['keyids']
    },
    {
      label: 'configuration using the "cbcs" encryption scheme',
      videoCapabilities: [{
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cbcs'
      }],
      audioCapabilities: [{
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cbcs'
      }],
      initDataTypes: ['keyids']
    },
  ]);

ในตัวอย่างด้านล่าง ระบบจะค้นหาการกำหนดค่าเพียงรายการเดียวที่มีรูปแบบการเข้ารหัสที่แตกต่างกัน 2 รูปแบบ ในกรณีดังกล่าว Chrome จะทิ้งออบเจ็กต์ความสามารถที่โปรแกรมไม่รองรับ ดังนั้นการกำหนดค่าสะสมอาจมีรูปแบบการเข้ารหัส 1 รูปแบบหรือทั้ง 2 แบบ

await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [{
    videoCapabilities: [
      { // A video capability using the "cenc" encryption scheme
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cenc'
      },
      { // A video capability using the "cbcs" encryption scheme
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cbcs'
      },
    ],
    audioCapabilities: [
      { // An audio capability using the "cenc" encryption scheme
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cenc'
      },
      { // An audio capability using the "cbcs" encryption scheme
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cbcs'
      },
    ],
    initDataTypes: ['keyids']
  }]);

ความตั้งใจในการติดตั้งใช้งาน | ตัวติดตาม Chromestatus | ข้อบกพร่อง Chromium

EME: การตรวจสอบนโยบาย HDCP

ปัจจุบัน HDCP เป็นข้อกำหนดในนโยบายที่ใช้กันทั่วไปสำหรับการสตรีมเนื้อหาที่มีการคุ้มครองความละเอียดสูง และนักพัฒนาเว็บที่ต้องการบังคับใช้นโยบาย HDCP จะต้องรอให้การแลกเปลี่ยนใบอนุญาตเสร็จสมบูรณ์หรือเริ่มสตรีมเนื้อหาที่มีความละเอียดต่ำ นี่เป็นสถานการณ์ที่น่าเศร้าที่ HDCP Policy Check API ตั้งใจจะแก้ไข

API ที่เสนอนี้ช่วยให้นักพัฒนาเว็บค้นหาได้ว่าสามารถบังคับใช้นโยบาย HDCP บางอย่างได้หรือไม่ เพื่อให้การเล่นเริ่มเล่นที่ความละเอียดที่เหมาะสมที่สุดเพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดีที่สุด ซึ่งประกอบด้วยวิธีง่ายๆ ในการค้นหาสถานะของคีย์สมมติที่เชื่อมโยงกับนโยบาย HDCP โดยไม่ต้องสร้าง MediaKeySession หรือดึงข้อมูลใบอนุญาตจริง ทั้งนี้ คุณไม่จำเป็นต้องแนบ MediaKeys กับองค์ประกอบเสียงหรือวิดีโอ

HDCP Policy Check API ทำงานได้ง่ายๆ โดยเรียกใช้ mediaKeys.getStatusForPolicy() ด้วยออบเจ็กต์ที่มีคีย์ minHdcpVersion และค่าที่ถูกต้อง หาก HDCP พร้อมใช้งานในเวอร์ชันที่ระบุ สัญญาที่ส่งกลับมาจะมีค่า MediaKeyStatus เป็น 'usable' มิเช่นนั้น คําสัญญาจะแสดงด้วยค่าข้อผิดพลาดอื่นๆ ที่เป็น MediaKeyStatus เช่น 'output-restricted' หรือ 'output-downscaled' หากระบบคีย์ไม่รองรับการตรวจสอบนโยบาย HDCP เลย (เช่น ระบบคีย์ล้าง) คำสัญญาจะปฏิเสธ

โดยสรุปแล้ว นี่คือวิธีการทำงานของ API ในปัจจุบัน ไปที่ตัวอย่างอย่างเป็นทางการ เพื่อลองใช้ HDCP ทุกเวอร์ชัน

const config = [{
  videoCapabilities: [{
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    robustness: 'SW_SECURE_DECODE' // Widevine L3
  }]
}];

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(mediaKeySystemAccess => mediaKeySystemAccess.createMediaKeys())
.then(mediaKeys => {

  // Get status for HDCP 2.2
  return mediaKeys.getStatusForPolicy({ minHdcpVersion: '2.2' })
  .then(status => {
    if (status !== 'usable')
      return Promise.reject(status);

    console.log('HDCP 2.2 can be enforced.');
    // TODO: Fetch high resolution protected content...
  });
})
.catch(error => {
  // TODO: Fallback to fetch license or stream low-resolution content...
});

พร้อมให้ทดลองใช้จากต้นทาง

ก่อนหน้านี้เราได้เพิ่มฟีเจอร์ HDCP Policy Check API ใน Chrome 69 สำหรับเดสก์ท็อป (ChromeOS, Linux, Mac และ Windows) เพื่อรับความคิดเห็นจากนักพัฒนาเว็บ

ช่วงทดลองใช้สิ้นสุดลงเรียบร้อยแล้วในเดือนพฤศจิกายน 2018

ความตั้งใจในการทดสอบ | ตัวติดตาม Chromestatus | ข้อบกพร่อง Chromium

การปฏิบัติตามข้อกำหนดของ MSE PTS/DTS

ตอนนี้ช่วงที่บัฟเฟอร์และค่าระยะเวลาที่รายงานจะตามช่วงเวลาการประทับเวลาของการนำเสนอ (PTS) แทนที่จะเป็นช่วงเวลาการถอดรหัส (DTS) ในส่วนขยายแหล่งที่มาของสื่อ (MSE)

ในตอนที่ MSE เป็นเวอร์ชันใหม่ เราได้ทดสอบการใช้งาน Chrome กับ WebM และ MP3 ซึ่งเป็นรูปแบบสตรีมสื่อบางรูปแบบที่ไม่มีความแตกต่างระหว่าง PTS และ DTS และก็ทำงานได้เป็นปกติจนกระทั่งมีการเพิ่ม ISO BMFF (หรือที่เรียกว่า MP4) คอนเทนเนอร์นี้มักจะมีการนำเสนอที่ไม่เรียงตามลำดับกับสตรีมเวลาที่ถอดรหัส (เช่น สำหรับตัวแปลงรหัส เช่น H.264) ซึ่งทำให้ DTS และ PTS แตกต่างกัน ซึ่งทำให้ Chrome รายงาน (โดยปกติจะเล็กน้อย) กับช่วงบัฟเฟอร์และค่าระยะเวลาที่ต่างจากที่คาดไว้ ลักษณะการทำงานแบบใหม่นี้จะทยอยเปิดตัวใน Chrome 69 และทำให้การใช้งาน MSE เป็นไปตามข้อกำหนด MSE

แต้ม/DTS
PTS/DTS

การเปลี่ยนแปลงนี้ส่งผลต่อ MediaSource.duration (ซึ่งส่งผลให้เกิด HTMLMediaElement.duration) SourceBuffer.buffered (ซึ่งส่งผลให้เกิด HTMLMediaElement.buffered) และSourceBuffer.remove(start, end))

หากไม่แน่ใจว่าใช้วิธีการใดในการรายงานช่วงที่บัฟเฟอร์และค่าระยะเวลาที่บัฟเฟอร์ไว้ ให้ไปที่หน้า chrome://media-internals ภายในและค้นหา "ChunkDemuxer: การบัฟเฟอร์โดย PTS" หรือ"ChunkDemuxer: บนอุปกรณ์นี้ "บัฟเฟอร์โดย DTS" ในบันทึก

ความตั้งใจในการใช้งาน | ข้อบกพร่อง Chromium

การจัดการความตั้งใจในการดูสื่อบน Android Go

Android Go เป็น Android เวอร์ชันน้ำหนักเบาที่ออกแบบมาสำหรับสมาร์ทโฟนระดับเริ่มต้น ด้วยเหตุนี้ แพลตฟอร์มนี้จึงไม่จำเป็นว่าจะต้องมาพร้อมกับแอปพลิเคชันการดูสื่อบางประเภท ดังนั้นหากผู้ใช้พยายามเปิดวิดีโอที่ดาวน์โหลด ก็จะไม่มีแอปพลิเคชันใดๆ มารองรับ Intent ดังกล่าว

ในการแก้ปัญหานี้ ตอนนี้ Chrome 69 บน Android Go จะคอยตรวจจับ Intent ในการดูสื่อ เพื่อให้ผู้ใช้สามารถดูเสียง วิดีโอ และรูปภาพที่ดาวน์โหลดไว้ กล่าวคือ จะแทนที่ แอปพลิเคชันการดูที่ขาดหายไป

ALT_TEXT_HERE
ตัวแฮนเดิล Intent ของสื่อ

โปรดทราบว่าฟีเจอร์นี้ของ Chrome จะเปิดใช้งานบนอุปกรณ์ Android ทั้งหมดที่ใช้ Android O ขึ้นไปและมี RAM ไม่เกิน 1 GB

ข้อบกพร่อง Chromium

การนำเหตุการณ์ที่ "หยุด" สำหรับองค์ประกอบสื่อโดยใช้ MSE

ระบบจะเพิ่มเหตุการณ์ที่ "หยุดทำงาน" ในองค์ประกอบสื่อหากการดาวน์โหลดข้อมูลสื่อไม่สำเร็จเป็นเวลาประมาณ 3 วินาที เมื่อใช้ Media Source Extensions (MSE) เว็บแอปจะจัดการการดาวน์โหลด และองค์ประกอบสื่อจะไม่ทราบความคืบหน้า ซึ่งทำให้ Chrome เพิ่มเหตุการณ์ "หยุด" ในช่วงเวลาที่ไม่เหมาะสมเมื่อเว็บไซต์ไม่ได้เพิ่มข้อมูลสื่อใหม่ต่อท้ายด้วย SourceBuffer.appendBuffer() ในช่วง 3 วินาทีที่ผ่านมา

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

มีเจตนาเลิกใช้งานและนำออก | ตัวติดตาม Chromestatus | ข้อบกพร่อง Chromium