WebRTC简单实用的Qos优化

原创已于 2025-06-21 11:08:42 修改 · 1.5k 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#音视频算法 #webrtc

于 2022-03-31 23:15:36 首次发布

WebRTC开发实战宝典专栏收录该内容

10 篇文章

订阅专栏

本文探讨针对资源有限的小公司，如何通过简单的音频RED冗余和视频LTR策略来提升WebRTC的QoS。音频使用RED技术应对丢包，视频则利用LTR减少I帧请求，以降低延迟并节省带宽。

一、前言

WebRTC作为实时通信的核心技术，其服务质量(QoS)直接影响用户体验。本文将介绍一些简单而实用的WebRTC QoS优化策略，帮助开发者提升音视频通话质量。

二、优化方法

WebRTC有非常多的Qos策略，NACK, PLI, FEC等，在产品实践中，BAT对每个环节都有优化，以达到最优效果，实现70%抗丢包。原来x265对应x264节省25%带宽，通过自研编解码器，实现H265节省带宽56%。问题是对于小公司，即有自研RTC系统和优化Qos的需要，同时研发投入又非常有限，本问探讨了WebRTC最简单实用的Qos优化策略。

网络传输和播放缓存，贡献了78%的延时。无线传输相较于有限网络，更加复杂多变，Wifi信号干扰，4G用户移动造成的信号不稳定，拥塞，运营商带宽限速，造成丢包、拥塞、延时抖动，以及各种复合状况。

三、现有Qos策略的弊端

对抗丢包，WebRTC的Qos策略有，音频RED、NACK，FEC，PLI，FIR，这些策略再某些情景下能发挥很好的作用，例如：

NACK：延时低，带宽够，少量随机的丢包
FEC：冗余带宽够，低于FEC算法能力上限的丢包
PLI（Picture Lost Indication）：带宽够，延时低，超过NACK上限的大量丢包，或者SPS参数解析失败
FIR（Full Intra Request）：切换视频源，用用户加入多人会议，需要同学各方发送key frame。Intra是指帧内编码，而不是需要依赖其它帧的inter frame B或P帧。

同时，在某些情景下，上述的策略会失效，或加剧问题。

NACK：延时较大，例如传输延时200ms+NACK消息返回200ms+RTP重传200ms，重传之后延时增大到600ms，缓存队列增大。重传的流量，也可能加速带宽消耗，拥塞恶化。
PLI：由于key frame较大，重传I帧会加剧带宽消耗。
FEC：因带宽有限，FEC冗余占用了宝贵的带宽

四、简单高效的Qos优化策略

Qos优化可以无极限的追求，对于研发实力薄弱的小公司，在Qos优化的巨坑里面，如何简单高效的取得成果呢？

4.1、音频流的动态RED冗余

连续的音频是重要的用户体验，流的码率小，常用语音码率为20kbps~60kbps?。音频RED的原理，就是将码流冗余发送，例如30kbps，冗余发送1份就是60kbps，RED发送2份就是90kbps。这样在丢包率50%情况下，用户仍然能听到连续的音频，实现增强用户Qos体验。

4.2、视频LTR

对于静态画面，LTR能显著抵抗丢包画质，减少I帧请求。

4.3、网络适应性优化

// 简单的比特率自适应示例
function adjustBitrateBasedOnNetwork(stats) {
const { packetsLost, roundTripTime } = stats;

if (packetsLost > 0.1) { // 10%丢包
// 降低比特率
const senders = peerConnection.getSenders();
senders.forEach(sender => {
const parameters = sender.getParameters();
if (!parameters.encodings) return;

parameters.encodings.forEach(encoding => {
encoding.maxBitrate *= 0.8; // 降低20%
});
sender.setParameters(parameters);
});
} else if (packetsLost < 0.05 && roundTripTime < 200) {
// 网络良好，提高比特率
const senders = peerConnection.getSenders();
senders.forEach(sender => {
const parameters = sender.getParameters();
if (!parameters.encodings) return;

parameters.encodings.forEach(encoding => {
encoding.maxBitrate *= 1.2; // 提高20%
});
sender.setParameters(parameters);
});
}
}

4.4、使用Transport-CC和Goog-REMB

在SDP中启用拥塞控制反馈：

a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 goog-remb

五、抗丢包策略

5.1、FEC(前向纠错)

// 配置FEC
const pc = new RTCPeerConnection({
encodedInsertableStreams: true,
// 其他配置
});

// 或通过SDP
const offer = await pc.createOffer();
offer.sdp = offer.sdp.replace(
/a=fmtp:\d+ .*\r\n/g,
'$&a=fmtp:111 max-fr=30; max-fs=12288; useinbandfec=1\r\n'
);