- Chrome mendukung dekode video AV1.
- Kueri skema enkripsi mana yang didukung melalui EME kini tersedia.
- Developer web dapat bereksperimen dengan melakukan kueri apakah kebijakan HDCP tertentu dapat diterapkan.
- Ekstensi Sumber Media kini menggunakan PTS untuk rentang yang di-buffer dan nilai durasi.
- Pengguna Android Go dapat membuka audio, video, dan gambar yang didownload di Chrome.
- Peristiwa terhenti untuk elemen media yang menggunakan MSE akan dihapus.
Decoder video AV1
Pelacak Chromestatus | Bug Chromium
EME: Membuat kueri dukungan skema enkripsi
Beberapa platform atau sistem kunci hanya mendukung mode CENC, sementara yang lain hanya mendukung mode CCBCS. Ada juga yang dapat mendukung keduanya. Kedua skema enkripsi ini tidak kompatibel, sehingga developer web harus dapat membuat pilihan cerdas terkait konten yang akan ditayangkan.
Agar tidak perlu menentukan platform mana yang digunakan untuk memeriksa dukungan skema
enkripsi yang "dikenal", kunci encryptionScheme
baru ditambahkan di
kamus MediaKeySystemMediaCapability
agar situs dapat menentukan
skema enkripsi yang dapat digunakan dalam Ekstensi Media Terenkripsi (EME).
Kunci encryptionScheme
baru dapat berupa salah satu dari dua nilai:
'cenc'
sampel lengkap mode AES-CTR dan enkripsi subsampel NAL video.'cbcs'
Enkripsi pola NAL video parsial mode AES-CBC.
Jika tidak ditentukan, ini menunjukkan bahwa skema enkripsi dapat diterima. Perlu
diketahui bahwa Clear Key selalu mendukung skema 'cenc'
.
Contoh di bawah menunjukkan cara membuat kueri dua konfigurasi dengan skema enkripsi yang berbeda. Dalam hal ini, hanya satu yang akan dipilih.
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']
},
]);
Pada contoh di bawah, hanya satu konfigurasi dengan dua skema enkripsi berbeda yang dikueri. Dalam hal ini, Chrome akan menghapus objek kemampuan apa pun yang tidak dapat didukung, sehingga konfigurasi yang terakumulasi dapat berisi satu skema enkripsi atau keduanya.
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']
}]);
Niat untuk Diimplementasikan | Pelacak Status Chrome | Bug Chromium
EME: Pemeriksaan kebijakan HDCP
Saat ini, HDCP adalah persyaratan kebijakan umum untuk streaming konten yang dilindungi dengan resolusi tinggi. Selain itu, developer web yang ingin menerapkan kebijakan HDCP harus menunggu hingga pertukaran lisensi selesai atau memulai streaming konten pada resolusi rendah. Ini adalah situasi menyedihkan yang ingin diselesaikan oleh HDCP Policy Check API.
API yang diusulkan ini memungkinkan developer web untuk menanyakan apakah kebijakan HDCP tertentu
dapat diterapkan sehingga pemutaran dapat dimulai pada resolusi optimal untuk
pengalaman pengguna terbaik. Class ini terdiri dari metode sederhana untuk membuat kueri status
kunci hipotetis yang terkait dengan kebijakan HDCP, tanpa perlu membuat
MediaKeySession
atau mengambil lisensi asli. MediaKeys
juga tidak perlu disertakan
ke elemen audio atau video apa pun.
HDCP Policy Check API berfungsi cukup dengan memanggil
mediaKeys.getStatusForPolicy()
menggunakan objek yang memiliki kunci minHdcpVersion
dan nilai yang valid. Jika HDCP tersedia pada versi yang ditentukan, promise yang ditampilkan akan diselesaikan dengan MediaKeyStatus
'usable'
. Jika tidak, promise akan diselesaikan dengan nilai error lainnya dari MediaKeyStatus
seperti 'output-restricted'
atau 'output-downscaled'
. Jika sistem kunci tidak mendukung Pemeriksaan Kebijakan HDCP sama sekali (misalnya, Clear Key System), promise akan ditolak.
Singkatnya, berikut ini cara kerja API untuk saat ini. Lihat contoh resmi untuk mencoba semua versi 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...
});
Tersedia untuk uji coba origin
Untuk mendapatkan masukan dari developer web, sebelumnya kami telah menambahkan fitur Pemeriksaan Kebijakan HDCP di Chrome 69 untuk Desktop (ChromeOS, Linux, Mac, dan Windows).
Uji coba berhasil berakhir pada November 2018.
Niat untuk Melakukan Eksperimen | Pelacak Status Chrome | Bug Chromium
Kepatuhan PTS/DTS MSE
Nilai durasi dan rentang yang mengalami buffering kini dilaporkan oleh interval Stempel Waktu Presentasi (PTS), bukan berdasarkan interval Stempel Waktu Dekode (DTS) di Ekstensi Sumber Media (MSE).
Ketika MSE masih baru, implementasi Chrome diuji terhadap WebM dan MP3, beberapa format streaming media yang tidak memiliki perbedaan antara PTS dan DTS. Dan berfungsi dengan baik sampai ISO BMFF (alias MP4) ditambahkan. Container ini sering kali berisi presentasi yang tidak berurutan versus aliran waktu dekode (untuk codec seperti H.264 misalnya) yang menyebabkan DTS dan PTS berbeda. Hal tersebut menyebabkan Chrome melaporkan (biasanya hanya sedikit) rentang yang di-buffer dan nilai durasi yang berbeda dari yang diharapkan. Perilaku baru ini akan diluncurkan secara bertahap di Chrome 69 dan membuat implementasi MSE-nya sesuai dengan spesifikasi MSE.
Perubahan ini memengaruhi MediaSource.duration
(dan akibatnya
HTMLMediaElement.duration
), SourceBuffer.buffered
(dan akibatnya
HTMLMediaElement.buffered)
, serta SourceBuffer.remove(start, end)
.
Jika tidak yakin metode mana yang digunakan untuk melaporkan rentang yang di-buffer dan nilai durasi, Anda dapat membuka halaman chrome://media-internals
internal dan menelusuri
"ChunkDemuxer: buffering by PTS" atau "ChunkDemuxer: buffering by DTS" di
log.
Intent untuk Mengimplementasikan | Bug Chromium
Penanganan intent tampilan media di Android Go
Android Go adalah versi Android ringan yang dirancang untuk smartphone entry-level. Oleh karena itu, video ini tidak selalu dikirimkan dengan beberapa aplikasi untuk melihat media, jadi jika pengguna mencoba membuka video yang didownload, misalnya, mereka tidak akan memiliki aplikasi apa pun untuk menangani intent tersebut.
Untuk memperbaikinya, Chrome 69 di Android Go kini memproses intent menonton media sehingga pengguna dapat melihat audio, video, dan gambar yang didownload. Dengan kata lain, ia menggantikan aplikasi penampil yang hilang.
Perhatikan bahwa fitur Chrome ini diaktifkan di semua perangkat Android yang menjalankan Android O dan seterusnya dengan RAM 1 GB atau kurang.
Penghapusan peristiwa "terhenti" untuk elemen media yang menggunakan MSE
Peristiwa "terhenti" akan dimunculkan di elemen media jika proses download data media
gagal berlangsung selama sekitar 3 detik. Saat menggunakan Ekstensi Sumber Media
(RKG), aplikasi web akan mengelola download dan elemen media tidak mengetahui
progresnya. Hal ini menyebabkan Chrome memunculkan peristiwa "terhenti" pada waktu yang tidak tepat setiap kali situs tidak menambahkan potongan data media baru dengan SourceBuffer.appendBuffer()
dalam 3 detik terakhir.
Karena situs mungkin memutuskan untuk menambahkan potongan besar data dengan frekuensi rendah, ini bukan sinyal yang berguna tentang kondisi buffering. Menghapus peristiwa "terhenti" untuk elemen media menggunakan MSE akan menghilangkan kebingungan dan menjadikan Chrome lebih sesuai dengan spesifikasi MSE. Perhatikan bahwa elemen media yang tidak menggunakan MSE akan terus memunculkan peristiwa "terhenti" seperti saat ini.
Rencana Penghentian Penggunaan dan Penghapusan | Pelacak Status Chrome | Bug Chromium