CN117041610A - 低延迟直播应用场景下的非对称式sfu媒体网关架构 - Google Patents

Abstract

本发明涉及一种低延迟直播应用场景下的非对称式SFU媒体网关架构，直播流注入直播信号进入编码器，经过音视频处理后送入SFU网关进行分发，编码器到SFU网关这段网络通路使用保证质量优先的传输协议，无需根据网络条件进行反馈处理；SFU网关在直播流分发侧，使用标准WebRTC协议栈，利用WebRTC自适应低延迟播放的特性，多终端分别和SFU网关服务器建联，实现支持多终端的低延迟直播分发。基于WebRTC协议设计网关框架，实现了从直播流采集编码注入，媒体服务器流分发和客户端解码播放的全链路低延迟优化。被所有主流操作系统和浏览器所支持，可以实现多终端低延迟播放；WebRTC基于UDP的传输和高度优化的自适应低延迟播放引擎可以实现稳定流畅的低延迟播放。

Description

低延迟直播应用场景下的非对称式SFU媒体网关架构

技术领域

本发明涉及一种直播技术，特别涉及一种低延迟直播应用场景下的非对称式SFU媒体网关架构。

背景技术

直播延时指直播源画面与播放端播出画面之间的时间差值，低延迟直播指延时降低到毫秒级的直播，低延迟直播系统通常指延迟低于1秒的直播系统。

基于RTMP协议的直播：RTMP协议是流媒体传输标准协议，实时流传输协议，是TCP/IP协议体系中的一个应用层协议，有广泛的服务器和终端播放器支持，已经大规模应用于CDN(Content Delivery Network，内容分发网络)直播系统。其缺点是基于TCP(Transmission Control Protocol)传输控制协议，抗网络抖动的能力一般，终端播放器实现未针对低延迟场景进行优化，直播延迟通常在2秒以上。

基于UDP协议的直播：包括基于SRT传输层协议或其他私有协议的直播系统。这类系统一般可以将直播延迟降低到1秒以内，但是通常不具备穿越NAT(Network AddressTranslation，网络地址转换)传输的能力。播放终端为专有实现，第三方接入时需要集成SDK,无法支持网络浏览器的低延迟播放。

发明内容

针对低延时直播问题，提出了一种低延迟直播应用场景下的非对称式SFU媒体网关架构，基于WebRTC协议设计网关框架，实现了从直播流采集编码注入，媒体服务器流分发和客户端解码播放的全链路低延迟优化。

本发明的技术方案为：一种低延迟直播应用场景下的非对称式SFU媒体网关架构，直播流注入直播信号进入编码器，经过音视频处理后送入SFU网关进行分发，编码器到SFU网关这段网络通路使用保证质量优先的传输协议，无需根据网络条件进行反馈处理；SFU网关在直播流分发侧，使用标准WebRTC协议栈，利用WebRTC自适应低延迟播放的特性，多终端分别和SFU网关服务器建联，实现支持多终端的低延迟直播分发。

优选的，所述终端和SFU网关服务器建联中，SFU网关服务器侧在标准协议框架内，在收到客户端SDP中包含的地址信息并建联成功后，就立即开始媒体RTP包发送，而不等待ICE所有候选地址探测完成，同时SFU网关服务器增加了GOP cache,始终缓存最近一个GOP的媒体数据，在有新的客户端请求开始播放时，将GOP cache发送给客户端。

优选的，所述GOP cache采用GOP fast flush机制，在不修改WebRTC客户端实现的前提下，起播时以2倍码率速度发送GOP cache是一个平衡点，在避免UDP流瞬时burst流量过大引起丢包进而触发客户端增大Jitter Buffer的同时,实现直播首帧快速显示，并利用WebRTC追帧的特性，显示首帧后快速追上最新的视频帧，实现平滑的起播体验。

优选的，所述终端为机顶盒，客户端在WebRTC C++核心层针对低延迟直播场景进行优化，包括:减小Jitter Buffer动态伸缩的上限，在高码率条件下，避免帧间传输耗时的波动频繁触发Jitter Buffer的增大；使用低延迟渲染组件，降低大屏幕画面上屏延迟。

优选的，所述机顶盒客户端通过修改WebRTC库以采用激进的缓冲区管理策略，通过使用硬件加速的安卓渲染组件降低渲染延迟，降低网口带宽和设备解码渲染导致的直播延迟。

优选的，所述标准WebRTC协议栈，媒体传输层在UDP之上增加了3个协议：

数据包传输层安全性协议DTLS：用于加密媒体数据和应用程序数据；

安全实时传输协议SRTP：用于传输音频和视频流；

流控制传输协议SCTP：用于传输应用程序数据。。

本发明的有益效果在于：本发明低延迟直播应用场景下的非对称式SFU媒体网关架构，WebRTC被所有主流操作系统和浏览器所支持，可以实现多终端低延迟播放；WebRTC基于UDP(User Datagram Protocol，用户数据报协议)的传输和高度优化的自适应低延迟播放引擎可以实现稳定流畅的低延迟播放。

附图说明

图1为本发明WebRTC技术架构示意图；

图2为Mesh网络结构示意图；

图3为本发明使用的SFU网络结构示意图；

图4为本发明适用于低延迟直播应用场景下的非对称式SFU媒体网关架构图；

图5为本发明直播流分发侧WebRTC标准网络协议栈图；

图6为本发明终端和SFU网关服务器建联时序图。

具体实施方式

下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。

本发明使用WebRTC协议作为传输协议，所有支持WebRTC的终端设备都可以接入，利用WebRTC面向低延迟音视频通信的能力，实现基于标准协议的低延迟播放，具有WebRTC跨NAT传输，抗网络抖动，自适应播放的能力。各公有云厂商也有基于WebRTC的低延迟直播产品，但是他们不支持运营商私有部署(只支持所有用户接入统一的公有云平台)。因此无法支持企业客户如有线电视运行商的业务场景。需要开发设计客户端或服务端或媒体端的网关架构，保证低延迟直播产品在连接运用后也保持低延迟。

WebRTC，名称源自网页即时通信(Web Real-Time Communication)的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。

WebRTC使用安全实时传输协议SRTP(Secure Real-time Transport Protocol)对RTP(Real-time Transport Protocol实时传输协议)数据进行加密，消息认证和完整性以及重播攻击保护。它是一个安全框架，通过加密RTP负载和支持原始认证来提供机密性。WebRTC的安全特性是其可靠性的重要组成部分，其基础全部围绕实时传输协议RTP进行。

如图1所示WebRTC技术架构示意图，WebRTC技术架构的顶层分为两个部分：

一部分为Web API：架构的Web端，一组JavaScript接口，由W3C维护，开发人员可以使用这些API在浏览器中创建实时通信应用程序。

另一部分为适用于移动端及桌面开发的libwebrtc：架构的移动端，即可使用WebRTC C++源码在Windows、Android、iOS等平台编译后的开发包，开发人员可以使用这个开发包打造原生的WebRTC应用程序。

WebRTC C++API，它是顶层Web API和libwebrtc的底层实现。该层包含了连接管理、连接设置、会话状态和数据传输的API。基于这些API，浏览器厂商可以方便地加入对WebRTC的支持。

WebRTC规范里没有包含信令协议，这部分需要研发人员依据业务特点自行实现。

WebRTC支持的音频编码格式有OPUS和G.711，同时还在音频处理模块实现了回音消除及降噪功能。WebRTC支持的视频编码格式主要有VP8和H264(还有部分浏览器支持VP9及H265格式)，同时还在视频处理模块实现了Jitter Buffer(抖动缓冲区)防抖动及图像增强等高级功能。

WebRTC在媒体传输模块，图1中列出所有传输协议，在UDP之上增加了3个协议：

数据包传输层安全性协议(DTLS)：用于加密媒体数据和应用程序数据；

安全实时传输协议(SRTP)：用于传输音频和视频流；

流控制传输协议(SCTP)：用于传输应用程序数据。

WebRTC的媒体传输中借助ICE技术在端与端之间建立P2P连接，它提供了一系列API，用于管理连接。WebRTC还提供了摄像头、话筒、桌面等媒体采集API，使用这些API可以定制媒体流。

WebRTC规范主要介绍了使用ICE技术建立P2P的网络连接，即Mesh网络结构，如图2所示。

Mesh是WebRTC多方会话最简单的网络结构。在这种结构中，每个参与者都向其他所有参与者发送媒体流，同时接收其他所有参与者发送的媒体流。

在Mesh网络结构中，每个参与者都以P2P的方式相互连接，数据交换基本不经过中央服务器(部分无法使用P2P的场景，会经过TURN服务器)。由于每个参与者都要为其他参与者提供独立的媒体流，因此需要N-1个上行链路和N-1个下行链路。众多上行和下行链路限制了参与人数，参与人过多会导致明显卡顿，通常只能支持小型会议(参会者小于4人)的实时互动场景。

WebRTC技术的实际应用中，衍生出了SFU网关服务器的用法。如图3所示，在SFU(Selective Forwarding Unit)网络结构中，SFU网关负责媒体流转发，每个参与者需要1个上行链路和N-1个下行链路，带宽消耗低于Mesh。

SFU服务器作为一个WebRTC参与方，它与其他所有参与方进行1对1的建立连接，并在其中起到桥梁的作用，同时转发各个参与者的媒体数据。SFU服务器具备复制媒体数据的能力，能够将一个参与者的数据转发给多个参与者。

基于WebRTC SFU架构，本发明定义了适用于低延迟直播应用场景下的非对称式SFU媒体网关架构,拓扑结构如图4所示:

1、非对称SFU定义:

在直播流注入(上行)侧,采用传统的RTP组播注入方式,因为直播信号从编码器到SFU网关这段网络通路适合使用保证质量优先的传输协议，无需根据网络条件进行反馈处理，在理想网络环境下可以直接使用RTP协议注入，在广域网或高延迟网络下可以使用SRT协议注入。这也是市面上主流直播制作系统的成熟工作方式，沿用该方法可以降低客户接入系统的成本，避免侵入客户现有直播制作工作流程。

SFU网关在直播流分发侧，使用标准WebRTC协议栈，利用WebRTC自适应低延迟播放的特性，实现支持多终端(手机、机顶盒、浏览器)的低延迟直播分发。WebRTC标准网络协议栈如图5所示，其中媒体传输层，UDP/TCP是最底层标准协议，DTLS为UDP加密传输协议，TLS为TCP加密传输协议，DTLS/TLS层为音视频RTP的传输层协议，RTP通过DTLS/TLS传输时均为加密传输，因此称其为SRTP；UDP->DTLS->SCTP协议栈在传输非音视频数据时使用，即WebRTC DataChannel,在本发明中未涉及到。

在终端和SFU网关服务器建联环节，因为WebRTC是为了广域网环境下P2P音视频通话设计的，包含了SDP(Session Description Protocol，描述会话的协议)交换和可用地址协商等流程，时序图如图6:

为了降低直播起播延迟，在SFU网关服务器侧在标准协议框架内，在收到客户端SDP中包含的地址信息并建联成功后，就立即开始媒体RTP包(视频数据)发送，而不等待ICE所有候选地址(ICE Candidate)探测完成。

同时SFU网关服务器增加了GOP cache(GOP缓存),始终缓存最近一个GOP的媒体数据，在有新的客户端请求开始播放时，将GOP cache发送给客户端。

2、GOP Fast Flush

在该环节本发明首创了一种GOP fast flush机制，其原理是如果不控制码率发送GOP cache，UDP瞬时发送带宽过大，会引起丢包和重传。由于WebRTC客户端有灵敏的反馈机制，此时客户端会主动增大接收缓冲区，造成起播后延迟增大。为了支持所有标准WebRTC客户端都能快速起播，在不修改WebRTC客户端实现的前提下，我们发现以2倍码率速度发送GOP cache是一个平衡点，在避免UDP流瞬时burst流量过大引起丢包进而触发客户端增大Jitter Buffer(抖动缓冲区)的同时,实现直播首帧快速显示，并利用WebRTC追帧的特性，显示首帧后快速追上最新的视频帧，实现平滑的起播体验。

3、WebRTC客户端优化：

本发明在机顶盒客户端主要的开创性工作是在WebRTC C++核心层针对低延迟直播场景进行优化，主要包括:

3.1减小Jitter Buffer动态伸缩的上限，在高码率条件下，避免帧间传输耗时的波动频繁触发Jitter Buffer的增大。

3.2使用低延迟渲染组件，降低大屏幕画面上屏延迟。

4、非对称式SFU媒体网关架构设计时，对输入编码、中间传输和输出解码各个环节中影响低延迟的关键点进行控制改进，进一步保证全链路低延迟优化。

4.1、对编码环节关键点：严格控制I帧大小。源信号编码输出的H264码率中的I帧大小，决定了帧间延迟波动的最大振幅。因为I帧相对P帧大很多，I帧过大会引起输出码流的气泡效应，大帧较长的传输时间会引起客户端播放缓冲消耗而没有新的帧补充，进而触发播放器增大播放缓冲引起延迟增加。因此在编码端调整x264/nvenc编码器的参数，严格控制其输出I帧的大小。

通过ffmpeg编码参数实现控制:

-b:v[bitrate]-maxrate:v[bitrate]-bufsize:v[bitrate]

如8Mbps的流编码参数使用:

-b:v 8000k-maxrate:v 8000k-bufsize:v 8000k在该组参数下，可以实现将I帧大小压在150KByte以内。

4.2、传输环节关键点：在传输I帧时，瞬间的流量陡增会引起网络丢包和重传。在起播环节，SFU服务器对GOP Cache执行fast flush发送，既可以快速显示首帧，同时避免WebRTC客户端主动增加JitterBuffer；在常态发送环节，通过在SFU服务器发送端增加匀速发送模块对网络带宽曲线进行整形，使其尽量平滑，可以明显改善网络吞吐能力有限的终端(如机顶盒)上的丢包现象的发生。

4.3、解码播放环节关键点：在主流手机设备和PC浏览器上，由于设备性能充足，可以稳定实现1080p50 8Mbps码流的150毫秒以内的延迟；在机顶盒上，由于网口带宽和设备解码渲染性能一般，使用标准版开源WebRTC库，延迟经常会突破300毫秒甚至达到500毫秒，通过修改WebRTC库以采用更激进的缓冲区管理策略，通过使用硬件加速的安卓渲染组件降低渲染延迟，多种手段结合实现在线网机顶盒(海思Hi3798)上直播延迟稳定在300毫秒以内。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (6)

1.一种低延迟直播应用场景下的非对称式SFU媒体网关架构，其特征在于，直播流注入直播信号进入编码器，经过音视频处理后送入SFU网关进行分发，编码器到SFU网关这段网络通路使用保证质量优先的传输协议，无需根据网络条件进行反馈处理；SFU网关在直播流分发侧，使用标准WebRTC协议栈，利用WebRTC自适应低延迟播放的特性，多终端分别和SFU网关服务器建联，实现支持多终端的低延迟直播分发。

2.根据权利要求1所述低延迟直播应用场景下的非对称式SFU媒体网关架构，其特征在于，所述终端和SFU网关服务器建联中，SFU网关服务器侧在标准协议框架内，在收到客户端SDP中包含的地址信息并建联成功后，就立即开始媒体RTP包发送，而不等待ICE所有候选地址探测完成，同时SFU网关服务器增加了GOP cache,始终缓存最近一个GOP的媒体数据，在有新的客户端请求开始播放时，将GOP cache发送给客户端。

3.根据权利要求2所述低延迟直播应用场景下的非对称式SFU媒体网关架构，其特征在于，所述GOP cache采用GOP fast flush机制，在不修改WebRTC客户端实现的前提下，起播时以2倍码率速度发送GOP cache是一个平衡点，在避免UDP流瞬时burst流量过大引起丢包进而触发客户端增大Jitter Buffer的同时,实现直播首帧快速显示，并利用WebRTC追帧的特性，显示首帧后快速追上最新的视频帧，实现平滑的起播体验。

4.根据权利要求1所述低延迟直播应用场景下的非对称式SFU媒体网关架构，其特征在于，所述终端为机顶盒，客户端在WebRTC C++核心层针对低延迟直播场景进行优化，包括:减小Jitter Buffer动态伸缩的上限，在高码率条件下，避免帧间传输耗时的波动频繁触发Jitter Buffer的增大；使用低延迟渲染组件，降低大屏幕画面上屏延迟。

5.根据权利要求4所述低延迟直播应用场景下的非对称式SFU媒体网关架构，其特征在于，所述机顶盒客户端通过修改WebRTC库以采用激进的缓冲区管理策略，通过使用硬件加速的安卓渲染组件降低渲染延迟，降低网口带宽和设备解码渲染导致的直播延迟。

6.根据权利要求1至5中任意一项所述低延迟直播应用场景下的非对称式SFU媒体网关架构，其特征在于，所述标准WebRTC协议栈，媒体传输层在UDP之上增加了3个协议：

数据包传输层安全性协议DTLS：用于加密媒体数据和应用程序数据；

安全实时传输协议SRTP：用于传输音频和视频流；

流控制传输协议SCTP：用于传输应用程序数据。