WebRTC 的可伸缩视频编码（SVC）扩展

除标记为非规范性的章节外，本规范中的所有编写指南、图示、示例和注释均为非规范性内容。本规范中的其他所有内容均为规范性内容。

本文档中的关键字可以、必须和应该应按照 BCP 14 [RFC2119] [RFC8174] 中所述进行解释，但仅当它们像这里所示那样全部使用大写形式出现时才如此。

本规范定义了适用于单一产品的一致性标准：实现本规范所包含接口的用户代理。

以算法或特定步骤表述的一致性要求可以采用任何方式实现，只要最终结果等效即可。特别是，本规范定义的算法旨在易于理解，而不是为了获得高性能。

使用 ECMAScript 实现本规范中所定义 API 的实现必须以与 Web IDL 规范 [WEBIDL] 中定义的 ECMAScript 绑定一致的方式实现它们，因为本规范使用了该规范及其术语。

“联播包络”一词在 [WEBRTC] 第 5.4.1 节中定义。

本规范引用了 [WEBRTC] 中定义的对象、方法、内部槽和字典。

对于可伸缩视频编码（SVC），“单会话传输” （SST）和“多会话传输”（MST）这两个术语定义于 [RFC6190]。本规范仅支持 SST，而不支持 MST。

“单实时传输协议流单传输” （SRST）一词定义于 [RFC7656] 第 3.7 节，指在单一传输中传输所有层的 SVC 实现，使用单一实时传输协议（RTP）流和同步源（SSRC）。“多 RTP 流单传输”（MRST）一词同样定义于 [RFC7656] 第 3.7 节，指在单一传输中传输所有层的实现，它使用多个 RTP 流，并为每一层使用不同的 SSRC。本规范仅支持 SRST，不支持 MRST。其 RTP 载荷规范支持 SRST 的编解码器包括 VP8 [RFC7741]、VP9 [VP9-PAYLOAD]、AV1 [AV1-RTP-SPEC]、H.264 [RFC6184] 和 H.265 [RFC7798]。

“S 模式”一词指在同一个 SSRC 上发送多个编码的可伸缩性模式。这包括 "S2T1"、"S2T1h"、 "S2T2"、 "S2T2h"、"S2T3"、"S2T3h"、"S3T1"、"S3T1h"、"S3T2"、"S3T2h"、 "S3T3" 和 "S3T3h" scalabilityMode 值。

术语选择性转发中间盒（SFM）定义于 [RFC7667] 第 3.7 节。

本规范通过扩展 RTCRtpEncodingParameters 字典，使得能够配置 SVC 的编码参数。

WebIDLpartial dictionary RTCRtpEncodingParameters {
             DOMString scalabilityMode;
};

scalabilityMode，类型为 DOMString: 仅当发送方的 kind 为 "video" 时，此成员才可以存在。当其存在时，表示要用于此流的区分大小写的可伸缩性模式标识符。可伸缩性模式定义于第 5 节。

[WEBRTC] 描述了 addTransceiver() （第 5.1 节）和 setParameters() （第 5.2 节）中的错误处理，包括使用 RTCError 来表示由于不受支持的编码参数而导致的 “hardware-encoder-error”，以及其他错误。当向 setParameters() 或 addTransceiver() 提供无效的 scalabilityMode 值时，实现会按照规定方式使用 RTCError 和其他错误。

[WEBRTC] 第 5.1 节描述了 addTransceiver() 中对 sendEncodings 的验证。为了验证 scalabilityMode，请在 addTransceiver sendEncodings 验证步骤的第 3 步之后添加以下步骤：

如果 sendEncodings 包含任何这样的编码：其 codec 值 codec 存在，并且同一编码的 scalabilityMode 值不受 codec 支持，则抛出一个 OperationError。
否则，如果 sendEncodings 包含任何这样的编码：其 scalabilityMode 值不受 kind 的已实现发送编解码器列表中的任何编解码器支持，则抛出一个 OperationError。
如果存储在 sendEncodings 中的 RTCRtpEncodingParameters 包含多个 active 成员值为 true 的编码，并且 sendEncodings 包含任何这样的编码：其 scalabilityMode 值表示“S 模式”，且其 active 成员的值为 true，则抛出一个 OperationError。

当 addTransceiver() 和 setCodecPreferences() 方法在提议/应答协商完成之前被调用时，协商出的编解码器及其能力可能尚未知晓。在这种情况下， sendEncodings 中配置的 scalabilityMode 值可能不受最终协商出的编解码器支持。但是，只有当请求的 scalabilityMode 值对任何受支持的编解码器都无效，或者请求了混合联播传输时，才会产生错误。

为了确保所需的 scalabilityMode 值能够应用，可以使用 setCodecPreferences() 来优先选择或仅包含支持所需配置的编解码器。例如，如果希望将时间可伸缩性与空间联播结合使用，则在调用 addTransceiver() 时，可以配置 sendEncodings 以发送多个具有不同分辨率的联播流，并让每个流使用时间可伸缩性。如果只有 VP8、VP9 和 AV1 编解码器实现支持时间可伸缩性，则可以使用 setCodecPreferences() 从提议中移除 H.264/AVC 编解码器，从而提高协商出支持时间可伸缩性的编解码器的可能性。

当使用 sendEncodings 通过 addTransceiver() 请求发送多个联播流时，不能请求“S 模式”。浏览器只能配置为使用多个 SSRC 和 RID 发送联播编码，或者将所有联播编码发送到单一 RTP 流上。不允许同时使用这两种联播传输技术。

[WEBRTC] 第 5.2 节描述了 setParameters() 中对 parameters 的验证。将以下条件插入导致该操作返回以 InvalidModificationError 拒绝的 promise 的条件列表中（第 6 步），该列表位于 setParameters 验证步骤中：

encodings 包含任何具有已存在的 codec 值 codec 的 encoding，且该 encoding 的 scalabilityMode 值不受 codec 支持。
sender.[[SendCodecs]] 为空并且 encodings 包含任何这样的编码：其 scalabilityMode 值不受 kind 的已实现发送编解码器列表中的任何编解码器支持。
sender.[[SendCodecs]] 不为空并且 encodings 包含任何这样的编码：其 scalabilityMode 值无法由 sender.[[SendCodecs]] 中的任何编解码器满足。
encodings 包含多个 active 成员值为 true 的编码，并且 encodings 包含任何这样的编码：其 scalabilityMode 值表示“S 模式”，且其 active 成员的值为 true。

"L1T1" 可伸缩性模式允许使用 setParameters() 关闭 SVC 编码。如果使用 setParameters() 设置了 "L1T1"，则它将在 getParameters() 的响应中返回。

在初始协商完成之前， getParameters() 会返回 encodings 中每个编码的 scalabilityMode 值，即最近一次由 addTransceiver() 或 setParameters() 设置的值。如果没有为 encodings 中的某个编码提供 scalabilityMode 值，或者某个值未成功设置，则 getParameters() 将不会为该编码返回 scalabilityMode 值。

初始协商完成后，getParameters() 会为 encodings 中在初始协商前具有值的每个编码返回当前配置的 scalabilityMode 值。该值可以不同于 addTransceiver() 或 setParameters() 中请求的值。例如，如果协商期间选中的编解码器不包括支持所需 scalabilityMode 值的编码器，则用户代理可以选择另一个值。如果配置不符合要求，可以使用 setParameters() 更改它。

如果 addTransceiver() 或 setParameters() 没有为 encodings 中的某个编码提供 scalabilityMode 值，则在初始协商完成后，getParameters() 将不会返回 scalabilityMode 值，而编码器将对该编码的 RTP 流使用编解码器的默认 scalabilityMode。每种编解码器的默认 scalabilityMode 取决于实现。默认 scalabilityMode 应该是时间可伸缩性模式之一（例如 "L1T1"、"L1T2"、"L1T3" 等）。

本节为非规范性内容。

SVC 最常用于视频会议，其中会议服务器（例如 SFM）会根据参与者的设备特性和可用带宽选择性地向其转发不同的层。在这种环境中，应用程序将与会议服务器协商要发送和接收的编解码器。但是，由于可伸缩性模式不会在提议/应答中协商，因此应用程序需要通过其他方式确定浏览器和会议服务器支持哪些可伸缩性模式。

[Media-Capabilities] API 支持发现编码器和解码器对可伸缩视频编码的支持情况。scalabilityMode 用于查询编码器是否支持某个 scalabilityMode 值，以指示它是否 “受支持”、“流畅”且“节能”。

[Media-Capabilities] API 还提供解码器对空间可伸缩性模式的支持信息。spatialScalability 指示解码器是否具有支持空间预测的能力，这要求其能够使用分辨率不同于当前分辨率的帧作为依赖项。如果将 spatialScalability 设置为 true，则解码器可以解码编码器支持的任何 scalabilityMode 值。如果将 spatialScalability 设置为 false 或不存在，则解码器无法解码空间可伸缩性模式，但可以解码编码器支持的所有其他 scalabilityMode 值。

一旦应用程序确定了哪些编解码器与 scalabilityMode 值的组合可供其使用，就需要确定其中哪些组合受 SFM 支持。一种处理方式是让 SFM 以接收器能力的形式指明它可以转发的编解码器与可伸缩性模式组合。收到 SFM 的能力后，应用程序可以计算浏览器的 RTCRtpSender 和 SFM 的接收器所支持的编解码器与 scalabilityMode 值的交集。这样可以用来确定传递给浏览器 addTransceiver() 和 setParameters() 方法的参数。

以下是一些示例：

一个解析编解码器载荷的 SFM 可能只支持不带可伸缩性的 H.264/AVC 编解码器，以及带时间可伸缩性的 VP8 编解码器。另一方面，浏览器可能能够使用时间可伸缩性编码 VP8，使用时间和空间可伸缩性编码 VP9 和 AV1，并使用时间可伸缩性编码 H.264/AVC。在此示例中，希望使用 SVC 的应用程序只能使用时间可伸缩性编码 VP8。
一个 SFM 可能仅支持使用 AV1 编解码器及 "S2T1" 和 "S2T1h" 可伸缩性模式的单流联播，而浏览器可能支持使用 "S2T1"、"S2T1h"、"S3T1" 和 "S3T1h" 模式，通过 VP9 和 AV1 编解码器编码单流联播。在此示例中，应用程序只能使用 AV1 编解码器进行最多两层的单流联播。如果应用程序希望使用三层，那么它可以决定放弃使用单流联播，转而协商多流联播。

在某些情况下，计算浏览器和 SFM 能力的交集时需要考虑 RTP 标头扩展。如果 SFM 无法解析编解码器载荷（无论是因为其设计上不这样做，还是因为载荷已加密），那么可能需要协商某个 RTP 标头扩展（例如 [AV1-RTP-SPEC] 附录 A 中定义的 AV1 依赖描述符），才能使 SFM 转发特定编解码器。为考虑这种情况，可以将转发某个编解码器所需的 RTP 标头扩展添加到 SFM 的接收器能力中。随后，应用程序可以计算浏览器的 RTCRtpSender 和 SFM 的接收器所支持的编解码器、标头扩展和 scalabilityMode 值的交集。

本规范支持的 scalabilityMode 值，以及与其关联的标识符和特征，均列于下表中。这里给出了 scalabilityMode 值的名称（区分大小写），以及 [AV1] 第 6.7.5 节中分配的可伸缩性模式标识符，以及第 9 节中所提供依赖关系图的链接。

虽然 [AV1] 和 VP9 [VP9] 规范支持表中定义的所有 scalabilityMode 值，其他编解码器规范则不支持。例如，VP8 [RFC6386]、H.264 [RFC6184] 和 H.265 [RFC7798] 仅支持时间可伸缩性（例如 "L1T2"、"L1T3"）。此外，VP8 [RFC6386]、H.264 [RFC6184] 和 H.265 [RFC7798] 仅允许在不同 SSRC 上传输联播，因此不支持“S”模式（其中多个编码在单个 RTP 流上传输）。

可伸缩性模式标识符	空间层	分辨率比率	时间层	层间依赖关系	AV1 scalability_mode_idc
"L1T1"	1		1		不适用
"L1T2"	1		2		SCALABILITY_L1T2
"L1T3"	1		3		SCALABILITY_L1T3
"L2T1"	2	2:1	1	是	SCALABILITY_L2T1
"L2T2"	2	2:1	2	是	SCALABILITY_L2T2
"L2T3"	2	2:1	3	是	SCALABILITY_L2T3
"L3T1"	3	2:1	1	是	SCALABILITY_L3T1
"L3T2"	3	2:1	2	是	SCALABILITY_L3T2
"L3T3"	3	2:1	3	是	SCALABILITY_L3T3
"L2T1h"	2	1.5:1	1	是	SCALABILITY_L2T1h
"L2T2h"	2	1.5:1	2	是	SCALABILITY_L2T2h
"L2T3h"	2	1.5:1	3	是	SCALABILITY_L2T3h
"L3T1h"	3	1.5:1	1	是
"L3T2h"	3	1.5:1	2	是
"L3T3h"	3	1.5:1	3	是
"S2T1"	2	2:1	1	否	SCALABILITY_S2T1
"S2T2"	2	2:1	2	否	SCALABILITY_S2T2
"S2T3"	2	2:1	3	否	SCALABILITY_S2T3
"S2T1h"	2	1.5:1	1	否	SCALABILITY_S2T1h
"S2T2h"	2	1.5:1	2	否	SCALABILITY_S2T2h
"S2T3h"	2	1.5:1	3	否	SCALABILITY_S2T3h
"S3T1"	3	2:1	1	否	SCALABILITY_S3T1
"S3T2"	3	2:1	2	否	SCALABILITY_S3T2
"S3T3"	3	2:1	3	否	SCALABILITY_S3T3
"S3T1h"	3	1.5:1	1	否	SCALABILITY_S3T1h
"S3T2h"	3	1.5:1	2	否	SCALABILITY_S3T2h
"S3T3h"	3	1.5:1	3	否	SCALABILITY_S3T3h
"L2T2_KEY"	2	2:1	2	是	SCALABILITY_L3T2_KEY
"L2T2_KEY_SHIFT"	2	2:1	2	是	SCALABILITY_L3T2_KEY_SHIFT
"L2T3_KEY"	2	2:1	3	是	SCALABILITY_L3T3_KEY
"L2T3_KEY_SHIFT"	2	2:1	3	是	SCALABILITY_L3T3_KEY_SHIFT
"L3T1_KEY"	3	2:1	1	是
"L3T2_KEY"	3	2:1	2	是	SCALABILITY_L4T5_KEY
"L3T2_KEY_SHIFT"	3	2:1	2	是	SCALABILITY_L4T5_KEY_SHIFT
"L3T3_KEY"	3	2:1	3	是	SCALABILITY_L4T7_KEY
"L3T3_KEY_SHIFT"	3	2:1	3	是	SCALABILITY_L4T7_KEY_SHIFT

提出一个 scalabilityMode 值时，应遵循以下原则：

所提出的 scalabilityMode 必须定义第 5 节表中的条目，包括可伸缩性模式标识符、空间层和时间层、分辨率比率、层间依赖关系以及相应的 AV1 scalability_mode_idc 值（如果已分配）。
可伸缩性模式标识符应该与现有命名方案保持一致，该方案使用 LxTy 表示具有 x 个空间层、使用 2:1 分辨率比率以及 y 个时间层的 scalabilityMode。 LxTyh 表示具有 x 个空间层、1.5:1 分辨率比率以及 y 个时间层。SxTy 表示一个 scalabilityMode，其中有 x 个使用 2:1 分辨率比率的联播编码，每个联播编码包含 y 个时间层。SxTyh 表示 1.5:1 分辨率比率。LxTy_KEY 表示一个 scalabilityMode，其中有 x 个使用 2:1 分辨率比率的空间层和 y 个时间层，其中空间层仅在关键帧处依赖较低的空间层。LxTy_KEY_SHIFT 模式表示一个 scalabilityMode，其中有 x 个使用 2:1 分辨率比率的空间层和 y 个时间层，空间层仅在关键帧处依赖较低的空间层，而后续帧的时间标识符会向上偏移。
必须按照第 9 节所给出的格式提供依赖关系图。

本节为非规范性内容。

此示例扩展了 [WEBRTC] 第 7.1 节（示例 1），以演示发送三个空间联播层，每层具有三个时间层，并为每个联播层使用一个 SSRC 和 RID。仅对原始示例中的 "sendEncodings" 属性进行了更改。

示例 1

const signaling = new SignalingChannel(); // 处理 JSON.stringify/parse
const constraints = {audio: true, video: true};
const configuration = {'iceServers': [{'urls': 'stun:stun.example.org'}]};
let pc;

// 调用 start() 以开始
async function start() {
  pc = new RTCPeerConnection(configuration);

  // 让 "negotiationneeded" 事件触发提议生成
  pc.onnegotiationneeded = async () => {
    try {
      await pc.setLocalDescription();
      // 将提议发送给另一个对等方
      signaling.send({description: pc.localDescription});
    } catch (err) {
      console.error(err);
    }
  };

  try {
    // 获取本地流，在自视图中显示它，并添加它以便发送
    const stream = await navigator.mediaDevices.getUserMedia(constraints);
    selfView.srcObject = stream;
    pc.addTransceiver(stream.getAudioTracks()[0], {direction: 'sendonly'});
    pc.addTransceiver(stream.getVideoTracks()[0], {
      direction: 'sendonly',
      sendEncodings: [
        {rid: 'q', scaleResolutionDownBy: 4.0, scalabilityMode: 'L1T3'},
        {rid: 'h', scaleResolutionDownBy: 2.0, scalabilityMode: 'L1T3'},
        {rid: 'f', scalabilityMode: 'L1T3'}
      ]
    });
  } catch (err) {
    console.error(err);
  }
}

signaling.onmessage = async ({data: {description, candidate}}) => {
  try {
    if (description) {
      await pc.setRemoteDescription(description);
      // 如果收到提议，则需要以应答进行回复
      if (description.type == 'offer') {
        await pc.setLocalDescription();
        signaling.send({description: pc.localDescription});
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

这是一个包含两个空间层（比率为 2:1）和三个时间层的示例。

示例 2

let sendEncodings = [
  {scalabilityMode: 'L2T3'}
];

这是混合编解码器联播的示例，其中每个联播层都有 3 个时间层。

示例 3

let sendEncodings = [
  {rid: 'q', codec: {clockRate: 90000, mimeType: 'video/AV1'}, scaleResolutionDownBy: 4.0, scalabilityMode: 'L1T3'},
  {rid: 'h', codec: {clockRate: 90000, mimeType: 'video/VP8'}, scaleResolutionDownBy: 2.0, scalabilityMode: 'L1T3'},
  {rid: 'f', codec: {clockRate: 90000, mimeType: 'video/VP8'}, scalabilityMode: 'L1T3'}
];

这是一个在单个 SSRC 上包含三个空间联播层、每层都有三个时间层的示例。

示例 4

let sendEncodings = [
  {scalabilityMode: 'S3T3'}
]

本节为非规范性内容。

这是实现了 [WEBRTC] 和 [Media-Capabilities] 的浏览器返回的 encodingInfo(configuration) 的示例。

示例 5

const contentType = 'video/VP9';

const configuration = {
  type: 'webrtc',
  video: {
    contentType,
    width: 640,
    height: 480,
    bitrate: 10000,
    framerate: 29.97,
    scalabilityMode: 'L3T3_KEY'
  }
};

try {
  const info = await navigator.mediaCapabilities.encodingInfo(configuration);

  if (!info.supported) {
    console.log(`${contentType} 不受支持。`);
    return;
  }
  console.log(`${contentType} ${info.smooth || '不'}流畅，并且` +
              `${info.powerEfficient || '不'}节能`);
} catch (err) {
  console.error(err, ' 导致 encodingInfo 失败');
}

本节为非规范性内容。

这是一个 SFM 返回的接收器能力示例，该 SFM 仅支持转发 VP8、VP9 和 AV1 的时间可伸缩性模式。

示例 6

 "codecs": [
    {
      "clockRate": 90000,
      "mimeType": "video/VP8",
      "scalabilityModes": [
        "L1T1",
        "L1T2",
        "L1T3"
      ]
    },
    {
      "clockRate": 90000,
      "mimeType": "video/VP9",
      "scalabilityModes": [
        "L1T1",
        "L1T2",
        "L1T3"
      ]
    },
    {
      "clockRate": 90000,
      "mimeType": "video/AV1",
      "scalabilityModes": [
        "L1T1",
        "L1T2",
        "L1T3"
      ]
    }
]

在 WebRTC 中，可伸缩编码工具的使用不会在对等方之间进行协商，因此既不会在 SDP 中公开所支持的 scalabilityMode 值，也不会公开解码器对空间预测的支持情况。

通过尝试使用 setParameters() API 为每种编解码器设置 scalabilityMode 值，应用程序可以通过记录哪些配置尝试成功、哪些失败，来确定编码器支持的值。但是，这并不能表明某个 scalabilityMode 值是由硬件编码器还是软件编码器（或二者）支持。由于 setParameters() 不支持 RTCRtpReceiver，因此无法运行等效实验来确定解码器支持情况。

由于软件编码器支持的 scalabilityMode 值通常是硬件所支持值的超集，因此这些实验可获得的信息与正在使用的浏览器高度相关，而浏览器信息本身已经可以被网页获得。一旦媒体开始传输，就可以获得有关性能特征或某个 scalabilityMode 值对当前使用的编解码器而言是否可解码的信息，从而提供更多有关硬件能力的信息。

如 [Media-Capabilities] 第 3.1 节所述，媒体能力 API 相比从本规范中获得的信息，“很可能会提供更准确且一致的信息”。如 [Media-Capabilities] 第 3.1 节所述，“预计此信息将与网页已经可以获得的其他信息高度相关，因为给定类别的设备预计具有非常相似的解码/编码能力。”