低延时直播的延迟优化方法有哪些

前阵子有个朋友问我，说他公司做直播电商，用户经常抱怨画面和声音不同步，有时候点击购买按钮，主持人已经讲到下一个产品了，差个几秒钟，转化率直接掉一截。他问我有没有什么办法能把延迟压下来。这让我意识到，虽然直播大家都在做，但”延迟”这个事儿，真正认真研究过的人可能并不多。

今天咱们就掰开了聊聊，低延时直播到底是怎么实现的，哪些环节会影响延迟，又有哪些方法可以优化。咱们不说那些玄之又玄的概念，就从实际的技术链条出发，一步步拆解来看。

延迟到底是从哪里来的

在说优化方法之前，得先搞清楚延迟是怎么产生的。这就像修水管得先知道哪里漏一样，不然使了半天劲，问题没解决还累得够呛。

整个直播的技术链路其实挺长的，从主播那一端的摄像头采集开始，中间要经过编码、网络传输、分发、CDN加速，最后到观众手机上解码渲染显示出来。每一个环节都会贡献一点延迟，这些延迟累加起来，就成了我们感受到的最终延迟。

我给大家拆解一下这几个主要的延迟来源，这样后边讲优化方法的时候，你们就能明白为什么要在那个环节上下功夫了。

采集与编码端的延迟

首先是采集和编码这一块。摄像头采集到的原始视频数据量是非常大的，比如说1080p、30帧的视频，一秒钟的数据量轻松突破100MB，这显然没办法直接往网上发，所以必须经过编码压缩。

编码过程需要时间，这个大家都能理解。但很多人不知道的是，为了保证画质，编码器通常会做一些帧间预测，也就是参考前后帧来压缩数据。这就导致编码器必须缓存一定量的帧才能开始工作，这部分缓存带来的延迟有时候能达到几百毫秒甚至更高。

另外，有些编码器为了追求更好的压缩效率，会使用更大的GOP（图像组）长度，这意味着帧与帧之间的依赖关系更复杂，延迟也就更高。如果是使用软件编码，CPU的处理速度也会成为瓶颈，导致编码队列积压，延迟进一步增加。

网络传输的延迟

数据编码完成之后，就要通过网络发出去了。这段的延迟主要来自几个方面：物理距离、网络质量波动、还有协议本身的特性。

物理距离很好理解，数据从北京传到上海和传到纽约，时间肯定不一样。虽然光速很快，但网络节点之间的路由转发、排队等待都会增加延迟。特别是如果跨运营商、跨国家，延迟的波动会非常明显。

网络质量波动这个问题更棘手。家用宽带、移动网络都会出现带宽抖动，有时候好有时候差。传统直播协议对网络波动的适应能力有限，一旦出现丢包或者延迟飙升，画面就会卡住或者延迟累积。这也是为什么很多直播在网络不好的时候会越来越慢的原因。

解码与渲染端的延迟

终于说到最后一步了。观众拿到数据之后，要先解码再渲染显示出来。解码本身也需要时间，特别是高分辨率视频，用软件解码的话，CPU性能直接影响解码速度。

渲染环节的延迟往往被忽略。显示设备从接收到画面数据到真正显示出来，是需要时间的。不同类型的显示器延迟不一样，OLED通常比LCD快，高刷新率的显示器延迟也更低一些。另外，系统层面的垂直同步、帧缓冲策略都会增加额外的延迟。

还有一点很多人没想到，就是播放器端的缓冲策略。为了保证播放流畅，播放器通常会预加载一定的数据作为缓冲，这个缓冲池的大小直接影响启动延迟和卡顿后的恢复速度。缓冲设得越大，越不容易卡，但延迟也就越高。这是一个需要权衡的事情。

从源头抓起：编码与采集环节的优化

清楚了延迟的来源，咱们就可以针对性地采取措施了。先从最源头说起，采集和编码环节怎么优化。

硬件编码是个好东西。现在新款电脑、手机、相机基本都内置了硬件编码器，比如Intel的QuickSync、AMD的VCE、苹果的VideoToolbox，还有英伟达的NVENC。这些硬件编码器的速度比软件编码快得多，而且延迟可以做到很低。因为硬件编码是专用电路做的，延迟通常在毫秒级别，而软件编码可能要几十甚至上百毫秒。

如果条件允许，优先使用硬件编码。特别是做低延时直播的场景，硬件编码带来的延迟优势是很明显的。当然硬件编码也有缺点，比如同样的码率下画质可能不如高质量的软件编码，但为了延迟，这个取舍是值得的。

编码参数的设置也非常关键。刚才提到GOP长度，这是影响延迟的一个重要因素。GOP越长，压缩效率越高，但延迟也越大。如果追求低延迟，建议把GOP设置短一些，甚至可以采用全I帧编码，也就是每个帧都不参考其他帧，直接独立编码。这样虽然码率会高很多，但延迟可以降到最低。

分辨率和帧率也要合理选择。不是越高越好，1080p 60帧肯定比720p 30帧延迟更容易上去，因为数据量大了，处理时间自然就长。根据实际场景选择合适的分辨率和帧率，既能满足观众需求，又能控制延迟，这才是明智的做法。

码率的设置同样有讲究。码率太低会导致画质差，码率太高又会增加延迟和带宽压力。在低延时场景下，建议使用ABR（自适应码率）技术，根据网络情况动态调整码率，而不是固定一个码率不变。这样可以保证在网络好的时候画质清晰，网络差的时候至少能维持流畅，不出现严重的延迟累积。

协议选对了，延迟就成功了一半

网络传输协议的选择对延迟的影响非常大，甚至可以说选对协议就成功了一半都不为过。

传统直播常用的协议是RTMP，这个协议诞生年代比较早了，延迟通常在2到5秒左右。为什么延迟这么大？因为RTMP是基于TCP的，而TCP要保证可靠性，就会先建立连接、确认收到、重新发送丢包的数据。这一套流程走下来，延迟就上去了。而且RTMP的流式处理能力也不如新协议好。

后来出了HTTP FLV和HLS这两个协议，它们本质上都是把直播流切成小片段，通过HTTP下载来播放。HLS切得比较碎，延迟通常在10秒以上；HTTP FLV好一些，能做到1到3秒左右。但它们本质上还是没有解决TCP带来的延迟问题，而且切片机制本身就会引入额外的延迟。

webrtc的出现改变了这个局面。这个协议本来是为了实时音视频通话设计的，比如微信视频通话用的就是webrtc或者类似的技术。它最大的特点是延迟可以做到毫秒级别，最低能到200毫秒以内，非常夸张。

WebRTC为什么这么快？主要得益于几个设计。首先它使用UDP协议传输，UDP不保证数据包的到达，也不按顺序，这看起来是缺点，但恰恰因为不用等重传、不用排序，延迟就下来了。然后WebRTC有自己的丢包恢复机制和拥塞控制算法，能够在网络波动时快速调整，既保证实时性，又尽量减少卡顿。

另外WebRTC还支持端到端的加密，安全性比较好。这也是为什么现在很多对延迟要求高的场景，比如互动直播、在线教育、远程会议，都开始采用WebRTC技术。

像声网这样的专业实时互动服务商，就是在WebRTC基础上做了大量优化，让开发者能够轻松接入低延迟直播能力。他们在全球部署了大量的边缘节点，通过智能路由选择最优传输路径，进一步降低了跨区域传输的延迟。对于很多中小企业来说，与其自己从头搭建WebRTC服务，不如直接使用现成的SDK来得高效。

当然WebRTC也不是没有缺点，它的开发成本比较高，需要处理信令服务器、STUN/TURN穿透、媒体协商等一系列问题。如果团队没有相关经验，直接上手确实有难度。这也是为什么很多开发者选择使用成熟方案的原因。

主流直播协议延迟对比

传输网络怎么优化

选好了协议，接下来是传输网络的优化。这一块主要靠CDN和智能调度来实现。

CDN，也就是内容分发网络，应该是直播行业的老朋友了。CDN的原理很简单就是把内容缓存到离用户最近的节点上，这样用户就不用跨越大半个中国去取数据，延迟自然就下来了。对于传统直播来说，CDN是标配，没有CDN的话，直播根本没法大规模分发。

但传统CDN是为HTTP协议设计的，对WebRTC的支持并不是特别好。因为WebRTC需要端到端的连接，CDN那种缓存和分发的模式不太适用。所以后来出现了专门为实时传输设计的边缘网络，比如声网的SD-RTN（Software Defined Real-time Network），这种网络在全球主要地区都部署了节点，能够实现毫秒级的传输延迟。

智能调度也是降低延迟的关键。用户的网络情况是动态变化的，有时候这个节点好，有时候那个节点好。智能调度系统需要实时监测各节点的网络质量，把用户请求路由到最优的节点上。这里面涉及的算法包括延迟预测、负载均衡、故障切换等等，还是挺复杂的。

边缘计算是另一个值得关注的方向。传统架构下，所有的处理都在云端完成，然后分发到边缘。边缘计算则是把一部分计算任务下沉到离用户更近的地方，比如在边缘节点完成转码、切片等工作，这样既能降低延迟，又能减轻云端压力。对于低延时直播来说，边缘计算的价值是很明显的。

客户端播放器的优化

最后说说客户端这一侧。服务器端做得再好，如果播放器端拖后腿，整体延迟还是会上去。

解码器的选择很重要。软解码灵活性高，什么格式都能播，但CPU占用高，延迟也难以下降。硬解码用GPU或者专用电路来解码，速度快延迟低，但兼容性需要处理好。在低延时场景下，建议优先使用硬解码，并且确保硬解码的参 数设置正确，不要让解码器引入额外的延迟。

播放器的缓冲策略需要仔细调教。传统播放器的缓冲通常在5到10秒甚至更长，为的是保证绝对不卡顿。但在低延时场景下，这个缓冲就太大了。应该根据网络质量动态调整缓冲大小，网络好的时候缓冲可以小一些，网络差的时候适当增大，但不能无限制地增大导致延迟失控。

首帧加载速度也值得关注。观众点进来到看到画面的这段时间，叫做首帧延迟。这个延迟主要来自DNS解析、TCP连接、HTTP请求、解码初始化等一系列步骤。优化首帧速度的方法包括预连接、预加载、复用连接池、优化解码器初始化流程等等。对于用户来说，首帧延迟是最直接感受到的延迟，优化好了体验提升很明显。

特殊场景的特殊处理

不同场景对延迟的要求其实不太一样，不能一刀切。

互动直播场景是最严格的。比如直播带货，观众要和主播实时互动，问答、秒杀、下单这些操作都需要即时反馈。这时候延迟必须控制在500毫秒以内，否则互动体验会非常差。WebRTC加边缘节点是这类场景的首选方案。

大型赛事直播的延迟要求相对宽松一些。这类场景观众主要是看内容，对互动需求不高，延迟在2到3秒左右是可以接受的。这时候可以采用HTTP FLV或者低码率的WebRTC切片，在延迟和成本之间找个平衡点。

还有一类是超低延迟的特定应用，比如远程手术指导、工业遥控、自动驾驶的视频回传。这类场景对延迟的要求可能是100毫秒甚至更低，而且对可靠性要求极高，通常需要使用私有的传输协议和网络方案，不是一般企业能玩得转的。

写到最后

关于低延时直播的优化方法，咱们今天聊了不少。从采集编码到网络传输，再到客户端播放，每个环节都有可以优化的点。但说回来，技术只是手段，关键还是要看业务场景的需求。盲目追求极低延迟可能会带来成本的急剧上升，得不偿失。

如果你们公司正打算做低延时直播，我的建议是先想清楚业务场景对延迟的真正要求是多少，然后再倒推需要采用什么样的技术方案。有时候差个几百毫秒用户根本感觉不出来，这时候过度优化就是浪费资源。

另外，对于技术资源有限的团队来说，借助声网这样的专业平台来完成底层传输的搭建，把精力集中在业务逻辑上，可能是更明智的选择。毕竟术业有专攻，专业的事情交给专业的人来做，效率更高，效果也更有保障。