Chrome 69 中的媒体更新

François Beaufort
François Beaufort

AV1 视频解码器

Chromestatus Tracker | Chromium bug

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 会舍弃任何无法支持的 capability 对象,因此累积的配置可能包含一种或两种加密方案。

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

意图实现 | Chrome 状态跟踪器 | Chromium 错误

EME:HDCP 政策检查

如今,对于流式传输高分辨率受保护内容HDCP 是一项常见的政策要求。而想要强制执行 HDCP 政策的网站开发者必须等待许可交换完成,或者开始以低分辨率流式传输内容。这属于令人遗憾的情况,HDCP Policy Check API 旨在解决这一问题。

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

HDCP Policy Check API 只需使用具有 minHdcpVersion 键和有效值的对象调用 mediaKeys.getStatusForPolicy() 即可。如果指定版本支持 HDCP,则返回的 promise 会解析为 MediaKeyStatus'usable'。否则,该 promise 会使用 MediaKeyStatus其他错误值(例如 'output-restricted''output-downscaled')进行解析。如果密钥系统完全不支持 HDCP 政策检查(例如 Clear Key 系统),则 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 月成功结束。

Intent to Experiment | Chromestatus Tracker | Chromium Bug

MSE PTS/DTS 合规性

现在,媒体源扩展 (MSE) 中缓冲区范围和时长值的报告方式是按呈现时间戳 (PTS) 间隔,而不是按解码时间戳 (DTS) 间隔。

MSE 刚推出时,Chrome 的实现已针对 WebM 和 MP3 进行了测试,这些媒体流格式不区分 PTS 和 DTS。在添加 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 bug

在 Android Go 上处理媒体视图 intent

Android Go 是专为入门级智能手机打造的轻量级 Android 系统。为此,Android 设备不一定会随附一些媒体观看应用,例如,如果用户尝试打开下载的视频,就没有任何应用可处理该 intent。

为解决此问题,Android Go 版 Chrome 69 现在会监听媒体观看 intent,以便用户查看下载的音频、视频和图片。换句话说,它会取代缺少的观看应用。

ALT_TEXT_HERE
媒体 intent 处理脚本

请注意,在搭载 Android O 及更高版本且 RAM 不超过 1 GB 的所有 Android 设备上,此 Chrome 功能均处于启用状态。

Chromium 错误

移除了使用 MSE 的媒体元素的“卡顿”事件

如果下载媒体数据未能持续 3 秒左右,媒体元素上会引发“stalled”事件。使用媒体源扩展 (MSE) 时,Web 应用会管理下载,而媒体元素无法知晓下载进度。这导致每当网站在过去 3 秒内未附加包含 SourceBuffer.appendBuffer() 的新媒体数据块时,Chrome 都会在不恰当的时间引发“已暂停”事件。

由于网站可能会决定以低频率附加大量数据,因此这不是一个有关缓冲健康状况的实用信号。移除使用 MSE 的媒体元素的“卡顿”事件可消除混淆,使 Chrome 更符合 MSE 规范。请注意,不使用 MSE 的媒体元素将继续像现在一样引发“stalled”事件。

废弃和移除的意图 | Chromestatus 跟踪器 | Chromium bug