【书籍阅读】WebRTC学习记录2

陈成不姓丞

已于 2022-10-19 10:41:56 修改

阅读量322

点赞数

分类专栏：书籍阅读文章标签： webrtc 实时音视频视频编解码

于 2022-03-30 12:10:25 首次发布

本文链接：https://blog.csdn.net/qq_42775328/article/details/123068958

版权

书籍阅读专栏收录该内容

11 篇文章 0 订阅

订阅专栏

WebRTC学习记录2

SFU vs. MCU

常用的媒体服务器主要分为SFU(Selected Forward Unit)和MCU(Multipoint Control Unit)，SFU只负责媒体流转发，不做太多复杂的媒体处理，并发能力会强一些。MCU除了媒体流的接收/发送，还会进行转码和混流，对服务器的性能要求比较高，在实时传输系统中，转码会带来额外的延时，在选型时也必须考虑。多人视频会议场景下的SFU/MCU架构示意如图：
在这里插入图片描述
SFU对接入的媒体流进行全网转发，MCU对接收到的媒体流做转码后，只转发一路合成后的媒体流。它们的优势和劣势总结如下表：

WebRTC的生态中，有许多优秀的开源媒体服务器：

对于实时性和高并发有强要求的会议场景，推荐采用SFU架构。

Quality of Service(QoS)

QoS策略的主要任务是对抗影响数据传输的网络变量，比如时延，抖动，丢包，带宽等。QoS的常规武器包括以下几个：

ARQ：自动重传请求，是数据链路层的错误纠正协议之一，WebRTC中用到是协议中的NACK机制，即接收端监测到数据包SeqN丢失后，发送对该数据包的重传请求，由发送端执行重传。
FEC：前向纠错，是增加数据通讯可靠度的方法，利用原始数据编码进行冗余信息的传输，当传输中出现丢包，允许接收端根据冗余信息重建。WebRTC利用UlpFEC进行数据保护，冗余系数由链路上的丢包率决定。
Jitter Buffer：抖动缓冲，通过在接收端维护一个数据缓冲区，可以对抗一定程度的网络抖动，丢包和乱序，需要考虑的是接收延时和卡顿之间的平衡。
Congestion Control：拥塞控制， WebRTC利用GCC算法来控制传输，通过兼顾丢包和时延的算法来估计网络可用带宽，并以此估算值来控制源端发送码率，避免网络拥堵。

在典型的SFU传输链路中，媒体流(RTP数据包)由Sender发送到Receiver，媒体控制流(RTCP包)由Receiver反馈给Sender。控制流中包括了NACK, PLI, REMB, Receiver Report等反馈信息。这些反馈信息是配合QoS策略的辅助手段。

有了这些QoS策略的加持，WebRTC的视频通话能够对抗一定程度的网络状况，正常情况下的通话质量可以保障。但是，这种默认的策略也存在明显的改进空间，比如：

QoS的策略是在端到端之间生效的，接收端发现丢包后，才会向发送端发送NACK请求重传，全链路的路径(rtt)过长，影响数据重传和恢复的效率。
接收端在发现无法恢复视频帧后，才会发送PLI(Picture Lost Indicator)向源端请求关键帧，直到下一个关键帧到达前，所有链路上的视频帧都无法正常解码，影响接收端的视频帧率，较大概率造成卡顿。

改进一：重传请求不再是全链路反馈

在这里插入图片描述
如上图所示，在改进的SFU传输架构中，重传请求不再是全链路反馈，而是在客户端和服务器之间进行。一方面，服务器具备了NACK请求的能力，及时发现上行链路的丢包，及时向发送端请求重传。另一方面，服务器能够及时响应接收端的NACK请求。丢包重传的效率提升，有助于减少端到端延时，改善音视频体验。

对于弱网下视频帧率较低的问题，除了优化传输过程中的FEC+NACK策略之外，还可以从源端编码器入手调整。

改进二：改变编码器的参考帧选择

常规的RTC系统中的编码GOP是IPPP…P，每一个P帧都作为参考帧，一旦某一帧有数据包缺失，其后的所有P帧都无法正常解码，抗误码扰动的能力比较差。

一种改进的思路是，改变编码器的参考帧选择，采用长参考帧Long-Term Reference (LTR) frames机制，比如：
在这里插入图片描述
可以看到，引入LTR后，P帧不再是单一的前向参考，而是会有选择性的参考一些固定的帧，只要这部分固定的参考帧能够完整被接收，就能确保其他的完整帧能够正常解码，提高接收端的视频帧率，保障流畅。这种编码方式是比较适合于RTC系统的，能够对抗更大的网络抖动。

应用在视频会议中，需要接收端实时反馈的配合。接收端借助于RTCP，实时反馈能够正常解码的帧信息，发送端可以利用收集到的这些信息，选择合适的参考帧序列(需要兼顾编码效率)，这样端到端的配合，能够最大程度的提升实时传输系统的体验。

Simulcast和SVC

Simulcast

Simulcast：同步广播，指的是同时编码/发送多路视频流，比如常规发送一路720p，外加一路180p的流，这样在SFU下发给接收端的时候，可以根据下行带宽的限制，选择下发不同分辨率的流，照顾到每个端的体验。
在这里插入图片描述

SVC

SVC：可伸缩编码，使用基于层次的方法，提供时间或空间可伸缩编码组合。在RTC的应用中，通常会选用时域SVC，通过改变帧率来实现伸缩性。SFU可以根据下行的实际带宽，从同一路SVC视频流中解析出不同的时域分层，分别传输给各个接收端，同样可以实现差异化的视频流转发。
在这里插入图片描述
常用的可分级编码有三种，分别是：空域可分级（Spatial Scalability）、质量可分级（Quality Scalability）和时域可分级（Temporal Scalability）。

空域可分级编码，即对视频中的每帧图像产生多个不同空间分辨率的图像，解码基本层码流得到的低分辨率图像，如果加入增强层码流到解码器，得到的是高分辨率图像。
在这里插入图片描述
质量可分级，一个可行的做法是，基本层码流编码这一路对原始图像 DCT 变换后进行一次粗糙量化，熵编码后形成基本层码流。粗糙量化后的数据经反量化后形成基本层系数，与原始图像 DCT 变换系数相减形成差值信号，再对此差值信号再进行一次细量化和熵编码生成增强层码流。

在这里插入图片描述
时域可分级，即把视频序列不重叠地分割成多层，对基本层的帧进行普通的视频编码，提供具有基本时间分辨率的基本层码流；对增强层则是利用基本层数据对增强层的帧间预测编码，生成增强层数据。

支持情况如图所示。从图中可以看出，H.264 仅支持 Simulcast（？），VP8 支持时域可分级，VP9 则全方位支持 SVC 编码。VP9 是 Google 公司在主推的编解码器，但是在 H.264 编解码器优化方面的推进力度不大，一定程度上限制了 WebRTC 的应用，比如苹果公司最新出品的 iPhone13 手机自带 H.264 的硬件加速功能，如果采用 AV1 编码器，虽然可以获得 SVC 的优点，但是无法进行硬件解码。在 WebRTC 中，Simulcast 是默认通过多线程技术，同时启动多个 OpenH264 编码器, SVC 则是可以调用 OpenH264 进行时域和空域可分级编码。
时域分级（时间可伸缩性）仅在VP8中可用。H.264并没有。（？）
在这里插入图片描述
将视频运动作为一个主要是衡量指标，对码流进行分配。相关论文具体的方案框架如图所示。

该方案存在两个改进空间：第一个是运动量度的方法采用的当前帧和前一帧的差，难以准确地反映出视频运动变化的情况。第二个是增加除了运动特征以外的其他特征，以便更好地反映图像视频的变化。拟采用的解决方案如图所示。
在这里插入图片描述
ICME2020 会议上，有学者提出了用于视频编码的超分辨模型，该模型通过提取不同时刻的图像进行特征融合来重建出高分辨率图像。

MPEG5 提出了 Low Complexity Enhancement Video Coding（LCEVC），该编码方式和 H.264 相比，在相同的 PSNR 下，压缩效率更高。
在这里插入图片描述