Update media di Chrome 69

François Beaufort
François Beaufort
GitHub

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.

PTS/DTS
PTS/DTS

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.

ALT_TEXT_HERE
Pengendali intent media

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

Bug Chromium

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