- Chrome mendukung dekode video AV1.
- Membuat kueri skema enkripsi mana yang didukung melalui EME kini tersedia.
- Developer web dapat bereksperimen dengan mengajukan 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 tertahan untuk elemen media yang menggunakan MSE akan dihapus.
Decoder video AV1
Pelacak Chromestatus | Bug Chromium
EME: Meminta dukungan skema enkripsi
Beberapa platform atau sistem kunci hanya mendukung mode CENC, sementara yang lain hanya mendukung Mode CBCS. Ada lagi yang dapat mendukung keduanya. Kedua skema enkripsi ini tidak kompatibel, sehingga pengembang web harus mampu membuat pilihan yang cerdas konten yang akan ditayangkan.
Agar tidak perlu menentukan platform mana yang mereka gunakan untuk memeriksa "dikenal"
dukungan skema enkripsi, kunci encryptionScheme
baru ditambahkan di
Kamus MediaKeySystemMediaCapability
untuk mengizinkan situs menentukan
skema enkripsi mana yang dapat digunakan di Encrypted Media Extensions (EME).
Kunci encryptionScheme
baru dapat berupa salah satu dari dua nilai:
'cenc'
sampel lengkap mode AES-CTR dan enkripsi subsampel NAL video.'cbcs'
Enkripsi sebagian pola NAL video mode AES-CBC.
Jika tidak ditentukan, hal ini menunjukkan bahwa skema enkripsi dapat diterima. Catatan
bahwa Clear Key akan selalu mendukung skema 'cenc'
.
Contoh di bawah ini menunjukkan cara membuat kueri dua konfigurasi dengan skema enkripsi. 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']
},
]);
Dalam contoh di bawah ini, hanya satu konfigurasi dengan dua enkripsi yang berbeda skema kustom yang dikueri. Dalam hal ini, Chrome akan menghapus objek kapabilitas apa pun yang tidak dapat didukung, jadi konfigurasi yang terakumulasi dapat berisi satu enkripsi skema 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 Mengimplementasikan | Pelacak Chromestatus | Bug Chromium
EME: pemeriksaan kebijakan HDCP
Saat ini HDCP adalah persyaratan kebijakan umum untuk streaming resolusi tinggi konten yang dilindungi. Dan developer web yang ingin menerapkan kebijakan HDCP harus menunggu hingga pertukaran lisensi selesai atau memulai streaming konten dengan resolusi rendah. Ini adalah situasi yang menyedihkan karena Kebijakan HDCP Check API bertujuan untuk menyelesaikan.
API yang diusulkan ini memungkinkan developer web menanyakan apakah kebijakan HDCP tertentu
dapat ditegakkan sehingga pemutaran dapat
dimulai pada resolusi optimal untuk
pengalaman pengguna terbaik. Ini terdiri dari metode sederhana
untuk melakukan kueri status dari
kunci hipotetis yang terkait dengan
kebijakan HDCP, tanpa perlu membuat
MediaKeySession
atau ambil lisensi sungguhan. MediaKeys
tidak harus berupa
disertakan ke elemen audio
atau video apa pun.
HDCP Policy Check API berfungsi
cukup dengan memanggil
mediaKeys.getStatusForPolicy()
dengan objek yang memiliki kunci minHdcpVersion
dan nilai yang valid. Jika HDCP tersedia di versi yang ditentukan, properti yang ditampilkan
promise akan di-resolve dengan MediaKeyStatus
dari 'usable'
. Jika tidak, promise
diselesaikan dengan nilai error lainnya dari MediaKeyStatus
seperti
'output-restricted'
atau 'output-downscaled'
. Jika sistem kunci tidak
mendukung Pemeriksaan Kebijakan HDCP (misalnya Clear Key System), promise ditolak.
Secara singkat, berikut adalah 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 Kebijakan HDCP Periksa fitur API di Chrome 69 untuk Desktop (ChromeOS, Linux, Mac, dan Windows).
Uji coba berhasil berakhir pada November 2018.
Niat untuk Bereksperimen | Pelacak Chromestatus | Bug Chromium
Kepatuhan MSE PTS/DTS
Rentang buffer dan nilai durasi kini dilaporkan oleh Stempel Waktu Presentasi Interval (PTS), bukan berdasarkan interval Stempel Waktu Dekode (DTS) dalam Media Ekstensi Sumber (MSE).
Saat MSE masih baru, implementasi Chrome diuji terhadap WebM dan MP3, format streaming media yang tidak memiliki perbedaan antara PTS dan DTS. Dan standar itu bekerja dengan baik sampai ISO BMFF (alias MP4) ditambahkan. Penampung ini sering berisi streaming waktu presentasi yang tidak berurutan vs. dekode (untuk codec seperti H.264) yang menyebabkan perbedaan antara DTS dan PTS. Hal itu menyebabkan Chrome akan melaporkan (biasanya hanya sedikit) rentang dan durasi yang di-buffer yang berbeda dari yang diharapkan. Perilaku baru ini akan diluncurkan secara bertahap di Chrome 69 dan membuat penerapan MSE-nya sesuai dengan spesifikasi MSE.
Perubahan ini memengaruhi MediaSource.duration
(dan akibatnya
HTMLMediaElement.duration
), SourceBuffer.buffered
(dan akibatnya
HTMLMediaElement.buffered)
, dan SourceBuffer.remove(start, end)
.
Jika Anda tidak yakin metode mana yang digunakan untuk melaporkan rentang dan durasi yang di-buffer
Anda dapat membuka halaman chrome://media-internals
internal dan mencari
"ChunkDemuxer: buffering oleh PTS" atau "ChunkDemuxer: buffering oleh DTS" di
log.
Niat untuk Mengimplementasikan | Bug Chromium
Penanganan intent tampilan media di Android Go
Android Go adalah versi ringan Android yang dirancang untuk entry-level di ponsel pintar. Oleh karena itu, video tidak harus disertai dengan beberapa penayangan media aplikasi, jadi jika misalnya pengguna mencoba membuka video yang diunduh, mereka tidak akan memiliki aplikasi apa pun untuk menangani maksud itu.
Untuk memperbaikinya, Chrome 69 di Android Go sekarang memproses intent melihat media sehingga pengguna dapat melihat audio, video, dan gambar yang didownload. Dengan kata lain, dibutuhkan tempat aplikasi penampil yang hilang.
Perlu diperhatikan bahwa fitur Chrome ini diaktifkan di semua perangkat Android yang menjalankan Android O dan seterusnya dengan RAM 1 GB atau kurang.
Penghapusan "terhenti" untuk elemen media yang menggunakan MSE
"terhenti" dipicu pada elemen media jika download data media telah
gagal berjalan selama sekitar 3 detik. Saat menggunakan Ekstensi Sumber Media
(MSE), aplikasi web mengelola download dan elemen media tidak mengetahui
progresnya. Hal ini menyebabkan Chrome memunculkan kata "macet" acara yang tidak pantas
kali ketika {i>website<i} belum menambahkan potongan
data media baru dengan
SourceBuffer.appendBuffer()
dalam 3 detik terakhir.
Karena situs web dapat memutuskan untuk menambahkan potongan data yang besar dengan frekuensi rendah, hal ini bukan merupakan sinyal yang berguna tentang kondisi buffering. Menghapus "berhenti" acara untuk elemen media yang menggunakan MSE mengatasi kebingungan dan menjadikan Chrome lebih selaras dengan spesifikasi MSE. Perhatikan bahwa elemen media yang tidak menggunakan MSE akan terus meningkatkan "macet" yang berbeda seperti yang terjadi saat ini.
Rencana Penghentian dan Penghapusan | Pelacak Chromestatus | Bug Chromium