- Chrome รองรับการถอดรหัสวิดีโอ AV1
- การค้นหาเกี่ยวกับรูปแบบการเข้ารหัสที่รองรับผ่าน EME พร้อมใช้งานแล้ว
- นักพัฒนาเว็บจะทดสอบกับการค้นหาว่าจะบังคับใช้นโยบาย HDCP บางอย่างได้หรือไม่
- ส่วนขยายแหล่งที่มาของสื่อใช้ PTS สำหรับช่วงที่บัฟเฟอร์และค่าระยะเวลา
- ผู้ใช้ Android Go สามารถเปิดเสียง วิดีโอ และรูปภาพที่ดาวน์โหลดไว้ใน Chrome ได้
- เหตุการณ์หยุดนิ่งสำหรับองค์ประกอบสื่อที่ใช้ MSE จะถูกนำออก
ตัวถอดรหัสวิดีโอ AV1
ตัวติดตามสถานะ Chrome | ข้อบกพร่องของ 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 จะทิ้งออบเจ็กต์ความสามารถทั้งหมด ไม่สนับสนุน ดังนั้น การกำหนดค่าสะสมอาจมีการเข้ารหัสเดียว สคีมหรือทั้ง 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']
}]);
ความตั้งใจในการใช้ | ตัวติดตามสถานะ Chrome | ข้อบกพร่องของ Chromium
EME: การตรวจสอบนโยบาย HDCP
ปัจจุบัน HDCP เป็นข้อกำหนดทั่วไปสำหรับการสตรีมความละเอียดสูง ของเนื้อหาที่มีการคุ้มครอง และนักพัฒนาเว็บที่ต้องการบังคับใช้นโยบาย HDCP ต้องรอให้การแลกเปลี่ยนใบอนุญาตเสร็จสมบูรณ์หรือเริ่มสตรีม เนื้อหาที่มีความละเอียดต่ำ นี่เป็นสถานการณ์ที่น่าเศร้าที่ นโยบาย HDCP ตรวจสอบ 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 เพื่อรับความคิดเห็นจากนักพัฒนาเว็บ ตรวจสอบฟีเจอร์ API ใน Chrome 69 สำหรับเดสก์ท็อป (ChromeOS, Linux, Mac และ Windows)
ช่วงทดลองใช้สิ้นสุดลงเรียบร้อยแล้วในเดือนพฤศจิกายน 2018
ความตั้งใจในการทดสอบ | ตัวติดตามสถานะ Chrome | ข้อบกพร่องของ 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
การเปลี่ยนแปลงนี้จะส่งผลต่อ MediaSource.duration
(และผลที่ตามมาคือ
HTMLMediaElement.duration
), SourceBuffer.buffered
(และผลที่ได้คือ
HTMLMediaElement.buffered)
และ SourceBuffer.remove(start, end)
หากไม่แน่ใจว่าใช้วิธีการใดในการรายงานช่วงที่บัฟเฟอร์และระยะเวลาที่บัฟเฟอร์
คุณสามารถไปที่หน้า chrome://media-internals
ภายในและค้นหา
"ChunkDemuxer: การบัฟเฟอร์โดย PTS" หรือ "ChunkDemuxer: การบัฟเฟอร์โดย DTS" ในช่วง
บันทึก
ความตั้งใจในการใช้ | ข้อบกพร่องของ Chromium
การจัดการ Intent ในการดูสื่อใน Android Go
Android Go คือ Android เวอร์ชันน้ำหนักเบาที่ออกแบบมาสำหรับรองรับการใช้งานระดับเริ่มต้น และสมาร์ทโฟน ด้วยเหตุนี้ โฆษณาอาจไม่แสดงผลพร้อมกับการดูสื่อ ดังนั้นหากผู้ใช้พยายามจะเปิดวิดีโอที่ดาวน์โหลด ก็หมายความว่า ก็จะไม่มีแอปพลิเคชันสำหรับจัดการความตั้งใจนั้น
เพื่อแก้ไขปัญหานี้ Chrome 69 ใน Android Go จะตรวจจับ Intent ในการดูสื่อ ผู้ใช้จะดูเสียง วิดีโอ และรูปภาพที่ดาวน์โหลดไว้ได้ กล่าวคือ ต้องใช้ แอปพลิเคชันการดูที่ขาดหายไป
โปรดทราบว่าฟีเจอร์นี้ของ Chrome เปิดใช้งานอยู่ในอุปกรณ์ Android ทั้งหมดที่ใช้ Android O ขึ้นไปที่มี RAM ไม่เกิน 1 GB
การนำ "หยุดทำงาน" ออก เหตุการณ์สำหรับองค์ประกอบสื่อที่ใช้ MSE
"หยุด" เพิ่มขึ้นในองค์ประกอบสื่อหากการดาวน์โหลดข้อมูลสื่อ
คืบหน้าไม่สำเร็จประมาณ 3 วินาที เมื่อใช้ส่วนขยายแหล่งที่มาของสื่อ
(MSE) เว็บแอปจะจัดการการดาวน์โหลด และองค์ประกอบสื่อไม่ทราบ
ความคืบหน้า ซึ่งทำให้ Chrome ทำงาน "ค้าง" กิจกรรมที่ไม่เหมาะสม
เมื่อใดก็ตามที่เว็บไซต์ไม่ได้ต่อท้ายกลุ่มข้อมูลสื่อใหม่
SourceBuffer.appendBuffer()
ใน 3 วินาทีที่ผ่านมา
เนื่องจากเว็บไซต์อาจตัดสินใจเพิ่มข้อมูลจำนวนมากด้วยความถี่ต่ำ ไม่ใช่สัญญาณที่มีประโยชน์เกี่ยวกับประสิทธิภาพของการบัฟเฟอร์ กำลังนำ "หยุด" ออก กิจกรรมสำหรับ องค์ประกอบสื่อที่ใช้ MSE จะช่วยขจัดความสับสนและทำให้ Chrome มีความสอดคล้องมากขึ้น ตามข้อกำหนด MSE โปรดทราบว่าองค์ประกอบสื่อที่ไม่ได้ใช้ MSE จะ ยังคงเพิ่ม "ชะลอ" ต่อได้ กิจกรรมของคุณอย่างที่เป็นอยู่ในปัจจุบัน
ตั้งใจที่จะเลิกใช้งานและนำออก | ตัวติดตามสถานะ Chrome | ข้อบกพร่องของ Chromium