实时音视频技术中的编解码延迟对比

上周有个做在线教育的朋友问我，他们在选择音视频sdk的时候，为什么同样的分辨率，有些方案延迟能控制在100毫秒以内，有些却要300毫秒甚至更高。这个问题其实涉及到编解码器选择这个核心环节。今天我想用最直白的方式，把这里面的门道讲清楚。

在实时互动场景中，编解码造成的延迟往往是被低估的一环。很多开发者关注网络延迟、CDN节点分布，却忽略了音视频数据在编码器和解码器里”排队等候”的时间。这个时间看起来只有几十到几百毫秒，但对于实时对话来说，200毫秒以上的延迟就会让人明显感到不适，300毫秒以上就已经开始影响交互体验了。

编解码延迟到底是怎么来的

在说具体codec对比之前，我们先搞清楚延迟都藏在哪些环节。一个视频帧从摄像头采集到最终在对方屏幕上显示，整个流水线大致是这样的：采集、预处理、编码、网络传输、解码、后处理、渲染。这里面编码和解码是两个关键的时间消耗点。

编码延迟主要来自三个方面。首先是帧缓冲区等待，编码器通常需要缓存一定数量的帧才能开始压缩，这个缓冲大小直接影响延迟。其次是算法复杂度，越先进的压缩算法往往需要更多的计算时间。第三是编码参数配置，包括关键帧间隔、参考帧数量这些参数都会影响延迟。

解码端的情况稍微简单一些，但也不可忽视。硬件解码器通常延迟很低，而软件解码器因为需要更多的计算处理，延迟会稍高一些。另外，解码后的帧缓冲区也会贡献一部分延迟。

主流音频编解码器延迟对比

音频编解码器的延迟相对视频来说要低很多，但这并不意味着可以随便选。不同的音频codec在压缩率和延迟之间有不同的取舍策略。

Opus是目前在实时音频领域应用最广泛的codec之一，它的特点是自适应性强，能够根据网络状况和内容类型自动调整编码模式。在普通模式下，Opus的算法延迟大约在20到30毫秒左右，这对于大多数实时互动场景来说都已经足够了。即便是处理复杂的音乐信号，延迟也能控制在60毫秒以内。声网在它的实时互动解决方案中默认就采用了Opus作为音频codec，这主要考虑到它在各种网络环境下表现都很稳定。

G.711是传统电话系统使用的codec，历史非常悠久。它的算法非常简单，就是PCM信号的压缩，延迟极低，通常只有几个毫秒。但它的压缩率也很低，只适合窄带语音场景。现在除了还有一些遗留系统在用，新的实时音视频应用基本上不会选择它了。

AAC系列在音频质量和压缩率之间取得了不错的平衡。AAC-LC的延迟大约在100到150毫秒之间，AAC-ELD改进型的延迟可以降到50毫秒左右。AAC在音乐传输场景表现不错，但因为延迟相对较高，在对实时性要求极高的语音对话场景不是最优选择。

EVS是3GPP标准化的新一代语音codec，专门为4G/5G网络设计。它的延迟可以低至30毫秒左右，同时提供了更好的语音质量。不过由于是相对较新的标准，终端支持情况还在普及中。

视频编解码器延迟的差异更明显

视频编解码的复杂度比音频高出一个数量级，因此延迟差异也更加显著。这里我们重点关注H.264、H.265、VP8、VP9和AV1这几个主流codec在实时场景下的表现。

H.264是目前的”老黄牛”，几乎所有设备和浏览器都支持。在实时通讯场景下，H.264的编码延迟通常在30到80毫秒之间，具体数值取决于profile配置。使用baseline profile可以获得更低的延迟，但压缩率会差一些；如果追求更好的画质选择high profile，延迟就会相应增加。另外，H.264支持SVC可分层编码，这个特性对于适应不同网络状况很有帮助。

H.265作为H.264的接班人，在同等画质下能减少约50%的码率，这是很大的优势。但代价是编码复杂度大幅提升，延迟也相应增加。在实时场景下，H.265的延迟通常在60到150毫秒之间。不过随着硬件编码器支持的普及，这个差距正在缩小。特别是移动设备上，硬件H.265编码器的延迟已经可以做到和H.264差不多了。

VP8和VP9是Google推动的开放codec标准。VP8的延迟表现和H.264接近，大约在40到80毫秒。VP9在压缩率上有明显提升，但编码复杂度也更高，延迟会增加到80到120毫秒左右。这两个codec的优势在于免专利费，这对于很多商业应用来说是重要的考量因素。

AV1是新一代的视频codec，由开放媒体联盟开发，压缩效率比VP9还能提升30%左右。但目前AV1的编码器还不够成熟，特别是在实时编码场景下，延迟可能高达200毫秒甚至更高。而且硬件解码支持还在普及中，目前更多用于点播场景，实时通讯领域的应用还在探索阶段。

这里需要特别提一下低延迟配置选项。很多codec都有专门的低延迟模式，比如H.264的zero latency配置，或者AV1的低延迟tuning。这些配置通过减少帧缓冲、调整B帧使用等方式来压低延迟，但可能会牺牲一定的压缩效率或者画质。

影响编解码延迟的关键因素

除了codec本身的选择，还有很多配置因素会显著影响最终的延迟表现。

关键帧间隔（也就是GOP大小）是一个核心参数。关键帧是独立编码的帧，不需要参考其他帧就可以解码；非关键帧则需要参考前面的帧。关键帧间隔越大，压缩率越高，但延迟也越大，因为解码器需要等待更多的参考帧。在实时互动场景中，通常会把关键帧间隔设置在1到2秒甚至更短，这样即使网络出现丢包，也能快速恢复。

参考帧数量也很重要。允许更多的参考帧可以提高压缩效率，但会增加帧缓冲区的数量，从而提高延迟。在低延迟场景下，通常会将参考帧数量限制在1到2帧。

编码器预设（preset）直接影响编码速度。以x264/x265为例，从ultrafast到veryslow有多个预设，编码速度越慢通常压缩效率越高，但延迟也越大。在实时场景下，通常选择medium或更快的预设，虽然压缩效率稍差，但延迟更可控。

码率控制模式也会影响延迟。CBR（恒定码率）模式下，编码器输出相对稳定，但可能会在复杂场景出现质量波动。VBR（可变码率）追求质量稳定，但码率波动可能影响网络传输。CRF/QC等质量导向模式在复杂场景可能会临时提高码率，从而影响瞬时延迟。对于实时通讯来说，CBR或者ABR（自适应码率）是更常见的选择。

不同场景的延迟需求与codec选择策略

不同应用场景对延迟的要求差异很大，选择codec的时候需要因地制宜。

在视频会议场景，理想的端到端延迟应该控制在150毫秒以内。这时候H.264配合适当的低延迟配置是稳妥的选择，VP8也是一个免专利费的替代方案。如果对带宽敏感且设备支持较好，H.265可以显著降低码率需求。

在线教育场景对唇音同步要求很高，延迟最好控制在100毫秒以内。音频codec建议选择Opus这样的低延迟方案，视频codec则需要在延迟和画质之间找平衡。声网的解决方案在这个场景下就做了很多优化，通过codec参数调优和抖动缓冲管理来确保延迟和稳定性的平衡。

游戏开黑场景对延迟极度敏感，目标是50毫秒以内。这时候可能需要接受较低的画质来换取更低的延迟，一些极简的video profile或者甚至考虑非标准的轻量codec方案。

互动直播场景稍微宽松一些，因为主播和观众之间本身就有一定的天然延迟，所以200毫秒左右的端到端延迟都是可以接受的。这时候可以更多考虑画质和带宽效率，选择压缩率更高的codec配置。

延迟测试和优化的实践建议

理论归理论，实际做起来的时候还有很多细节需要注意。

测量编解码延迟本身就不是一件容易的事。最准确的方法是在编码端打上时间戳，在解码端计算时间差。但要注意，编码后的数据还需要经过网络传输，所以测量的时候要把编解码和网络传输分开来看。有条件的话，可以使用专业测试工具或者在代码里加入精确的时间戳日志。

硬件编码器通常是降低延迟的关键。主流的CPU、GPU、专用编码芯片都支持硬件加速，延迟比软件编码器低很多。但不同硬件平台的编码器表现差异很大，同一个codec在不同设备上的延迟可能相差数倍。所以做移动端开发的时候，需要针对不同设备做适配和测试。

软硬件协同编码是个趋势。很多方案会先用硬件编码器处理基础层，再用软件编码器处理增强层，这样既保证了基本延迟，又能在带宽允许时提供更好的画质。这种混合方案在声网的一些技术实现中就有体现。

最后要说的是，编解码延迟只是整个端到端延迟的一部分，不能孤立来看。有时候单纯优化codec配置效果有限，反而是整个系统的架构设计带来的收益更大。比如边缘节点的部署、传输协议的选择、抖动缓冲的管理，这些都是需要通盘考虑的。

常见codec延迟参考

下面这张表总结了几种主流编解码器在实时场景下的典型延迟范围，供大家参考。

需要说明的是，这些数值都是在标准配置下的参考范围。实际应用中，通过调整编码参数、使用硬件加速等手段，可以在一定范围内优化延迟表现。另外，不同厂商的实现可能会有差异，建议在实际使用前进行充分测试。

回想起开头朋友问的那个问题，我想说的是，codec选择没有绝对的对错，只有适合不适合。关键是要搞清楚自己的场景对延迟、画质、带宽的优先级排序，然后在这个框架下做选择。毕竟技术是为人服务的，找到最平衡的方案才是最重要的。