本文由百度智能云-视频云直播技术架构师——朱晓恩 在百度开发者沙龙线上分享的演讲内容整理而成。内容从低延时直播背景与机遇出发，分析低延迟直播技术，重点分享百度在低延迟直播技术的实践工作。
文/ 朱晓恩
整理/ 百度开发者中心
视频回放：https://developer.baidu.com/live.html?id=10
本次分享的主题是：超低延迟直播架构解析，内容主要分为以下三个方面：
-
低延迟直播背景与机遇
-
低延迟直播技术分析
-
LSS低延迟直播技术实践
01
低延迟直播背景与机遇
随着各行各业直播的普及，加上疫情的强势推广。在线教育、直播带货、企业培训、线上招聘等实时互动的场景迅速升温。直播已成为企业数字化转型和内容营销的必备场景。
在直播中，用户实时互动体验一直是商家重点关心的问题。例如直播带货过程中，主播已经上完优惠券，10几秒过去了，用户却还在等待优惠券。超低延迟直播可以大大提升边看边买的体验，主播可以结合互动区更好实现控场和互动，并且让秒杀、抽奖、拍卖等对时效要求高的营销玩法有了更强的底层支撑，大大优化直播转换率。
又比如活动赛事直播场景中，电视/文字直播用户已在呐喊，而视频直播画面还未进球。超低延迟可以极大的加深观众对于现场实时互动的沉浸感，参与比分和现场的互动，提升用户对于线下活动的参与感。
而随着5G时代的到来，网络条件正快速提升：边缘带宽实现Mb向Gb增长，5G网络时延下降到1~10毫秒；依托于AR、VR技术的直播更是大大提升了用户的沉浸式体验。
这些对低延迟直播来技术，都是重大的机遇。
02
超低延迟直播架构解析
RTMP/FLV直播延迟原因分析
接下来，我们以一个简单的直播架构为例，分析传统的 RTMP/FLV 直播产生延迟的原因。
![]()
架构介绍：
主播通过 RTMP 推流到流媒体服务器，再从直播流媒体服务器通过 RTMP/HLS/FLV 等技术向观众分发包。
而一个视频直播传输过程如下：
视频输入摄像头采集数据——CDN传输——视频解码
「设备端处理延迟」、「网络层延迟」和「服务器内部处理延迟」。
1. 缓存策略
缓存策略主要指CND的GOP缓存，但这种缓存策略会增加延迟。码率过高或 GOP 太短会造成 TCP 累积延迟。
2. TCP累积延迟
编解码过程中，解码端在显示之前的视频帧缓存和编码端的缓存都会造成延迟。
3. 编解码缓存
解码端在显示之前的视频帧缓存和编码端的缓存都会造成延迟。
4. 编码
编码环节中的 B 帧解码也依赖于前后视频帧的到达。
由于以上原因，传统的基于 RTMP/FLV 的视频直播一般会产生 3-5 秒左右的延迟。延迟高的关键在于CDN的传输和播放解码没有很好地配合和互动。所以要实现低延迟，主要解决这个关键问题。
低延迟直播方案简单比较——基于UDP
![]()
基于 TCP 的视频直播存在较长的延迟。为此，人们开发出了 SRT、QUIC、WebRTC 等一系列基于 UDP 协议的低延迟直播方案。
下表可以简单概述一下基于UDP的各项低延迟直播方案的特点：
| UDP协议 |
延迟 |
流媒体特殊 |
生态 |
特点 |
| SRT |
毫秒级别 |
有 |
生态差，浏览器基本不支持。 |
拥塞控制较为简单，但是 SRT 协议需要对上下行进行改造。 |
| QUIC |
1~10秒 |
无 |
生态差，浏览器基本不支持。 |
传输层进行了优化，具有优秀的拥塞控制机制。 |
| WebRTC |
毫秒级别 |
有 |
生态好，大部分浏览器都支持。 |
专门为实时音视频通信设计的端到端解决方案，具有 QoS、低延迟等特性，具有实时双向的数据通道，为交互式体验提供了更多可能，可以扩展到会议、连麦等 RTC 场景下。 |
介于WebRTC生态繁荣，百度选择了WebRTC做为低延迟，在下一章节会基于百度智能云音视频直播服务LSS，详细介绍低延迟的直播方案实现。
03
LSS低延迟直播技术实践
LSS低延迟直播方案设计目标与过程
![]()
设计目标:
-
兼容已有直播业务，支持录制、截图、转码、RTMP/FLV等多协议分发。
-
支持百万并发，实现直播的CDN分发。
-
将延迟控制在1s以内。
实现过程：
如上图所示，在典型的 LSS 直播推拉流的流程中
-
主播首先在主播端通过 LSS 推流 SDK 实现 RTMP 推流 ，在该过程中将实现实时美颜、实时滤镜、视觉特效、硬件加速等功能；
-
视频流会被推到全球智能接流网络中，进而接入 LSS 媒体中心，通过服务器端 SDK 实现实时转码、自动鉴黄、多码率输出、实时水印、实时截图、内容加密、录制点播、统计分析等功能，打通与点播、存储、RTC 等其它云服务产品的联系。
-
接着，通过全球智能分发网络，基于 RTMP/FLV/HLS/WebRTC 等方案将视频流分发到客户端，通过 LSS 播放器 SDK 实现 LSS 播放，在该过程中，将实现首屏秒开、追帧播放、自适应码率、解密播放等功能。
直播场景改造
![]()
WebRTC 本身是面向多人会议的实时通信方案，为了使其更好地适用于直播场景，我们需要对其进行一系列的改造，从而支持大规模的低延迟直播分发。
-
就组件协议而言，采用 AAC、H.264 音视频引擎、UDP 传输层协议、RTP 媒体协议、RTCP 数据协议。通过 STUN/ICE 实现建联，并且通过 HTTP 请求实现 SDP 协商。
-
就QoS 方案而言，通过 NACK 的方式实现丢包重传。在播放侧进行基于 Jitter Buffer 的缓冲，在发送侧基于 PACING 机制调整发送的频率和码率，通过 GCC 实现拥塞控制，进而估计并反馈带宽。
-
就具体的改造点而言，仍然使用上行 RTMP 协议，支持非加密传输，音频转码支持 Opus，视频支持 B 帧，实现了 FLV timestamp 透传和 Metadata 透传。
直播CDN支持与质量
![]()
WebRTC 低延迟方案需要考虑对直播 CDN 的支持与质量。
首先，采用与 RTMP/FLV 等协议相同的多级直播 CDN 分发拓扑，实现回源与推流。
这套方案通过了大规模并发的考验，更加稳定成熟。在CDN 边缘节点上进行封装协议的转换，例如：WebRTC/FLV 协议可以复用节点回源数据，如果某条直播流上已经存在 WebRTC/FLV 的播放回源数据，就可以实现更快的响应。
此外，百度 WebRTC 低延迟方案依托于百度 CDN 的海量资源节点以及优质骨干传输网络，建立了覆盖全国的实时节点质量拨测系统与智能流量调度系统，实现了更完善的直播流质量监控系统，可以实时监控直播流回源过程中的卡顿等指标。
请求过程
![]()
WebRTC 低延迟方案的请求过程主要分为「媒体协商」、「网络协商」、「媒体传输&信令传输」三个阶段，我们进行的主要改造包括：
-
在媒体协商阶段中，在客户端通过 HTTP API 访问节点，从而携带播放的 URL、SDP Offer。在服务端，获得直播流对应的媒体描述，如果直播流已经存在于节点上，可以直接获得媒体描述，否则将会通过回源拉流来获取媒体描述。此外，会生成并记录会话 token，通过 HTTP 协议相应返回，通过 ice-ufrag 字段对应会话的 token。
-
在网络协商阶段中，通过 STUN 在客户端发起 Binding Request，并在 USERNAME 字段中携带会话 token。这样一来，我们在服务器端就可以通过 USERNAME 映射到 ice-ufrag 字段，从而对应到拉流的进程，返回 Binding Response。
-
在媒体传输 & 信令传输阶段中，实现 RTP 和 RTCP 的复用传输。
总结：
综上所述，LSS实现了基于 WebRTC 的低延迟端到端解决方案，该方案依托于成熟稳定的百度 CDN 直播分发架构，支持百万并发和多协议并发，能够兼容直播媒体中心的产品矩阵，接入的成本较低，打通了与 BRTC、BOS 等百度智能云产品的联系，支持更多的使用场景。
欢迎大家在百度智能云官网体验：https://cloud.baidu.com/product/lss.html
以上是老师的全部分享内容，有问题欢迎在评论区提出。
点击进入获得更多技术信息~~
扫描二维码，备注：音视频开发，立即加入音视频开发技术交流群。
![]()
