隨着直播行業的快速發展，直播帶貨秒殺和在線教育答題等應用場景對直播延時的要求越來越嚴苛。今天的技術解碼就由費偉老師為大家帶來騰訊雲在快直播方面的一些分享！
隨着直播行業的快速發展，特別是在今年疫情的影響下，各種低延時的直播場景得到了爆發性發展。最典型的應用就是直播帶貨秒殺和在線教育答題。這些應用場景的核心需求就是實時音視頻互動，而傳統直播技術基於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/
from：https://cloud.tencent.com/developer/article/1760040?from=information.detail.html5%E4%B8%ADh265