webrtc QOS 丢包测试发现问题

最新推荐文章于 2025-10-27 22:59:57 发布
原创 最新推荐文章于 2025-10-27 22:59:57 发布 · 2.7k 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文探讨在10%丢包率环境下，Webrtc视频通话的性能问题。初始视频流畅，但随时间推移，视频卡顿加剧，直至完全停滞，解码帧率归零。分析发现，Webrtc持续降低帧率和码率以适应丢包，最终导致帧率降至0。文章建议设置BWE最低码率来应对持续丢包。

一、组网环境

二、预置参数

或者

1、Client1、Client2、信令服务器连接在一个以太网交换机上。保证Client1与Client2走P2P。

2、在Client2上使用Network Emulator Client网损工具，配置固定丢包率为10%或者随机丢包率为10%

3、创建视频连接，观察视频质量变化情况。

三、预期结果

在10%丢包率的网络下，视频质量无明显块效应，视频无明显卡顿。

四、实际结果

1、在视频链接前一分钟左右，视频质量良好，无明显块效应，视频流畅性良好，无明显卡顿。

2、随着视频通话时间变长，视频卡顿越来越明显，后期完全卡住不动。根据显示统计结果，解码帧率为0。

五、分析原因

发现网损工具每N个包丢一包模式，会引发一个问题：
1、刚开始10个包丢一个丢包，降了帧率和码率，webrtc发送到网络上的报文少了，视频流畅可接受；
2、网损工具还是每10包丢一包，让webrtc继续降帧率码率，webrtc发送到网络上的报文再减少；
3、网损工具还是每10包丢一包，如此循环。。。。。。
导致最后webrtc将帧率降为0，就长时间卡顿下去。这类似于0.9*0.9*....*0.9最后等于0的原理。

另外也说明，webrtc目前的机制，无法解决长时间、持续丢包模型。

为了应对这种场景，可以配置BWE的最低码率。

六、附录

别人总结的丢包模型，mark一下

http://xuxinting.cn/2017/08/30/VoIP-TroubleShouter-burst-loss/

webrtc QOS 优化 (1)慢启动优化
debug&code的专栏
02-21 2227
在webrtc启动阶段，第一个ack时钟的是由探测的策略来产生，这时GCC通过探测来进行码率评估,类型tcp的慢启动
深入探究音视频开源库WebRTC中NetEQ音频抗网络延时与抗丢包的实现机制
dvlinker的技术专栏
04-24 1万+
深入探究音视频开源库WebRTC中NetEQ音频抗网络延时与抗丢包的实现机制
【网络通信 -- WebRTC】WebRTC 服务质量 (QoS) -- 综述
CopperSun 技术博客
07-27 1021
【网络通信 -- WebRTC】WebRTC 服务质量 (QoS) -- 综述 【1】WebRTC QoS 处理过程简介 WebRTC 设计了一套基于延迟和丢包反馈的拥塞机制和带宽调节策略来保证延迟、质量和网路速度之间平衡，该处理循环如下图所示； 图示的循环处理流程如下 1) estimator 通过 RTCP 的 feedback 反馈过来的包到达延迟增量和丢包率信息计算出网络拥塞状态并评估出适合当前网络传输的码率，根据这个码率改变视频编码器码率，然后改变 pacer 的码率 2) pace
WebRTC系列分享 | WebRTC视频QoS全局技术栈
yinshipin007的博客
10-31 339
PACER，是网络报文平滑策略。WebRTC的vpx编码器使用了Temporal Scalability时间可适性编码，仅需通过FEC+NACK方式保护T0层的数据完整性，其余层的视频帧有丢失，可通过逐级降帧率方案（丢弃Tn-T1之间的数据），保证视频通话整体的流畅性。云架构平台部是腾讯规模最大的技术部门之一，长期深耕音视频、存储、接入和计算服务等技术领域，通过海量的存储和数据库平台，世界级的CDN&音视频服务，先进的操作系统和视频编解码技术，助力腾讯云以技术的力量持续赋能客户，帮他们提升效率，降低成本。
webrtc代码走读（十七）-QOS系列9-SVC（可分级视频编码）
最新发布
qq_31065851的博客
10-27 1485
SVC（可适性视频编码）是H.264/AVC的扩展技术，通过时间、空间和质量的灵活分层实现视频流的自适应传输。其核心优势在于"一次编码，多端适配"，有效降低编码开销。时间分层通过帧间预测实现帧率调整，空间分层支持分辨率动态变化，质量分层则允许码率弹性控制。典型应用包括监控视频的多分辨率存储、视频会议的多终端适配以及抗网络丢包场景。OpenH264等开源库已实现SVC编码功能，通过分层参数配置满足不同场景需求，显著提升视频传输效率与兼容性。
WebRTC QoS
闲敲棋子落灯花
11-15 2276
Outline 1. Bandwidth Estimation Delay Based Control Loss Based Control 2. Error Concealment RTP Retransmission(NACK) FEC PLI/SLI/RPSIPacket Arrival Model G
WebRTC QoS方法一（NACK实现）
CrystalShaw的博客
07-26 1万+
一、概念 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。 NACK也是一种通知技术，只是触发通知的条件刚好的ACK相反，在未收到消息时，通知发送方“我未收到消息”，即通知未达。 在rfc4585协议中定义可重传未到达数据的类型有二种： 1）RTPFB：r...
webrtc QoS -服务质量总结
tuan8888888的博客
10-22 1226
什么是QOS QoS（Quality of Service，服务质量）指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务能力，是网络的一种安全机制， 是用来解决网络延迟和阻塞等问题的一种技术。QoS的保证对于容量有限的网络来说是十分重要的，特别是对于流多媒体应用，例如VoIP和IPTV等，因为这些应用常常需要固定的传输率，对延时也比较敏感。 webrtc 的QoS 的方法 NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VF
WebRTC服务质量（01）- Qos概述
Ziwubiancheng的博客
12-10 1360
WebRTC 的 QoS 策略是一个复杂的多层动态优化过程，以实现实时音视频通信的高质量和低延迟。提高网络可靠性（NACK/RTX、FEC、JitterBuffer 等）。动态调整码率与带宽适配（拥塞控制、Transport-cc、主动丢包等）。降低数据发送量（SVC、Simulcast、动态帧率调整等）。延迟优化（Pacer、DTLS 优化、ICE 节点选择等）。音频质量优化（Opus 自适应、音频冗余编码、回声消除等）。设备性能适配（硬件加速、帧率和分辨率平衡等）。
【WebRTC---优化篇】（一）Qos优化杂记
用可见的方式来记录和分享每一次收获
03-08 1473
JitterBuffer延迟换流畅 在丢包+延迟+抖动的弱网环境下，推流端通过NACK+FEC等方式做了一定的容错，但是可能并不能百分之百解决所有问题，而且通过SFU分发到拉流端之后，拉流端网络也可能有问题，这个时候需要JitterBuffer来做媒体包的缓存，例如视频JitterBuffer，它不只缓存视频包，还组帧，还期望组成连续的可解码的GOP，一旦有一个帧的包丢失，就需要等待，如果较长时间无法恢复就丢弃剩余的整个GOP，如果恢复的比较晚，等到音视频同步完去渲染发现这一系列帧已经太晚了，会直接扔掉或
WebRTC系列-Qos系列之发送NACK
HOSTEN的博客
01-18 1443
在之前的文章介绍了音频开启对包重传的方式及验证是否开启的成功的方式；在文章的2.3.3章节介绍了NACK包在WebRTC中解析方式及RFC规定协议的定义。在WebRTC中是支持音频和视频的NACK，本文只分析NACK及其重点相关的机制，不分析jitterbuffer或者neteq的相关知识及实现，这些将会有其他的文章重点介绍。
WebRTC视频数据统计之延时、抖动与丢包
04-25
WebRTC视频数据统计之延时、抖动与丢包，包含WebRTC如何更新、客户端如何获取等流程结构图
webrtc QOS方法四（Sender Side BWE）
CrystalShaw的博客
10-09 1万+
背景介绍 BWE（Bandwidth Estimation）可能是WebRTC视频引擎中最关键的模块了。BWE模块决定视频通讯中可以发送多大码率视频不会使网络拥塞，防止视频通讯质量下降。 早期的带宽评估算法比较简单，大多是基于丢包来估计，基本的策略是逐步增加发送的数据量，直到检测到丢包为止。为了让发送端获悉网络上的丢包信息，可以使用标准的RTCP的RR来发送周期性的报告。 现代的带宽评估算法...
WebRTC QoS方法（汇总篇）
热门推荐
CrystalShaw的博客
05-24 2万+
目前总结出webrtc用于提升QOS的方法有： NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR（动态帧率调整策略）。 这几种方法在webrtc架构分布如下： 具体实现原理如下： 一、NACK 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收......
WebRTC服务质量（05）- 重传机制（02) NACK判断丢包
Ziwubiancheng的博客
12-17 1464
本文主要介绍了NACK的格式，以及NACK的调用栈，并且介绍了如何判断丢包，但请记住，这些包都是“可疑丢包”，真正的丢包下一节介绍。
WebRTC QoS方法四.4（Transport-wide Congestion Control协议笔记）
CrystalShaw的博客
08-04 1987
一、协议链接 https://tools.ietf.org/pdf/draft-holmer-rmcat-transport-wide-cc-extensions-01.pdf 二、协议定义 三、抓包示例 四、参数说明 version (V): 2 bits。固定是2。 padding (P): 1 bit。 feedback message type (FMT): 5 bits。TransportCC固定是15。 payload type (PT): 8 bits。Transp..
webrtc audio QoS
weixin_44991625的博客
06-15 223
WebRTC Qos策略
yinshipin007的博客
02-28 922
WebRTC中pacer的流程比较清晰，分为三步：1）如果一帧图像被编码和RTP切分打包后，先会将RTP报文存在待发送的队列中，并将报文元数据(packet id, size, timestamp, 重传标示)送到pacer queue进行排队等待发送，插入队列的元数据会进行优先级排序。基于丢包率（loss-based ）（发送端实现）发送端从接收端发送的 RTCP RR(Receiver Report）报文，根据 Report Block 中携带的丢包率信息，动态调整发送端码率。
webrtc QOS方法（概述篇）：
EveryDayOneHour的博客
02-04 1893
目前总结出webrtc用于提升QOS的方法有： NACK、FEC、SVC、JitterBuffer、IDR Request、PACER、Sender Side BWE、VFR（动态帧率调整策略）、AVSync（音视频同步）、动态分辨率调整。 与NACK对应的是ACK，ACK是到达通知技术。以TCP为例，他可靠因为接收方在收到数据后会给发送方返回一个“已收到数据”的消息（ACK），告诉发送方“我已经收到了”，确保消息的可靠。NACK也是一种通知技术，只是触发通知的条件刚好的...
WebRTC中要实现REMB，可以通过丢包率来计算码率吗？
08-21
<think>我们正在讨论WebRTC中的REMB算法，特别是它是否使用丢包率来计算码率。首先，我们需要了解REMB算法。 REMB（Receiver Estimated Maximum Bitrate）是WebRTC中由接收端估算最大可用带宽并反馈给发送端的一种机制。在WebRTC中，带宽估计是一个复杂的过程，涉及多个因素，其中丢包率是一个重要指标，但REMB本身并不直接使用丢包率来计算码率。 根据WebRTC的架构，带宽估计主要由两部分组成： 1. 基于延迟的拥塞控制（如GoogCC算法）：通过分析数据包之间的延迟变化来推断网络拥塞情况，从而调整发送码率。 2. 基于丢包的拥塞控制：当网络发生丢包时，会认为网络出现拥塞，从而降低发送码率。 但是，REMB消息本身并不包含丢包率的信息。REMB消息是接收端通过RTCP反馈的一种消息，它包含一个由接收端估算的带宽值（以bps为单位）。这个估算值是由接收端基于接收到的数据包的时间间隔、数据包大小等信息，通过特定的带宽估计算法（如Google的接收端带宽估计算法）计算出来的。 在WebRTC的实现中，接收端的带宽估计算法（如接收端使用的到达时间模型）主要关注的是延迟梯度（即包组之间的时间间隔变化），而不是丢包率。丢包率通常用于发送端的拥塞控制模块，当检测到丢包超过一定阈值时，发送端会主动降低发送码率。 因此，REMB算法本身并不直接使用丢包率来计算带宽估计值。丢包率是在发送端用于调整码率的另一个独立因素。 然而，在发送端，当它接收到REMB消息时，会结合其他信息（包括丢包率）来最终确定发送码率。发送端可能会将REMB建议的带宽值作为上限，同时根据丢包情况进一步调整。 总结： - 接收端在计算REMB（即最大可用带宽估计）时，主要基于延迟变化（即拥塞信号），不使用丢包率。 - 丢包率是发送端在拥塞控制中独立使用的另一个信号，用于在检测到丢包时调整发送码率。 引用说明： 根据WebRTC的文档和相关源码[^1][^2]，REMB消息的生成仅基于延迟梯度，而丢包率则用于发送端的基于丢包的拥塞控制模块。 §§相关问题§§ 1. WebRTC中除了REMB，还有哪些带宽估计算法？ 2. 发送端如何处理REMB消息和丢包率信息？ 3. 在WebRTC中，丢包率是如何测量的？</think>在WebRTC中，REMB（Receiver Estimated Maximum Bitrate）算法**不直接使用丢包率计算带宽**，而是主要依赖**延迟梯度**进行带宽估计。以下是关键分析： ### 1. REMB的核心机制 - **延迟梯度分析**：REMB接收端通过计算连续数据包的到达时间间隔变化（$\Delta t$），检测网络拥塞。数学表示为： $$ \text{延迟梯度} = \frac{\Delta \text{到达时间}}{\Delta \text{发送时间}} $$ 当该值持续增大时，表明网络排队延迟增加，触发带宽下调[^1]。 - **丢包率的辅助作用**：虽然REMB自身不依赖丢包率，但发送端会**综合REMB建议值和丢包率**调整最终发送码率： ```mermaid graph LR A[REMB接收端] -->|带宽估计| B[基于延迟梯度] C[发送端] -->|最终码率| D[REMB建议值] C -->|最终码率| E[丢包率阈值] ``` ### 2. 丢包率的独立作用 - **基于丢包的拥塞控制**：WebRTC发送端独立监测丢包率： - 丢包率 < 2%：缓慢增加码率 - 丢包率 > 10%：乘性降低码率（公式：$ \text{new\_rate} = \text{current\_rate} \times (1 - 0.5 \times \text{loss\_ratio}) $)[^2] - **与REMB的协同**：REMB提供带宽上限，丢包率提供即时拥塞反馈，两者共同约束发送码率。 ### 3. 性能对比 | 指标 | REMB（延迟驱动） | 丢包率驱动 | |--------------|------------------|------------------| | 响应速度 | 毫秒级 | 秒级（需统计窗口）| | 抗随机丢包 | 强 | 弱 | | 网络适应性 | 高（动态调整） | 中（固定阈值） | ### 4. 实际应用建议 若需结合丢包率优化REMB： 1. 在发送端实现**双因子决策**： ```python def adjust_bitrate(remb_bw, loss_rate): if loss_rate > 0.1: # 丢包率>10% return min(remb_bw, current_rate * 0.8) return remb_bw ``` 2. 使用**平滑函数**避免震荡： $$ \text{final\_rate} = \alpha \times \text{remb\_rate} + (1-\alpha) \times \text{loss\_adjusted\_rate} \quad (\alpha=0.7) $$ > ⚠️ 注意：过度依赖丢包率可能导致**带宽低估**（尤其在无线网络），REMB的延迟分析仍是WebRTC的默认推荐方案[^3]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值