揭秘并解决直播延迟问题(直播延迟怎么解决)

媒体和娱乐行业近期最引人注目的市场趋势之一是流媒体直播的增长。全球流媒体直播市场从 2022 年的 12.4 亿美元增至 2023 年的 14.9 亿美元，复合年增长率（CAGR）为 20.6%。根据 Research and Markets 的一份报告，预计到 2027 年，全球直播市场规模将增至 32.1 亿美元，复合年增长率为 21.2%，这表明市场的发展势头还将继续。

这一趋势的主要驱动力是流媒体消费行为的演变。德勤发布的第 17 份年度《数字媒体趋势报告》发现，消费者，尤其是年轻消费者，已经从在家观看电视节目和电影转向社交媒体上的用户生成内容（UGC），以及对社交联系的渴望，通常是通过视频游戏这一载体（德勤称，近一半的 Z 世代和千禧一代游戏玩家表示，他们在视频游戏中的社交多于在现实世界中的社交）。

对于内容创作者、有影响力的人和企业来说，直播已成为一个利润丰厚的收入来源。媒体和娱乐领域的许多公司都利用直播技术来吸引更广泛的受众，或更好地支持广告商直播体育赛事、健身课程、虚拟学习、音乐会和艺术品拍卖等。

由于这些社会和经济驱动因素，流媒体直播急剧增加，预计未来的发展轨迹也将如此，因此，流媒体直播平台和解决方案必须为越来越多、越来越分散的受众提供流畅、可靠和高质量的体验。实现这一目标的关键之一是解决直播延迟问题。

定义延迟及其重要性

延迟可简单定义为数据传输初始化与数据传输实际开始之间的时间。就实时视频流而言，它可以解释为视频帧从捕获到显示给用户之间的延迟–也可以将延迟定义为视频流时钟与实时时钟之间的延迟。

对于视频游戏锦标赛、体育竞赛或艺术品拍卖等直播活动来说，延迟是一个至关重要的方面。任何直播延迟，哪怕只有 10-30 秒的延迟，都会导致流媒体中断，降低用户体验的可靠性，这在实时信息意味着一切、分秒必争的环境中是不可接受的。

鉴于近年来观众和流媒体用户的增加，解决直播延迟问题比以往任何时候都更加重要。在最新的 Bitmovin 调查中，由 42 个国家的视频开发人员和行业专家组成的 25% 的参与者认为低延迟是他们面临的最大挑战之一。这也是受访者认为服务创新机会最多的第三大问题。

既然实现低延迟是如此重要的挑战，并被视为创新的首要重点，那么直播延迟问题的根本原因是什么？

直播延迟的原因及解决方法

影响直播延迟的一个重要方面是视频编码。在流媒体传输过程中，需要对视频进行编码、传输和解码。编码高质量视频需要消耗大量计算能力，这不可避免地会增加直播流编码过程中的延迟。输入和输出流的质量越高，对延迟的影响就越大。

造成延迟的另一个原因是大多数 OTT 流媒体技术（如 HLS 或 MPEG-DASH）所使用的伪流媒体协议的本质。这些协议将视频流内容分割成小段或 “块”，然后由接收设备按顺序下载。这些数据块的尺寸越大，每个数据块从下载到到达观众手中所需的时间就越长。相反，视频片段越小或越短，下载速度就越快，观看体验就越流畅。

延迟会受到网络配置问题和拥塞的严重影响，有几种方法可以缓解这些问题。在大多数情况下，自适应比特率技术有助于解决网络配置问题和与较低带宽相关的问题。内容分发网络（CDN）应针对延迟进行优化，例如利用 HTTP/2 Push 和 HTTP/3 协议加快数据传输，以及使用多路复用和标题压缩。理想情况下，CDN 提供商应与该地区的主要 ISP 网络直接连接，以促进延迟优化。最后，CDN 服务器的数量应足够多，以确保存在点与终端用户之间的物理距离不会影响延迟。当 CDN 服务器与用户的物理距离更近时，用户与服务之间的路由更容易预测，从而减少延迟的变化。

HLS 和 MPEG-DASH 利用成熟的 CDN 基础设施进行视频传输，确保了成本效益和可扩展性。但是，在实时事件和终端用户屏幕传输之间通常会有 30 秒的延迟，这不适合体育直播和类似应用。如何才能在利用现有 CDN 基础设施的同时实现最小延迟？低延迟伪流协议（如低延迟 HTTP 实时流（LL-HLS）和 HTTP 低延迟动态自适应流（LL-DASH））提供了 HLS 和 MPEG-DASH 标准的改进版本，解决了延迟问题。

这些卓越的伪流媒体协议背后的主要理念是尽可能缩短视频块，每个视频块的大小约为 300-500 毫秒（ms）。在这一水平上，它们的传输速度更快，延迟更少，从而减少了渲染第一个视频帧的延迟。CDN 的发展使这种能力成为可能，因为 CDN 现在已经具备了管理更频繁的较小视频片段请求的能力。

然而，对于带有实时语音和视频聊天功能的在线游戏等应用来说，即使是 300 毫秒的延迟也可能过高。当需要超低延迟时，必须使用实时流协议。在实时流式传输中，通信双方之间会建立连接，并在数据生成后立即逐帧传输。每当新的数据块准备就绪，就会被推送到现有的连接上。

有两种成熟的解决方案可用于双向实时通信： RTMP 和 WebRTC。

RTMP 是一种经典的客户端-服务器协议，自 1996 年以来就一直存在。它由 Macromedia 设计，后被 Adobe 收购。RTMP 在许多项目和视频应用（包括 ChatRoulette 和 Periscope）的成功中发挥了重要作用。不过，现在人们认为创建一个可以通过 TCP 或 UDP 直接连接其他服务器的插件是不安全的。因此，自 2016 年起，Web浏览器不再支持 RTMP 播放。不过，RTMP 仍在许多应用中使用，例如将视频流推送到 YouTube 或 Facebook。此外，多家无人机供应商主要使用 RTMP 将其信息传送到远程服务器。

2011 年，谷歌启动了 WebRTC 项目，为实时通信提供了手段，而不直接允许插件和 JavaScript 访问 TCP/UDP。该项目成为Web实时通信的标准，包括亚秒级延迟的视频聊天和文件传输。

解决直播延迟的策略：即构低延迟直播方案(畅直播)

前面说过，媒体协议最大程度决定直播低延时能力。基于TCP的RTMP/HTTP-FLV/HLS 等流媒体协议均存在3秒以上的延时，后来市面上出现WebRTC技术，且是开源的，其一定程度可以解决延时问题，然而该技术最大支持30%丢包，在网络环境不好时表现一般，且对 H264 支持有限，增加了开发者负担。

在解决直播延时问题上，即构自主研发媒体协议 AVERTP ，支持 H264，VP8和 HEVC 等多种编码格式，在 ABC（码率自适应）的基础上，结合包含 FEC（前向纠错）、ARQ（丢包重传）和 PLC（错误隐藏）的智能 QoS 信道策略，充分利用链路带宽，保证音视频传输的低延迟、弱网抗性和多端的同步性。

即构自主研发了MSDN ，基于音视频服务的特性、结合 SDN 架构，将不同供应商的 IDC、络线路等资源整合成一张“虚拟网络”，具有中立弹性、路径最优、可智能识别业务并在传输层优化、灵活可靠等特性，可以更好地解决大规模直播普遍存在的高并发、网络复杂与网络自适应等问题。

正因为重视技术且一开始就走自研路线，即构可以开发自己的媒体协议与虚拟网络，低延迟直播产品(畅直播)攻克了基于TCP的直播技术的延时问题，同时规避了WebRTC的短板。基于即构智能 QoS 策略，畅直播产品在 70% 丢包下，依然可以保证稳定的观看体验，在千万级并发规模下，可以做到毫秒级延迟新体验，相比市面上的直播技术服务更加稳定可靠。

免费体验 畅直播 >>