Chrome 63/64 中的媒体更新

François Beaufort
François Beaufort
GitHub

媒体功能 - 解码信息 API

如今，Web 开发者依赖 isTypeSupported() 或 canPlayType() 来大致了解某些媒体是否可以解码。不过，真正的问题应该是：“它在这款设备上的表现如何？”

这正是提议的 Media Capabilities 想要解决的问题之一：提供一个 API，用于根据编解码器、配置文件、分辨率、比特率等信息查询浏览器的设备解码能力。它会根据浏览器记录的先前播放统计信息，公开播放是否应流畅且省电等信息。

简而言之，以下是 Decoding Info API 目前的运作方式。查看官方示例。

const mediaConfig = {
  type: 'media-source', // or 'file'
  audio: {
    contentType: 'audio/webm; codecs=opus',
    channels: '2', // audio channels used by the track
    bitrate: 132266, // number of bits used to encode a second of audio
    samplerate: 48000 // number of samples of audio carried per second
  },
  video: {
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    width: 1920,
    height: 1080,
    bitrate: 2646242, // number of bits used to encode a second of video
    framerate: '25' // number of frames used in one second
  }
};

navigator.mediaCapabilities.decodingInfo(mediaConfig).then(result => {
  console.log('This configuration is' +
      (result.supported ? '' : ' NOT') + ' supported,' +
      (result.smooth ? '' : ' NOT') + ' smooth and' +
      (result.powerEfficient ? '' : ' NOT') + ' power efficient.');
});

您可以尝试不同的媒体配置，直到找到最佳配置（smooth 和 powerEfficient），然后使用该配置播放相应的媒体流。顺便说一下，Chrome 的当前实现基于之前记录的播放信息。当丢帧百分比小于 10% 时，它将 smooth 定义为 true；当超过 50% 的帧由硬件解码时，它将 powerEfficient 定义为 true。小帧始终被视为节能帧。

我建议您使用类似于以下代码段的代码来检测可用性，并针对不支持此 API 的浏览器回退到当前实现。

function isMediaConfigSupported(mediaConfig) {

  const promise = new Promise((resolve, reject) => {
    if (!('mediaCapabilities' in navigator)) {
      return reject('MediaCapabilities API not available');
    }
    if (!('decodingInfo' in navigator.mediaCapabilities)) {
      return reject('Decoding Info not available');
    }
    return resolve(navigator.mediaCapabilities.decodingInfo(mediaConfig));
  });

  return promise.catch(_ => {
    let fallbackResult = {
      supported: false,
      smooth: false, // always false
      powerEfficient: false // always false
    };
    if ('video' in mediaConfig) {
      fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.video.contentType);
      if (!fallbackResult.supported) {
        return fallbackResult;
      }
    }
    if ('audio' in mediaConfig) {
      fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.audio.contentType);
    }
    return fallbackResult;
  });
}

可用于源试用

为了尽可能多地收集开发者在使用解码信息 API（媒体功能的一部分）时提供的反馈，我们之前已在 Chrome 64 中以源试用版的形式添加了此功能。

该试验已于 2018 年 4 月成功结束。

实验意向 | 发布意向 | Chromestatus 跟踪器 | Chromium Bug

在 Windows 10 上播放 HDR 视频

高动态范围 (HDR) 视频的对比度更高，可呈现出精准、细致的阴影和令人惊艳的高光，清晰度也比以往更高。此外，支持广色域意味着色彩更加鲜艳。

模拟的 SDR 与 HDR 对比（如需查看真实的 HDR 效果，需要使用 HDR 显示屏）
模拟的 SDR 与 HDR 对比（如需查看真实的 HDR 效果，需要使用 HDR 显示屏）

由于 Chrome 现在支持在 Windows 10 Fall Creator Update 中播放 VP9 Profile 2 10 位视频，因此当 Windows 10 处于 HDR 模式时，Chrome 还支持 HDR 视频播放。从技术角度来看，Chrome 64 现在支持 scRGB 色彩配置文件，这反过来又允许媒体以 HDR 格式播放。

您可以在 YouTube 上观看《The World in HDR in 4K (ULTRA HD)》，尝试一下 HDR 效果，并通过查看 YouTube 播放器质量设置来确认视频是否以 HDR 格式播放。

YouTube 播放器画质设置（支持 HDR）
YouTube 播放器画质设置（支持 HDR）

您目前只需要 Windows 10 秋季创意者更新、兼容 HDR 的显卡和显示屏（例如 NVIDIA 10 系列显卡、LG HDR 电视或显示器），并在 Windows 显示设置中开启 HDR 模式。

Web 开发者可以使用最新的 color-gamut 媒体查询检测输出设备支持的大致色域，并使用 screen.colorDepth 检测用于在屏幕上显示颜色的位数。以下是一种使用这些常量来检测是否支持 VP9 HDR 的方法：

// Detect if display is in HDR mode and if browser supports VP9 HDR.
function canPlayVp9Hdr() {

  // TODO: Adjust VP9 codec string based on your video encoding properties.
  return (window.matchMedia('(color-gamut: p3)').matches &&
      screen.colorDepth >= 48 &&
      MediaSource.isTypeSupported('video/webm; codecs="vp09.02.10.10.01.09.16.09.01"'))
}

上述示例中传递给 isTypeSupported() 的带有 Profile 2 的 VP9 编解码器字符串需要根据您的视频编码属性进行更新。

请注意，目前还无法在 CSS、canvas、图片和受保护的内容中定义 HDR 颜色。Chrome 团队正在努力解决此问题。敬请期待！

适用于 Windows 和 Mac 的永久许可

加密媒体扩展程序 (EME) 中的持久许可意味着许可可以持久保存在设备上，以便应用将许可加载到内存中，而无需向服务器发送其他许可请求。以下是 EME 中如何支持离线播放。

在此之前，只有 ChromeOS 和 Android 平台支持永久许可。现在情况已不再如此。现在，在 Windows 和 Mac 上，Chrome 64 也支持在设备离线时通过 EME 播放受保护的内容。

const config = [{
  sessionTypes: ['persistent-license'],
  videoCapabilities: [{
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    robustness: 'SW_SECURE_DECODE' // Widevine L3
  }]
}];

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(access => {
  // User will be able to watch encrypted content while being offline when
  // license is stored locally on device and loaded later.
})
.catch(error => {
  // Persistent licenses are not supported on this platform yet.
});

您可以自行尝试持久许可，方法是查看示例媒体 PWA 并按以下步骤操作：

  1. 前往 https://biograf-155113.appspot.com/ttt/episode-2/
  2. 点击“设为可离线使用”，然后等待视频下载完成。
  3. 关闭互联网连接。
  4. 点击“播放”按钮，即可观看视频！

媒体预加载默认设置为“metadata”

为了与 Chrome 桌面版与其他浏览器的实现保持一致，现在将 <video> 和 <audio> 元素的默认预加载值设置为 "metadata"，以减少带宽和资源使用量。从 Chrome 64 开始，此新行为仅适用于未设置预加载值的情况。请注意，当 MediaSource 附加到媒体元素时，预加载属性的提示会被舍弃，因为网站会自行处理预加载。

换句话说，<video> 预加载值现在为 "metadata"，而 <video preload="auto"> 预加载值保持为 "auto"。不妨试试官方示例。

发布意向 | Chromestatus 跟踪器 | Chromium bug

不支持的 playbackRate 会引发异常

根据 HTML 规范变更，当媒体元素的 playbackRate 设置为 Chrome 不支持的值（例如负值）时，Chrome 63 中会抛出 "NotSupportedError" DOMException。

const audio = document.querySelector('audio');
try {
  audio.playbackRate = -1;
} catch(error) {
  console.log(error.message); // Failed to set the playbackRate property
}

顺便说一下，Chrome 的当前实现会在 playbackRate 为负、小于 0.0625 或大于 16 时引发此异常。不妨试用一下官方示例，看看实际效果。

发布意向 | Chromestatus 跟踪器 | Chromium bug

后台视频轨道优化

Chrome 团队一直在努力寻找延长电池续航时间的新方法，Chrome 63 也不例外。

如果视频不包含任何音轨，则在 Chrome 桌面版（Windows、Mac、Linux 和 ChromeOS）中于后台（例如在不可见的标签页中）播放时，该视频将自动暂停。这是对之前一项类似更改的后续跟进，该更改仅适用于 Chrome 62 中的 MSE 视频。

Chromium Bug

移除对极端 playbackRate 的静音

在 Chrome 64 之前，当 playbackRate 低于 0.5 或高于 4 时，声音会被静音，因为音质会明显下降。由于 Chrome 已改用波形相似度重叠相加 (WSOLA) 方法来降低音质，因此不再需要将声音静音。这意味着您现在可以以极慢和极快的速度播放声音。

Chromium Bug