随着直播行业的快速发展，直播带货秒杀和在线教育答题等应用场景对直播延时的要求越来越严苛。今天的技术解码就由费伟老师为大家带来腾讯云在快直播方面的一些分享！
随着直播行业的快速发展，特别是在今年疫情的影响下，各种低延时的直播场景得到了爆发性发展。最典型的应用就是直播带货秒杀和在线教育答题。这些应用场景的核心需求就是实时音视频互动，而传统直播技术基于HLS、FLV/RTMP协议具有秒级别的延时，高延时是制约互动效果的关键因素。快直播就是针对传统直播协议高延时的痛点，基于WebRTC技术实现毫秒级延时的直播产品方案。该产品能够满足一些对延迟性能要求更高的特定场景需求，除了电商直播带货和在线教育外，还有体育直播、游戏直播等各种能融合实时互动的直播场景。
表一 各种直播延时比较
直播经过多年发展，整个直播链路基本上已经实现了标准化。主播使用PC或手机通过客户端实现音视频采集编码，并以RTMP推流的形式传输到直播云平台，音视频数据再经过转码等媒体处理，最后通过CDN网络以FLV、HLS等协议传输到观众的终端设备上。整个链路上最大延时是RTMP推流、CDN传输延迟和终端缓存及解码播放耗时。传统的RTMP/FLV/HLS都是基于TCP协议，在弱网下容易传输积压，且一般终端播放器为了对抗TCP的网络波动需要缓存1~2个GOP保证播放不卡顿。
图一 标准直播链路
众所周知，WebRTC通过RTP/RTCP协议和优秀的拥塞控制算法在实时音视频领域实现了出色的低延时和抗弱网性能。快直播正是采用WebRTC协议对标准直播的拉流侧进行低延时改造，以达到高兼容、低成本、大容量的低延时直播要求。系统沿用原有直播架构中的云上数据处理能力，对直播接入和CDN边缘进行WebRTC改造，使直播接入能接收WebRTC推流，CDN边缘在原有分发FLV/HLS能力的基础上具有WebRTC协商和转封装分发的能力。这样快直播在低延时基础上，既兼容了标准直播中包括推流、转码、录制、截图、鉴黄等全套云上媒体处理功能，又具有传统CDN强大的边缘分发能力，可支撑起百万级同时在线人数。总之，客户可以从现有的标准直播平滑地迁移到快直播上来，快速实现低延时直播场景应用。
终端的生态环境也是快直播采用WebRTC进行低延时改造的重要考量。流行的Chrome、Safari等大部分浏览都已经支持WebRTC标准，还有成熟的开源WebRTC SDK能让我们方便地进行优化和定制。这样我们既能通过浏览器提供标准的WebRTC直播能力，也能通过定制SDK提供升级的更完善的低延时直播能力。
图二 基于标准直播的WebRTC低延时改造
标准WebRTC支持的音视频编码格式已经无法满足国内直播行业需求。标准WebRTC支持的视频编码格式是VP8/VP9和H.264，音频编码格式是Opus，而国内推流的音视频格式基本上是H.264/H.265 AAC的形式。另外，标准WebRTC为了追求极致的低延时通信，没有支持B帧编码，而B帧编码能更好的提高压缩率和节省带宽成本，已经被国内直播行业广泛采用。所以标准WebRTC在对接现有的直播系统时，往往会需要转码，引入额外延时和成本。为了更好的兼容国内直播推流的音视频格式，有必要对标准WebRTC进行升级，支持AAC音频、H.265视频和B帧编码。下面详细介绍快直播对标准WebRTC所做的升级扩展工作。
3.1 AAC-LC/AAC-HE/AAC-HEv2
WebRTC是基于SDP进行能力协商的，为了更好的支持新功能新特性，同时兼容标准WebRTC，快直播对WebRTC扩展的SDP定义和协商进行了规范。
为了支持AAC语音编码格式，终端SDK需要在offer sdp中添加AAC编码信息并实现AAC解码器，后台则需要实现AAC协商逻辑和RTP打包下发，具体可参考RFC6416和ISO/IEC 14496-3。
3.1.1 offer sdp
通过在offer sdp声明 AAC相关信息表示支持AAC拉流，分两种形式，MP4-LATM和MP4A-ADTS。下面的offer sdp的示例给出了两种payload type对应的AAC格式，MP4A-LATM/48K采样率/双声道和MP4A-LATM/44.1K采样率/双声道。这里的采样率，我们规定采用显示模式，即扩展后的实际采样率。当rtpmap有AAC声明时，后台优先下发原始流中的AAC。
...
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:120 MP4A-LATM/48000/2
a=rtcp-fb:120 transport-cc
a=rtpmap:121 MP4A-LATM/44100/2
a=rtcp-fb:121 transport-cc
...
3.1.2 anwser sdp
后台协商sdp回复answer sdp有两种方式：
第一种是异步回源方式，即在回源之前就回复answer sdp，这时由于没有解析到真实的音频格式，answer sdp一般只是拷贝offer sdp中的音频格式信息返回给客户端，在实际下发时优先以实际推流的音频编码格式及协商好的payload type下发音频RTP包，此时每帧AAC需要AudioSpecificConfig头信息。此类带帧头的方式被称为带内传输。
第二种是同步回源方式，即在回源解析码流之后再回复answer sdp。这时除了需要解析到实际AAC采样率来匹配rtpmap外，还需要附加fmtp字段表明AAC详细格式信息，下面是AAC-HE/44.1K/双声道的示例：
...
a=rtpmap:121 MP4A-LATM/44100/2
a=rtcp-fb:121 nack
a=rtcp-fb:121 transport-cc
a=fmtp:121 SBR-enabled=1;config=40005724101fe0;cpresent=0;object=2;profile-level-id=1
...
其中：
SBR-enabled=1表示启用SBR（Spectral Band Replication，频段复制），说明当前AAC为AAC-HE，SBR-enabled=0时即为AAC-LC。
config为StreamMuxConfig，能解析出AAC的具体格式信息，详见ISO/IEC 14496-3。
cpresent=0表示带外，AAC头信息只出现在SDP中，RTP流中不带头信息。cpresent=1表示带内，即AAC头信息不出现在SDP中，每帧AAC需要加上AudioSpecificConfig头信息。
由于AAC-HEv2是AAC-HE加上PS技术，即Parametric Stereo（参数立体声），所以可以通过字段SBR-enabled=1加PS-enabled=1的方式来表示AAC-HEv2。
注：如果用户需要ADTS格式的AAC时，可以将MP4A-LATM替换为MP4-ADTS，带内传输时每帧ASC头替换为ADTS头。
3.2 H.265
终端SDK需要在offer sdp中添加H.265相关信息，并实现H.265的RTP拆包、解析、组帧和解码等功能模块，后台则需要实现相应H.265协商逻辑和RTP打包下发功能。协商的逻辑为，当SDK offer sdp同时列出H.264和H.265时，后台则以实际推流视频编码下发，如果播放设备只支持H.264且推流视频格式为H.265，则后台需经过转码成H.264处理。
offer sdp示例：
...
a=rtpmap:98 H264/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtcp-fb:98 transport-cc
a=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:100 H265/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 transport-cc
...
3.3 H.264/H.265 B帧
终端SDK需要在offer sdp中添加B帧相关信息，实现B帧timestamp非单调递增的处理逻辑，后台则需要实现相应B帧timestamp封装逻辑。
3.3.1 SDP B帧协商
通过sdp fmtp bframe-enabled=1字段来表示支持B帧，后台会下发原始流中的视频数据，否则bframe-enabled=0时，后台走去B帧转码逻辑。
offer sdp示例：
...
a=fmtp:98 bframe-enabled=1;level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
...
3.3.2 B帧的timestamp
B帧数据的RTP封装和I帧P帧相同，但B帧的PTS不是单调递增，需要特殊处理，原始流中PTS = DTS CTS。快直播支持两种方式来支持PTS和DTS：
第一种，RTP timestamp直接采用PTS，客户端只需按sequence number顺序解码，按PTS顺序显示即可。
第二种，RTP timestamp采用DTS，CTS通过RTP扩展头的方式传输给客户端，客户端解析后算出PTS。下面是SDP extmap示例：
...
a=extmap:7 rtp-hrdext:video:CompistionTime
...
以上两种方式可以兼容，当offer sdp有相应extmap rtp-hrdext字段时采用第二种方式，否则采用第一方式。
3.4 非加密传输
标准WebRTC原本的设计使用场景是音视频通信，所以加密是必选项。而在直播应用中很多场景是公开的，没有必要采用加密传输，去掉加密既可以省去开播时DTLS握手产生的延时，也可以减少后台和前端加解密的开销。
3.4.1 加密时offer sdp
...
m=audio 9 UDP/TLS/RTP/SAVPF 111 120 121 110
...
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100
...
其中：
UDP/TLS/RTP/SAVPF表示用来传输音视频支持的协议，UDP、TLS、RTP表示使用UDP来传输RTP包，并使用TLS加密，即DTLS加密。SAVPF表示使用SRTCP的反馈机制来控制传输过程。
3.4.2 非加密时offer sdp
...
m=audio 9 RTP/AVPF 111 120 121 110
...
m=video 9 RTP/AVPF 96 97 98 99 100
...
RTP/AVPF表示RTP和RTCP都为非加密模式，SDK端有专门的加密开关接口分别产生加密和非加密SDP信息，后台则支持相应加密和非加密下发数据。
3.5 私有数据透传
3.5.1 SEI透传
很场景需要音视频本身需要同步外，其他媒体数据也需要同步，比如教育场景下的白板内容、直播带货场景下的评论互动等。这个时候带有时间戳的SEI NALU可以很好的完成这个任务，后台保持SEI数据透传，SDK端遇到SEI会有回调输出给应用层使用。
3.5.2 MetaData透传
后台通过RTP扩展头来实现媒体container层的MetaData私有数据透传，这样方便用自定义需要透传的使用场景，同样SDK端在解析到MetaData时会有回调输出给应用层使用。
offer sdp示例：
...
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/meta-data-01
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/meta-data-02
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/meta-data-03
...
rtp头扩展如下：
快直播SDK基于原生WebRTC进行定制扩展，并对除了标准WebRTC外，还支持以下功能：
a) 支持AAC，包括AAC-LC、AAC-HE和AAC-HEv2解码播放
b) 支持H.265解码播放，包括硬解和软解
c) 支持H.264和H.265的B帧解码
d) 支持SEI回调
e) 支持关闭加密
f) 支持画面截图、旋转、缩放
快直播SDK对原生WebRTC进行了性能优化，包括包括首帧延时、追帧、同步、Jitterbuffer和NACK策略等，裁减了与拉流播放不相关模块，整体打包增量在5M左右，包括arm64和arm32两个架构。
为用户提供了完善的SDK及DEMO，方便客户接入。Web DEMO提供了网页端标准WebRTC拉流演示，Android和iOS则提供了拉流播放SDK、DEMO及接入文档。
4.1 Web DEMO
http://webrtc-demo.tcdnlive.com/httpDemo.html
扫码打开Web DEMO
4.2 Android SDK及DEMO
https://github.com/tencentyun/leb-android-sdk
扫码打开Android SDK及DEMO
4.3 iOS SDK及Demo
https://github.com/tencentyun/leb-ios-sdk/
扫码打开iOS SDK及DEMO
快直播通对标准直播的推流接入和CDN边缘节点进行WebRTC改造，使直播迈入了毫秒级的低延时时代。并且在此基础上对标准WebRTC进行了升级扩展，完美对接了国内主流直播推流音视频格式。目前快直播已经在腾讯内部在线教育、企鹅电竞等业务平台已经落地，外部国内直播、教育、电商等头部客户也正在接入。后面快直播将更加契合客户的实际需求，并结合WebRTC推流提升上行质量，为客户提供更稳定且更低延时的直播服务和更实时的互动能力，与客户共创直播新时代。
参考文献
1. 腾讯云快直播——超低延迟直播技术方案及应用,
https://cloud.tencent.com/developer/article/1736846
2. RFC6416 RTP Payload Format for MPEG-4 Audio/Visual Streams,
https://datatracker.ietf.org/doc/rfc6416/
3. RFC3984 RTP Payload Format for H.264 Video,
https://datatracker.ietf.org/doc/rfc3984/
4. RFC7798 Payload Format for High Efficiency Video Coding (HEVC),
https://datatracker.ietf.org/doc/rfc7798/
5. RFC5285 A General Mechanism for RTP Header Extensions,
https://datatracker.ietf.org/doc/rfc5285/
