白话解读 WebRTC 音频 NetEQ 及优化实践-CSDN博客

本文链接：https://blog.csdn.net/yinshipin007/article/details/129937607

本文从宏观角度白话解读 WebRTC 中的 NetEQ，探讨丢包、抖动及其优化，介绍 NetEQ 及相关模块的工作原理、优化点，包括抗抖动、抗丢包及音视频同步的策略。通过对 NetEQ 的深入理解，帮助读者更好地掌握音视频通信中的服务质量提升。

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

1. 为什么要 “白话” NetEQ?

随便搜索一下，我们就能在网上找到很多关于WebRTC中音频 NetEQ 的文章，比如下面的几篇文章都是非常不错的学习资料和参考。特别是西安电子科技大学 2013 年吴江锐的硕士论文《WebRTC 语音引擎中 NetEQ 技术的研究》，非常详尽地介绍了 NetEQ 实现细节，也被引用到了很多很多的文章中。

《WebRTC 语音引擎中 NetEQ 技术的研究》

NetEQ 算法

WebRTC 中音频相关的 NetEQ

这些文章大部分从比较 “学术” 的或 “算法” 的角度，对 NetEQ 的细节做了非常透彻的分析，所以这里我想从更宏观一些的角度，说一下我个人的理解。白话更容易被大家接受，争取一个数学公式都不用，一行代码都不上就把思路说清楚，有理解不对的地方，还请大家不吝赐教。

2. 丢包、抖动和优化的理解

在音视频实时通信领域，特别是移动办公（4G），疫情下的居家办公和在线课堂（WIFI），网络环境成了影响音视频质量最关键的因素，在差的网络质量面前，再好的音视频算法都显得有些杯水车薪。网络质量差的表现主要有延时、乱序、丢包、抖动，谁能处理和平衡好这几类问题，谁就能获得更好的音视频体验。由于网络的基础延时是链路的选择决定的，需优化链路调度层来解决；而乱序在大部分网络条件下并不是很多，而且乱序的程度也不是很严重，所以接下来我们主要会讨论丢包和抖动。

抖动是数据在网络上的传输忽快忽慢，丢包是数据包经过网络传输，因为各种原因被丢掉了，经过几次重传后被成功收到是恢复包，重传也失败的或者恢复包过时的，都会形成真正的丢包，需要丢包恢复 PLC 算法来无中生有的产生一些假数据来补偿。丢包和抖动从时间维度上又是统一的，等一会来了的是抖动，迟到很久才来的是重传包，等一辈子也不来的就是 “真丢包”，我们的目标就是要尽量降低数据包变成 “真丢包” 的概率。

优化，直观来讲就是某个数据指标，经过一顿猛如虎的操作之后，从 xxx 提升到了 xxx。但我觉得，评判优化好坏不能仅仅停留在这个维度，优化是要 “知己知彼”，己是自己的产品需求，彼是现有算法的能力，己彼合一才是最好的优化，不管算法是简单还是复杂，只要能完美的匹配自己的产品需求，就是最好的算法，“能捉到老鼠的就是好猫”。

★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。

见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓