Chrome 69 中的媒体更新

François Beaufort
François Beaufort

AV1 视频解码器

Chromestatus Tracker | Chromium 错误

EME:查询加密方案支持

某些平台或关键系统仅支持 CENC 模式,而另一些平台或密钥系统仅支持 CBCS 模式。还有一些设备也可以同时支持这两者。这两种加密方案不兼容,因此 Web 开发者必须能够智能地选择要提供什么内容。

为避免必须确定在哪个平台上检查“已知”加密方案支持,系统会在 MediaKeySystemMediaCapability 字典添加一个新的 encryptionScheme 密钥,以允许网站指定可在加密媒体扩展 (EME) 中使用的加密方案。

新的 encryptionScheme 键可以是以下两个值之一:

  • 'cenc' AES-CTR 模式完整采样和视频 NAL 下采样加密。
  • 'cbcs' AES-CBC 模式部分视频 NAL 模式加密。

如果未指定,则表示接受任何加密方案。请注意,Clear Key 始终支持 'cenc' 架构。

以下示例展示了如何查询具有不同加密方案的两个配置。在这种情况下,系统只会选择其中一个选项。

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']
    },
  ]);

在下面的示例中,仅查询了一项具有两种不同加密方案的配置。在这种情况下,Chrome 会舍弃它不支持的所有功能对象,因此累积的配置可能包含一种加密方案,或同时包含这两种加密方案。

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 Tracker | Chromium 错误

EME:HDCP 政策检查

如今,HDCP 已成为流式传输高分辨率受保护内容的常见政策要求。想要强制执行 HDCP 政策的 Web 开发者必须等待许可交换完成,或者开始以低分辨率流式传输内容。这种情况不尽人意,而 HDCP Policy Check API 旨在解决这一问题。

该 API 允许 Web 开发者查询是否可以强制执行特定的 HDCP 政策,以便以最佳分辨率开始播放视频,从而提供最佳用户体验。它包含一个简单的方法,用于查询与 HDCP 政策关联的假设密钥的状态,而无需创建 MediaKeySession 或提取实际许可。它也不需要将 MediaKeys 附加到任何音频或视频元素。

HDCP Policy Check API 只需使用具有 minHdcpVersion 键和有效值的对象调用 mediaKeys.getStatusForPolicy() 即可。如果指定版本的 HDCP 可用,返回的 promise 解析为 MediaKeyStatus'usable'。否则,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...
});

可用于源试用

为了获得 Web 开发者的反馈,我们之前在桌面版 Chrome 69(ChromeOS、Linux、Mac 和 Windows)中添加了 HDCP Policy Check API 功能。

试用期已于 2018 年 11 月成功结束。

实验意图 | Chromestatus Tracker | Chromium 错误

MSE PTS/DTS 合规性

缓冲范围和时长值现在通过呈现时间戳 (PTS) 间隔进行报告,而不是通过媒体来源扩展 (MSE) 中的解码时间戳 (DTS) 间隔进行报告。

当 MSE 是新的时,针对 WebM 和 MP3(一些 PTS 和 DTS 之间没有区别的媒体流格式)测试了 Chrome 的实现。在添加 ISO BMFF(也称为 MP4)之前,它一直运行正常。此容器常常包含无序的呈现与解码时间流(例如 H.264 等编解码器),导致 DTS 和 PTS 有所不同。这导致 Chrome 报告(通常只是略微)与预期不同的缓冲范围和时长值。这种新行为将在 Chrome 69 中逐步推出,并使其 MSE 实现符合 MSE 规范

PTS/DTS
PTS/DTS

此变更会影响 MediaSource.duration(继而影响 HTMLMediaElement.duration)、SourceBuffer.buffered(继而影响 HTMLMediaElement.buffered)SourceBuffer.remove(start, end))。

如果您不确定使用哪种方法报告缓冲范围和时长值,可以转到内部 chrome://media-internals 页面,并在日志中搜索“ChunkDemuxer: buffering by PTS”或“ChunkDemuxer: buffering by DTS”。

要实现的意图 | Chromium 错误

在 Android Go 上处理媒体视图 intent

Android Go 是专为入门级智能手机设计的轻量级 Android 版本。为此,它未必会搭载某些媒体观看应用,因此,如果用户尝试打开已下载的视频,则没有任何应用可处理该 intent。

为了解决此问题,Android Go 上的 Chrome 69 现在会监听媒体观看 intent,以便用户可以查看下载的音频、视频和图片。换言之,它取代了缺失的查看应用。

ALT_TEXT_HERE
媒体 intent 处理程序

请注意,所有搭载 Android O 及更高版本的 Android 设备(RAM 不超过 1 GB)都会启用此 Chrome 功能。

Chromium 错误

使用 MSE 移除了媒体元素的“停滞”事件

如果媒体数据的下载未能持续约 3 秒,媒体元素上将引发“停滞”事件。使用媒体来源扩展 (MSE) 时,Web 应用会管理下载,但媒体元素不知道其进度。这会导致 Chrome 在每次网站未在过去 3 秒内使用 SourceBuffer.appendBuffer() 附加新媒体数据块时,适时地引发“停滞”事件。

由于网站可能会决定以低频率附加大量数据,因此该信号对缓冲运行状况没有用处。使用 MSE 移除媒体元素的“停滞”事件可以消除混淆,并让 Chrome 更加符合 MSE 规范。请注意,不使用 MSE 的媒体元素将继续像现在一样引发“停滞”事件。

有意废弃和移除 | Chromestatus Tracker | Chromium 错误