“奇怪的”WebRTC audio/video 丢包率

最新推荐文章于 2024-07-23 03:37:28 发布
原创 最新推荐文章于 2024-07-23 03:37:28 发布 · 2.7k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

针对WebRTC的音频丢包率计算问题，提出了一种改进的算法，该算法不再依赖固定时间间隔，而是根据丢包数变化动态计算，提高了丢包率数据的准确性和可靠性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

前一段时间在给公司产品的弱网提示功能提供数据支撑的时候，是根据WebRTC抛来上的StatsReport中的packetsLost、packetsSent/packetsReceived作为计算的数据来源进行的。采用的丢包率算法是：

（单位时间内packetsLost差）÷（单位时间内packetsSent/packetsReceived差）= 单位时间内的丢包率

期初，我们采取的单位时间是1秒。即每1秒就计算一次丢包率。但从实际的数据上来看，会发生这样的现象：

上图是通过WebRTC的StatsReport报上来的原始数据，每1秒打印一条，我过滤了其他，只保留了audio。从数据中我们很容易发现一个问题，就是每秒的packetsSent差都是50，但是packetsLost的值会发生275 -> 446 (差值171) 这种巨大的变化。

所以，如果我们按照单位时间1秒来计算丢包率，就会得到这样的结果：

(446-275) ÷ (4590-4540) = 171 ÷ 50 = 3.42 = 342%

显然如果我们按照单位时间1秒来计算丢包率是不合适的，否则就会出现上面展示的现象，上一秒的丢包率还是0，下一秒的丢包率就成了342%。

所以，我目前的处理方法是修改丢包率的计算公式，丢包率不再采用固定单位时间更新，而是根据丢包数发生变化的时候来计算。即当packetsLost发生变化时，记录当前packetsSent/packetsReceived数值，直到下一次packetsLost发生变化时，记录新的packetsSent/packetsReceived数值，丢包率的计算公式不变（还是本文一开始的），两次packetsLost差值作为分子，两次packetsSent/packetsReceived差值作为分母。得到最终的丢包率。这里的主要变化是不再考虑时间，即丢包率数值的更新不以某个固定时间来计算，而完全按照packetsLost发生变化才计算。

经过上面的调整以后，还是借用图中的数值。当packetsLost首次=275时，packetsSent=4240。之后过了7秒，packetsLost变为446，packetsSent变为4590，那么新的丢包率就是：

(446-275) ÷ (4590-4240) = 171÷350=0.4886=48.86%

这样处理后的丢包率数值看起来“更可信”一点。

欢迎读者提供WebRTC的audio/video更好的丢包率计算方法~

 

【gcc】webrtc发送侧计算 丢包率
突围
02-02 795
丢包率
【webrtc】视频包/音频包 接收测触发 nack
突围
12-27 650
nack
Webrtc丢包率的计算
qq_15821883的博客
07-27 552
webrtc丢包率的计算
WebRTC研究：丢包与抖动
m0_60259116的博客
09-01 1044
WebRTC研究：丢包与抖动
WebRTC的丢包计算方法
sonysuqin的专栏
09-06 5432
本文介绍了WebRTC内部计算丢包的算法，其跟RTT的计算有紧密联系，在Janus等服务优化丢包逻辑时可以作为参考。
深入浅出WebRTC—LossBasedBweV2
程序员老六的专栏
07-23 1466
与带宽一样，固有丢包率（inherent loss）也是网路链路的一个属性，而且是动态变化的。当观察到丢包的时候，我们如何判断这是由于链路固有丢包率导致的丢包还是由于网络拥塞导致的丢包？除非我们知道链路的固有丢包率和带宽，但显然这是无法办到的。WebRTC 为解决这个问题打开了一扇窗，其思路是建立网络丢包的二项式分布模型，通过搜集足够多的观测值，构造目标函数，使用牛顿方法去搜索链路带宽和固有丢包率的最佳组合。然后对这个最佳组合进行必要的校正与调整。
Chrome调试工具webrtc-internals
热门推荐
点点滴滴
11-30 1万+
文章目录1、打开调试工具2、导出调试信息3、切换获取统计信息的方式4、相关统计信息4.1 获取用户媒体设备请求(`GetUserMedia Request`)4.2 通道（`RTCPeerConnection`）列表4.3 查看每个通道（`RTCPeerConnection`）的信息4.3.1 查看事件信息4.3.2 查看统计信息4.3.3 统计数据说明`RTCPeerConnection (peer-connection)``RTCTransport_0_1 (transport)``RTCCertifi
【WebRTC---源码篇】（十七）WebRTC音频引擎
用可见的方式来记录和分享每一次收获
11-05 552
webrtc音频引擎
【WebRTC---源码篇】（十三）WebRTC/Pacer
用可见的方式来记录和分享每一次收获
10-07 564
WebRTC/Pacer
【webrtc 】FEC 1: 音频RED rfc2198及视频ULPFEC的RED封装
突围
10-16 1041
red
WebRTC视频数据统计之延时、抖动与丢包
04-25
WebRTC视频数据统计之延时、抖动与丢包，包含WebRTC如何更新、客户端如何获取等流程结构图
RTCP抖动、丢包率的计算方法
04-10
英语的，RTCP包的计算方法，有公式 Quality-of-service monitoring and reporting » Real-time control protocol RTCP
WebRTC中丢包重传机制的实现
RTC吧
08-08 5601
当网络质量突然变的很差并开始丢包时，声音听起来音质会变差，画面帧速会下降，甚至会完全卡住。我们可能需要某种机制来应对这种情况。在WebRTC中，主要有两种机制来应该网络变差的情况： 前向纠错：在每个数据包中，您将添加一些关于前一个信息的信息，以防丢失，您需要重新构建它们（flexfec是WebRTC [1]中的新格式）。 重传：当接收方检测到有丢包时，它会发送NACK类型的RTCP包给
WebRTC的 丢包和重传
HOSTEN的博客
04-03 1345
前向纠错FEC和ulpfec 简述 WebRTC 中的音频大部分使用opus编码，opus编解码自带有FEC(前向纠错)； 前向纠错也叫前向纠错码(Forward Error Correction，简称FEC)，是增加数据通讯可信度的方法。在单向通讯信道中， 一旦错误被发现，其接收器将无权再请求传输。FEC 是利用数据进行传输冗余信息的方法，当传输中出现错误，将允许接收器再建数据。 基本原理: 前一帧与当前帧均正常， 前一帧数据正常解码； opus_decode(decoder, previous_
How to Recover Lost Media Packets in WebRTC using Forward Error Correction
mandagod的博客
02-27 468
How to Recover Lost Media Packets in WebRTC using Forward Error Correction BY: LASSE LUMIAHO, VARUN SINGH,  09 NOVEMBER 2016 This is a followup blog post to an earlier post on error resil
webrtc代码走读十一（RTCP丢包率、环路延时计算）
CrystalShaw的博客
11-06 6370
以PeerA端为例，PeerA想要知道： 1、PeerA发送给PeerB的RTP报文的丢包率和环路延时 2、PeerB发送给PeerA的RTP报文的丢包率。 一、丢包率计算原理 1、peerA统计PeerB发送给PeerA的丢包率 PeerA接收报文的丢包率，可以通过判断收到报文的RTP序列号的连续性计算。 在webrtc里面函数实现如下： ->RTCPSender::Se...
html5调用系统声音1s响一次_HTML5 WebRTC AudioContext捕捉麦克风声音API代码示例
weixin_42309599的博客
01-12 364
JavaScript语言：JaveScriptBabelCoffeeScript确定var myAudio = document.querySelector('audio');var pre = document.querySelector('pre');var video = document.querySelector('video');var myScript = document.quer...
IP视频通信中的丢包恢复技术
10-30 851
转载这篇文章是为了告诉自己，在这几个方面需要有所作为。 在IP视频通话中，即使是在丢包率很小的情况下也会对使用效果造成较为明显的影响。正是由于这个原因，自从上世纪九十年代中后期IP视频会议技术出现以来，在“有损耗”的IP网络上成功召开视频会议的能力一直是一项挑战。近年来，随着低成本，共享式的网络线路的普遍采用(如DSL，有线，卫星，LAN和WAN，公共互联网等)以及使用更高通话带宽(通常需要支
是webrtc传输视频包时用了RED
最新发布
07-12
<think>我们正在讨论WebRTC中的RED（Redundancy）机制。RED是一种用于音频的抗丢包技术，通过发送冗余编码来应对网络丢包。虽然用户的问题是关于视频传输的，但需要澄清：在WebRTC中，RED通常用于音频，而视频则使用其他机制（如FEC、NACK、PLI/FIR）。然而，根据引用[3]提到“音频RED”，我们可以推断用户可能混淆了音频和视频。但为了全面性，我们将解释音频RED的原理，并说明视频传输中类似的技术。 根据引用[3]： > 对抗丢包，WebRTC的Qos策略有，音频RED、NACK，FEC，PLI，FIR 这里明确提到“音频RED”，因此RED主要用于音频。但是，如果用户坚持要了解视频RED（尽管标准WebRTC视频传输不使用RED），我们可以讨论冗余思想在视频中的应用（例如通过FEC或重传）。 因此，回答将分为两部分： 1. 音频RED的原理和实现（标准用法） 2. 视频传输中类似的冗余机制（非RED，但思想类似） 注意：WebRTC视频传输通常不使用RED，而是使用FEC（前向纠错）、NACK（重传请求）和关键帧请求（PLI/FIR）等。 --- ### 一、音频RED（Redundant Audio Data）原理 RED是RTP音频负载的一种冗余编码方案（RFC 2198）。其核心思想是在当前音频包中携带之前一个或多个音频包的冗余副本。当网络发生丢包时，接收端可以使用冗余数据恢复丢失的包。 #### 1. RED封包格式 一个RTP包中可以包含多个冗余块，每个块可以是主编码数据或冗余数据。格式如下： - **RTP头部**：标准RTP头部，PT（Payload Type）字段设置为RED的负载类型（动态值，通过SDP协商）。 - **RED头部**：包含一个块头列表和可选的辅助信息。 - 块头列表：每个冗余块的头（1~3字节），描述块的类型、长度和时间戳偏移。 - 主数据块：当前时间戳的音频数据（主编码）。 - 冗余数据块：之前时间戳的音频数据（冗余编码，通常使用更低比特率的编码）。 **RED头部结构**（简化）： ``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | ... (更多块头) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主数据块（当前包） | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 冗余数据块（前一个包） | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` - `F`：1位，指示是否还有后续块头（0表示还有，1表示最后一个块头）。 - `block PT`：7位，该块的负载类型（如OPUS、PCMA等）。 - `timestamp offset`：14位，相对于RTP头部时间戳的偏移量（以采样点为单位）。 - `block length`：10位，该块的长度（字节数）。 #### 2. RED工作流程 - **发送端**： 1. 对当前音频帧进行主编码（高质量）。 2. 将前一个音频帧进行冗余编码（低质量，如更低比特率）。 3. 将主编码数据（当前帧）和冗余编码数据（前一帧）打包到同一个RTP包中。 4. 设置RTP头部的PT为RED类型，并构造RED头部。 - **接收端**： 1. 收到RTP包后，根据PT判断为RED包。 2. 解析RED头部，提取主数据块和冗余数据块。 3. 若下一个包丢失（即当前包的主数据块对应的下一个包丢失），则使用当前包中的冗余数据块（它是前一个包的副本）来填补丢失的包。 4. 解码时优先使用主数据块，若主数据块对应的包丢失，则使用其他包中的冗余块恢复。 #### 3. 冗余策略 - **冗余层级**：可配置携带多级冗余（如最近1~3个包）。 - **编码选择**：冗余块通常使用低复杂度编码（如CELT、低比特率OPUS）以节省带宽。 - **带宽开销**：冗余数据增加带宽占用（例如，50%冗余意味着带宽增加50%）。 #### 4. WebRTC中的实现 - **启用条件**：通过SDP协商RED负载类型。例如： ```sdp a=rtpmap:111 red/8000/1 // 定义RED负载类型为111 a=fmtp:111 96/97 // 96为主编码类型（如OPUS），97为冗余编码类型 ``` - **配置参数**：在WebRTC中可通过`PeerConnection`配置编码器参数，设置冗余包数量。 - **源码位置**：WebRTC中RED编码/解码实现在`modules/audio_coding/neteq`和`modules/rtp_rtcp/source/rtp_format_red.[h/cc]`。 --- ### 二、视频传输中的冗余机制（非RED） 视频数据量远大于音频，直接使用RED携带完整冗余帧会导致带宽剧增。因此，WebRTC视频采用以下冗余机制： #### 1. 前向纠错（FEC） - **原理**：发送原始数据包的同时发送冗余校验包（如XOR、Reed-Solomon编码）。当原始包丢失时，可通过校验包恢复。 - **实现**：WebRTC使用UlpFEC（Uneven Level Protection FEC）和FlexFEC（RFC 8627）。FlexFEC独立于RTP流发送，支持恢复连续丢包。 - **开销**：固定比例冗余（如10%~20%）。 #### 2. NACK重传 - **原理**：接收端检测到丢包后发送NACK报文请求重传。 - **适用场景**：低延迟、带宽充足且丢包率较低时（引用[3]提到“NACK：延时低，带宽够，少量随机的丢包”[^3]）。 #### 3. 关键帧请求（PLI/FIR） - **原理**： - PLI（Picture Loss Indication）：接收端通知发送端“画面不完整”，请求重发关键帧（I帧）[^3]。 - FIR（Full Intra Request）：强制发送端生成关键帧（如新参与者加入时）[^3]。 - **适用场景**：大量丢包或解码失败时。 #### 4. 参考帧选择（RPS）与SVC - **RPS**：编码时选择参考帧，减少丢包传播。 - **SVC（可伸缩视频编码）**：将视频分为多层（基础层+增强层）。基础层丢失时可通过FEC保护，增强层可丢弃。 --- ### 三、视频传输中类似RED的冗余方案 尽管视频通常不使用RED，但某些场景下可采用： - **重传包（RTX）**：WebRTC定义RTX负载类型（RFC 4588），用于重传原始包。与RED不同，RTX是独立的重传流。 - **带内FEC**：将FEC数据与原始数据打包在同一包中（类似RED思想），但WebRTC未采用。 --- ### 四、RED的优缺点 | 优点 | 缺点 | |------|------| | 抗随机丢包（无需反馈） | 带宽开销大（冗余数据始终发送） | | 恢复延迟低（接收端即时恢复） | 不适用于突发丢包（冗余数据可能同时丢失） | | 实现简单 | 视频场景不适用（数据量大） | --- ### 五、相关问题 §§相关问题§§ 1. WebRTC中音频RED如何配置？ 2. WebRTC视频传输如何选择FEC和NACK策略？ 3. 如何评估RED对音频质量的影响？ 4. WebRTC中FlexFEC的实现原理是什么？</think>### WebRTC视频传输中RED机制的原理与实现 RED（Redundant Coding，冗余编码）是WebRTC中用于对抗网络丢包的关键技术，尤其在音频传输中广泛应用（引用[3]明确提到“音频RED”作为QoS策略之一[^3]）。虽然RED主要面向音频，但其核心思想在视频传输中也有类似应用（如FEC冗余）。下面详细解析RED机制的原理和实现方式： --- ### 一、RED的核心原理 RED通过**发送冗余数据包**来提升抗丢包能力，其工作流程如下： 1. **冗余生成**： 发送端将当前数据包（$P_n$）与之前的数据包（$P_{n-1}$, $P_{n-2}$等）按特定算法组合，生成冗余包（$R_n$）。 $$ R_n = f(P_n, P_{n-1}, ..., P_{n-k}) $$ 其中$k$为冗余层级（通常$k=1$或$2$）。 2. **并行传输**： 原始数据包和冗余包通过**不同网络路径**或**不同RTP包**发送（避免同时丢失）。 3. **丢包恢复**： 接收端检测到原始包丢失时，利用冗余包中的信息重建丢失数据： - 若$P_n$丢失，但$R_n$包含$P_n$的信息 → 直接恢复 - 若$P_n$丢失，但$R_{n+1}$包含$P_n$的信息 → 间接恢复 4. **带宽权衡**： 冗余数据增加带宽开销（典型冗余率$20\%-50\%$），但显著降低丢包影响（引用[3]指出需“冗余带宽够”时使用[^3]）。 --- ### 二、RED在WebRTC中的实现方式 #### 1. 音频RED实现（标准方案） 音频RED遵循**RFC 2198**标准，在RTP包中封装冗余数据： ```plaintext | RTP头部 | RED头部 | 主数据块 | 冗余数据块1 | 冗余数据块2 | ... ``` - **RED头部结构**： - 块PT（7位）：冗余块的负载类型（如OPUS） - 时间戳偏移（14位）：相对于主块的时间偏移 - 块长度（10位）：冗余块字节数 **WebRTC源码关键位置**： - 编码器配置：`modules/audio_coding/audio_network_adaptor/` - RED封包逻辑：`modules/rtp_rtcp/source/rtp_sender_audio.cc` #### 2. 视频传输中的类RED机制 虽然视频不直接使用RED格式，但采用类似冗余思想： - **FEC（前向纠错）**： 生成奇偶校验包（类似RED冗余包），通过异或运算恢复丢失包： ```c // 伪代码：生成FEC冗余包 fec_packet = original_packet1 XOR original_packet2 ``` - **参考帧冗余**： 关键帧（I帧）复制到多个RTP包发送（类似RED的多级冗余），避免帧丢失导致解码中断（引用[3]的FIR/PLI策略与此相关[^3]）。 **视频冗余源码位置**： - FEC生成：`modules/rtp_rtcp/source/flexfec_sender.cc` - 抗丢包策略：`modules/video_coding/utility/framerate_controller.cc` --- ### 三、RED的性能优化策略 1. **动态冗余调整**： 根据网络QoS动态改变冗余层级$k$： - 低丢包率：$k=0$（关闭冗余） - 高丢包率：$k=2$（双重冗余） ```mermaid graph LR A[网络监测] -->|丢包率<5%| B[k=0] A -->|丢包率5%-15%| C[k=1] A -->|丢包率>15%| D[k=2] ``` 2. **分层冗余**： 对关键数据（如音频SILK层、视频I帧）采用更高冗余级别。 3. **带宽自适应**： 冗余率$r$与可用带宽$B$的关系： $$ r = \min\left(0.5, \ \frac{B - B_{\text{min}}}{B_{\text{max}} - B_{\text{min}}}\right) $$ 当$B$接近$B_{\text{min}}$时关闭冗余（优先保流畅性）。 --- ### 四、RED的适用场景与限制 | **场景** | **效果** | **限制** | |-------------------------|------------------------------|------------------------------| | 随机单包丢失（<15%） | 恢复率>90% | 突发丢包时失效 | | 低延迟通信（<200ms） | 比NACK重传更快恢复 | 带宽开销增加20%-50% | | 移动网络（4G/5G） | 对抗信号波动 | 需终端支持RED解码 | > 注：引用[3]强调RED在“带宽够”时效果显著，高丢包场景需结合FEC/NACK[^3]。 --- ### 五、调试与验证 1. **Wireshark分析**： 过滤RTP包查看RED头结构：`rtp.payload_type == RED_PT` 2. **WebRTC日志**： 启用`rtc_event_log`查看冗余包统计： ```bash peerconnection.setOptions({rtcEventLog: true}); ``` ---
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值