Chrome 69 中的媒体更新

François Beaufort
François Beaufort

AV1 视频解码器

Chromestatus Tracker | Chromium bug

EME:查询加密架构支持

某些平台或密钥系统仅支持 CENC 模式,而有些仅支持 CBCS 模式。还有一些设备可以同时支持这两者。这两种加密架构 这两种工具是不兼容的,因此 Web 开发者必须能够明智地做出选择 提供什么内容

无需确定设备所在的平台,即可检查是否有“已知” 新的 encryptionScheme 密钥添加MediaKeySystemMediaCapability 字典,用于允许网站指定 加密媒体扩展 (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']
  }]);

意图实现 | Chromestatus Tracker | Chromium bug

EME:HDCP 政策检查

如今,HDCP 是流式传输高分辨率的常用政策要求 受保护内容。想要实施 HDCP 政策的网络开发者 必须等待许可交换完成或开始直播 以较低的分辨率显示内容。很遗憾,HDCP 政策 Check API

这项提议的 API 让网络开发者可以查询特定 HDCP 政策 可以强制以最佳分辨率开始播放 最佳用户体验它包含一种用于查询 与 HDCP 政策关联的假设密钥,无需创建 MediaKeySession或获取真实许可。它不需要 MediaKeys 附加的任何音频或视频元素。

HDCP Policy Check API 只需调用 将 mediaKeys.getStatusForPolicy() 替换为具有 minHdcpVersion 键的对象 以及有效值。如果指定版本支持 HDCP,则返回 promise 进行解析,并返回 MediaKeyStatus'usable'。否则,promise 解析为 MediaKeyStatus其他错误值,例如 'output-restricted''output-downscaled'。如果密钥系统 完全支持 HDCP 政策检查(例如 Clear Key System),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...
});

可用于源试用

为了获得网络开发者的反馈,我们之前添加了 HDCP 政策 检查桌面版 Chrome 69(ChromeOS、Linux、Mac 和 Windows)中的 API 功能。

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

有实验目的 | Chromestatus Tracker | Chromium bug

MSE PTS/DTS 合规性

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

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

<ph type="x-smartling-placeholder">
</ph> PTS/DTS <ph type="x-smartling-placeholder">
</ph> PTS/DTS

此更改会影响 MediaSource.durationHTMLMediaElement.duration)、SourceBuffer.buffered(以及 HTMLMediaElement.buffered)SourceBuffer.remove(start, end)

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

意图实现 | Chromium bug

在 Android Go 上处理媒体视图 intent

Android Go 是专为入门级用户打造的轻量级 Android 系统 智能手机。为此,它不一定会随附一些 因此如果用户尝试打开下载的视频 任何应用都无法处理该 intent。

为了解决这个问题,Android Go 上的 Chrome 69 现在会监听媒体查看 intent, 用户可以查看下载的音频、视频和图片。换句话说, 缺少查看应用的位置

<ph type="x-smartling-placeholder">
</ph> ALT_TEXT_HERE <ph type="x-smartling-placeholder">
</ph> 媒体 intent 处理程序

请注意,运行 Android 的所有 Android 设备都会启用这项 Chrome 功能 O 及更高版本,RAM 不超过 1 GB。

Chromium 错误

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

“停滞”事件会在媒体元素上引发,前提是下载媒体数据 未能播放进度大约 3 秒。在使用 Media Source Extensions 时 (MSE),Web 应用管理下载,而媒体元素不知道 进度这会导致 Chrome 引发“已停滞”错误不当的直播活动 次,每当网站未附加新媒体数据块 SourceBuffer.appendBuffer()

由于网站可能会决定以较低的频率附加大量数据, 并不是关于缓冲健康的有用信号。移除“停滞”事件 使用 MSE 的媒体元素消除了混淆,让 Chrome 更加井然有序 与 MSE 规范保持一致请注意,不使用 MSE 的媒体元素 继续引发“停滞”问题与现在一样。

打算弃用并移除 | Chromestatus Tracker | Chromium bug