Update media di Chrome 69

François Beaufort
François Beaufort

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.

PTS/DTS
PTS/DTS

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.

ALT_TEXT_HERE
Pengendali intent media

Perhatikan bahwa fitur Chrome ini diaktifkan di semua perangkat Android yang menjalankan Android O dan seterusnya dengan RAM 1 GB atau kurang.

Bug Chromium

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