超低延迟直播架构解析
keki_kk 发布于2021-10 浏览:7633 回复:1
0
收藏

本文由百度智能云-视频云直播技术架构师——朱晓恩  在百度开发者沙龙线上分享的演讲内容整理而成。内容从低延时直播背景与机遇出发,分析低延迟直播技术,重点分享百度在低延迟直播技术的实践工作。

文/ 朱晓恩
整理/ 百度开发者中心
视频回放:https://developer.baidu.com/live.html?id=10

本次分享的主题是:超低延迟直播架构解析,内容主要分为以下三个方面:

  1. 低延迟直播背景与机遇
  2. 低延迟直播技术分析
  3. 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的各项低延迟直播方案的特点:



介于WebRTC生态繁荣,百度选择了WebRTC做为低延迟,在下一章节会基于百度智能云音视频直播服务LSS,详细介绍低延迟的直播方案实现。


03 LSS低延迟直播技术实践

| LSS低延迟直播方案设计目标与过程


设计目标:

  1. 兼容已有直播业务,支持录制、截图、转码、RTMP/FLV等多协议分发。
  2. 支持百万并发,实现直播的CDN分发。
  3. 将延迟控制在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


以上是老师的全部分享内容,有问题欢迎在评论区提出。

 

扫描二维码,备注:音视频开发,立即加入音视频开发技术交流群。

收藏
点赞
0
个赞
共1条回复 最后由用户已被禁言回复于2022-03
#3用户已被禁言回复于2021-10

跟着百度AI  完美提升自己

1
快速回复
TOP
切换版块