WebRTC RTP 标头扩展审查

WebRTC 支持 RTP 标头扩展的概念，以使用额外的元数据扩展媒体数据包。最常见的用例之一是将音频级别附加到音频数据包，这样服务器就可以计算活跃的说话者而无需解码音频数据包。

其中一些标头扩展是标准的并且已经使用了一段时间，但还有一些是 Google 在需要时添加的，并且仅在网站和 libwebrtc 代码中进行了少量记录。这些标头扩展及其用法不是很清楚，这篇文章试图让 WebRTC 社区了解它们。

要发现其中一些标头，您通常可以查看 Google Meet 会话的报价/答案，或查看此处的 libwebrtc 源代码：https://chromium.googlesource.com/external/webrtc/+/master /api/rtp_parameters.h

音频级别( urn:ietf:params:rtp-hdrext:ssrc-audio-level ) Doc
[非常常见]

标头包含此音频包中包含的音频的音频电平（音量），以及一个可选位（通常不使用），用于指示该数据包是语音还是其他类型的音频。

用例：不解码音频的服务器仍然可以检测会话中的活动和/或主导发言者。

混合器到客户端音频级别( urn:ietf:params:rtp-hdrext:csrc-audio-level ) Doc 
[不是很常见，但 Google Meet 使用它]

此标头扩展包括有关促成此数据包音频的不同来源及其音频级别的信息。

用例：如果服务器组合或合并音频，则音频流可以同时描绘多个说话者，并且此标头使接收者能够识别在此期间说话的特定用户。

Inband Confort Noise ( http://www.webrtc.org/experiments/rtp-hdrext/inband-c )
[有人使用它吗？]

此标头扩展通知音频数据包是否包含舒适噪声及其级别。

用例：服务器可以降低这些数据包的优先级或避免将它们包含在混合中。接收方可以使用它作为启用不连续传输的提示。

绝对发送时间( http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time ) 
[Legacy]

此标头扩展包含一个 NTP 时间戳，表示发送数据包的时间，而不是捕获媒体的时间。

用例：主要用例是服务器端带宽估计能够检测数据包间延迟的变化，并使用它来估计可用带宽，并在需要时将其发送回发送方（使用 REMB RTCP 数据包）。

捕获时间( http://www.webrtc.org/experiments/rtp-hdrext/abs-capture-time )
[不是很常见，但 Google Meet 使用它]

此标头扩展包含一个 NTP 时间戳，表示何时从输入设备捕获与此数据包对应的帧。

用例：在服务器中实现音频/视频同步，例如用于混合目的。

传输范围标识符 ( http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 ) 
[几乎一直被使用]

此标头扩展包括每个数据包的唯一标识符，以便接收方随后可以将具有这些标识符的数据包的相对时间戳发送回发送方。有一个 v2 版本可以让发送者更好地控制何时接收反馈。

用例：它仅用于生成 TransportControlFeedback 数据包，包括标头扩展中包含的那些标识符的数据包间延迟。

媒体标识符(mid) ( urn:ietf:params:rtp-hdrext:sdes:mid ) Doc
[几乎一直被使用]

此标头扩展包括媒体流的 ID，该 ID 也包含在 SDP 中。  

用例：这样服务器或接收方就可以了解这些数据包的媒体流。为了节省带宽，此标头扩展仅包含在流的第一个数据包中或 ssrc 更改时。

RTP 流 ID  ( urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id )  Doc
[非常常见]

此标头扩展包括流的每个编码的标识符（来自联播层）。

用例：它类似于上述的中间标头扩展，但在这种情况下是为了在联播的情况下区分多种编码。 

修复的 RTP 流 ID  ( urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id )  Doc
[非常常见]

此标头扩展包括重传数据包的标识符，为其他 RTP 流中的数据包提供冗余。

用例：区分重传并将其关联到相应的 RTP 流。 

时间偏移量( urn:ietf:params:rtp-hdrext:toffset ) Doc
[有人在用吗？]

包括从捕获数据包到发送数据包的偏移量。

用例：允许在接收器端进行更准确的抖动计算。

Video orientation ( urn:3gpp:video-orientation )文档
【常用，唯一问题是firefox】

此标头扩展包括在渲染视频帧之前需要应用于视频帧的旋转（0、90、180、270 度）。这样，在横向模式下发送 640×480 视频的手机可以在将手机旋转到纵向模式时继续发送标头扩展中值为 90 的 640×480。

用例：由发送者使用，以避免在设备（通常是手机）从纵向变为横向时必须更改流的纵横比。Firefox 不支持这使得它在某些用例中变得棘手。

播放延迟( http://www.webrtc.org/experiments/rtp-hdrext/playout-delay ) 
[不是很常用，主要用于游戏流用例]

此标头扩展包括延迟，应在呈现之前应用于此音频或视频流。

用例：由发送方或服务器用来指示接收方它需要最小延迟（播放延迟=0）或者它可以容忍一些延迟以获得更好的质量（fe 播放延迟 500 毫秒）。这种行为也可以通过 javascript 属性 playoutDelayHint 来控制

视频内容类型( http://www.webrtc.org/experiments/rtp-hdrext/video-content-type ) 
[不是很常用]

此标头扩展包含有关内容类型（相机或屏幕共享）的信息。Chrome 在这里还包括一些更专有的东西来定义这个联播流的空间层。

用例：由服务器用来应用不同的 . 它也可能被接收器用来调整一些延迟或重传行为，但显然它在 Chrome 中没有用于这些。

Video Timing ( http://www.webrtc.org/experiments/rtp-hdrext/video-timing ) 
[不是很常用。也许只有 Google Meet？]

此标头包括与特定帧对应的媒体的不同时间戳（编码开始、编码结束、打包时间、定速器时间）。

用例：我认为主要用例是用于监控、测试和统计目的。

色彩空间( http://www.webrtc.org/experiments/rtp-hdrext/color-space ) 
[不是很常用。体育场？] 

此标头扩展包括用于表示视频帧信息的颜色空间。

用例：对以不同颜色空间表示的视频进行编码。

通用帧描述符( http://www.webrtc.org/experiments/rtp-hdrext/generic-frame-descriptor-00 ) 
[Legacy. 大部分替换为下面的依赖描述符 hdrext]

此标头扩展包括有关可缩放视频帧的层和依赖性的信息。 

用例：服务器使用它能够以独立于代码的方式正确过滤不同的帧和分辨率。   

视频层分配（http://www.webrtc.org/experiments/rtp-hdrext/video-layers-allocation00）
[不是很常用。Google Meet 使用它。]

此标头扩展包括使用可缩放视频编码或联播的有关空间层、时间层、它们的分辨率、帧速率和比特率的信息流。

用例：否则服务器需要猜测其中的一些信息（fe 比特率）来决定将哪些层转发给每个参与者，从而导致不太准确的值和更多的复杂性。

依赖描述符( https://aomediacodec.github.io/av1-rtp-spec/#dependency-descriptor-rtp-header-extension ) 
[不是很常用。Google Meet 使用它。]

此标头扩展包括有关可缩放视频帧的层和依赖性的信息。它专为 AV1 而设计，但也可用于其他编解码器 (fe VP9)。

用例：由选择性转发单元使用，能够以独立于代码的方式正确过滤不同的帧和分辨率。它与上面包含的遗留通用帧描述符的目的相同。

视频帧跟踪 Id ( http://www.webrtc.org/experiments/rtp-hdrext/video-frame-tracking-id ) 
[仅用于测试]

标头扩展，包括唯一的帧标识符。

用例：出于测试目的，能够关联发送方和接收方的帧。