关于音视频:超低延迟直播架构解析

39次阅读

共计 2905 个字符,预计需要花费 8 分钟才能阅读完成。

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

文 / 朱晓恩
整顿 / 百度开发者核心
视频回放:https://developer.baidu.com/l…

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

  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/produ…

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

点击进入取得更多技术信息~~

扫描二维码,备注:音视频开发,立刻退出音视频开发技术交换群。

正文完
 0