- Chrome では AV1 動画のデコードがサポートされています。
- EME でサポートされている暗号化スキームをクエリできるようになりました。
- ウェブ デベロッパーは、特定の HDCP ポリシーを適用できるかどうかをクエリできます。
- Media Source Extensions は、バッファリングされた範囲と時間の値に PTS を使用するようになりました。
- Android Go をご利用の場合は、ダウンロードした音声、動画、画像を Chrome で開くことができます。
- MSE を使用するメディア要素の停止したイベントが削除されました。
AV1 動画デコーダ
Chromestatus トラッカー | Chromium のバグ
EME: 暗号化スキームのサポートのクエリ
プラットフォームや主要システムは、CENC モードのみをサポートしていますが、他のプラットフォームや主要システムは CBCS モードのみをサポートしています。また、両方をサポートできるアプリもあります。この 2 つの暗号化スキームには互換性がないため、ウェブ デベロッパーは提供するコンテンツについてインテリジェントな選択ができるようにする必要があります。
「既知の」暗号化スキームのサポートを確認するために使用しているプラットフォームを判断しなくて済むように、新しい encryptionScheme 鍵が MediaKeySystemMediaCapability 辞書に追加されます。これにより、Encrypted Media Extensions（EME）で使用できる暗号化スキームをウェブサイトで指定できるようになります。
新しい encryptionScheme キーは、次の 2 つの値のいずれかになります。
'cenc'AES-CTR モードのフルサンプルおよび動画の NAL サブサンプル暗号化。'cbcs'AES-CBC モードの部分的な動画 NAL パターン暗号化。
指定しない場合は、任意の暗号化スキームを使用できることを示します。キーの消去は常に 'cenc' スキームをサポートしています。
次の例は、暗号化スキームが異なる 2 つの構成をクエリする方法を示しています。この場合は 1 つのみ選択されます。
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 つの異なる暗号化スキームを使用する 1 つの構成のみがクエリされます。この場合、Chrome はサポートできない機能オブジェクトを破棄するため、蓄積された設定には暗号化スキームが 1 つ、または両方に含まれることがあります。
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']
}]);
実装の目的 | Chromestatus トラッカー | Chromium のバグ
EME: HDCP ポリシー チェック
現在の HDCP は、保護されたコンテンツを高解像度でストリーミングするための一般的なポリシー要件です。HDCP ポリシーを適用する場合、ウェブ デベロッパーは、ライセンス交換が完了するまで待つか、低解像度でコンテンツのストリーミングを開始する必要があります。これは悲しい状況であり、HDCP Policy Check API はその解決を目指しています。
この提案された API を使用すると、ウェブ デベロッパーは、特定の HDCP ポリシーを適用できるかどうかをクエリして、ユーザー エクスペリエンスに最適な解像度で再生を開始できます。これは、HDCP ポリシーに関連付けられている仮のキーのステータスを照会するシンプルなメソッドで構成されています。MediaKeySession の作成や、実際のライセンスの取得は必要ありません。MediaKeys を音声要素や動画要素に関連付ける必要もありません。
HDCP Policy Check API は、minHdcpVersion キーと有効な値を持つオブジェクトで mediaKeys.getStatusForPolicy() を呼び出すだけで機能します。指定されたバージョンで HDCP が利用可能な場合、返される Promise は 'usable' の MediaKeyStatus で解決されます。それ以外の場合、Promise は MediaKeyStatus の他のエラー値（'output-restricted' や 'output-downscaled' など）で解決されます。鍵システムが HDCP ポリシー チェックをまったくサポートしていない場合（鍵システムの消去など）、Promise は拒否されます。
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...
});
オリジン トライアルで利用可能
ウェブ デベロッパーからのフィードバックとして、パソコン版 Chrome 69（ChromeOS、Linux、Mac、Windows）には、HDCP Policy Check API 機能がすでに追加されています。
トライアルは 2018 年 11 月に終了しました。
テストの目的 | Chromestatus トラッカー | Chromium のバグ
MSE PTS/DTS への準拠
バッファリングされた範囲と期間の値は、Media Source Extensions（MSE）のデコード タイムスタンプ（DTS）間隔ではなく、プレゼンテーション タイムスタンプ（PTS）間隔でレポートされるようになりました。
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: buffering by PTS」または「ChunkDemuxer: buffering by DTS」を検索できます。
Android Go でのメディア表示インテントの処理
Android Go は、エントリレベルのスマートフォン向けに設計された Android の軽量バージョンです。そのため、必ずしも一部のメディア表示アプリが付属しているわけではないため、たとえばユーザーがダウンロードした動画を開こうとしても、そのインテントを処理するアプリはありません。
この問題を解決するために、Android Go の Chrome 69 は、メディア表示インテントをリッスンするようになりました。これにより、ダウンロードした音声、動画、画像をユーザーが表示できるようになります。つまり、見つからない表示アプリを置き換えます。
なお、この Chrome 機能は、RAM が 1 GB 以下の Android O 以降を搭載したすべての Android デバイスで有効です。
MSE を使用したメディア要素の「停滞」イベントの削除
メディアデータのダウンロードが約 3 秒間進行しなかった場合、メディア要素で「停滞」イベントが発生します。Media Source Extensions（MSE）を使用している場合、ウェブアプリはダウンロードを管理しますが、メディア要素は進行状況を認識しません。このため、過去 3 秒間にウェブサイトが SourceBuffer.appendBuffer() で新しいメディアデータ チャンクを追加していない場合、Chrome は不適切なタイミングで「stalled」イベントを発生させていました。
ウェブサイトでは、大量のデータを低い頻度で追加する可能性があるため、これはバッファリングの健全性に関する有用なシグナルではありません。MSE を使用してメディア要素の「停滞」イベントを削除すると、混乱が解消され、Chrome がより MSE 仕様に準拠するようになります。MSE を使用しないメディア要素では、現在と同様に引き続き「停滞」のイベントが発生します。