導(dǎo)語：現(xiàn)場(chǎng)信號(hào)超低延時(shí)直播的設(shè)計(jì)一文來源于網(wǎng)友上傳，不代表本站觀點(diǎn)，若需要原創(chuàng)文章可咨詢客服老師，歡迎參考。

摘要：本文介紹了模擬信號(hào)、DVB數(shù)字信號(hào)和基于互聯(lián)網(wǎng)協(xié)議3種直播信號(hào)傳輸技術(shù)方案，分析比較了SRT與WebRTC兩種傳輸協(xié)議，歌華有線應(yīng)用WebRTC協(xié)議完成北京冬奧場(chǎng)館超低延時(shí)直播系統(tǒng)研發(fā)，為冬奧賽事直播提供了有力保障，也為后續(xù)廣電網(wǎng)絡(luò)運(yùn)營(yíng)商IP化改造提供了有力技術(shù)支持。

關(guān)鍵詞：冬奧會(huì)；超低延時(shí)；視頻直播

1引言

冬奧場(chǎng)館體育賽事的直播須兼顧實(shí)時(shí)性和流暢性，不僅時(shí)延要低，還要保障賽事直播視頻的流暢性和清晰度。同時(shí)，直播系統(tǒng)要兼顧“節(jié)儉辦奧運(yùn)”的主旨，基于有線電視網(wǎng)絡(luò)的傳輸環(huán)境，滿足用戶使用電腦、手機(jī)、平板等智能終端進(jìn)行觀看的需求。

2技術(shù)方案

不同技術(shù)方案呈現(xiàn)效果與實(shí)現(xiàn)路徑差異較大，基于當(dāng)前有線電視網(wǎng)絡(luò)背景，我們選取了3種技術(shù)手段，分別是使用模擬信號(hào)、DVB數(shù)字信號(hào)和互聯(lián)網(wǎng)協(xié)議傳輸直播視頻數(shù)據(jù)，并搭建對(duì)比環(huán)境，從多種維度考察這3種技術(shù)方案的優(yōu)缺點(diǎn)。

2.1模擬信號(hào)傳輸方案

北京2008年奧運(yùn)會(huì)時(shí)，為應(yīng)對(duì)奧運(yùn)會(huì)場(chǎng)館超低時(shí)延直播需求，采用了模擬信號(hào)傳輸?shù)姆桨?，較好地完成了直播工作，如圖1所示。Compound區(qū)提供本場(chǎng)館的多套HD-SDI基帶信號(hào)，配置SDI光發(fā)機(jī)傳輸至有線電視機(jī)房，使用SDI光收機(jī)完成HD-SDI基帶信號(hào)接收。經(jīng)過SDI轉(zhuǎn)AV轉(zhuǎn)換器將數(shù)字HD-SDI基帶信號(hào)轉(zhuǎn)換為模擬AV信號(hào)，并使用模擬調(diào)制器完成模擬電視射頻信號(hào)調(diào)制。經(jīng)有線同軸分配網(wǎng)傳輸至各接收終端，終端電視機(jī)可以直接收看低延時(shí)模擬信號(hào)。該技術(shù)方案相對(duì)成熟，時(shí)延低，故障率低，維護(hù)簡(jiǎn)單，易于使用，但清晰度低，已經(jīng)無法適應(yīng)當(dāng)下觀眾對(duì)賽事視頻收看清晰度的要求，亦無法滿足多樣化終端帶來的收看需求，且設(shè)備賽后不可回收再利用，不符合節(jié)儉辦冬奧的主旨。

2.2數(shù)字DVB傳輸方案

除模擬信號(hào)傳輸技術(shù)，亦可考慮使用數(shù)字DVB傳輸技術(shù)實(shí)現(xiàn)賽事的本地低延時(shí)信號(hào)傳輸。如要保證350ms以下的端到端時(shí)延，則需要SDI編碼器、傳輸處理設(shè)備、機(jī)頂盒等均具備低延時(shí)特性。數(shù)字DVB低延時(shí)信號(hào)處理如圖2所示。Compound區(qū)可提供本場(chǎng)館的多套HD-SDI基帶信號(hào)，配置SDI光發(fā)機(jī)傳輸至有線電視機(jī)房，使用SDI光收機(jī)完成HD-SDI基帶信號(hào)接收。經(jīng)過SDI低延時(shí)編碼器將數(shù)字HD-SDI基帶信號(hào)轉(zhuǎn)換為IP信號(hào)，并使用IPQAM調(diào)制器完成數(shù)字電視射頻信號(hào)調(diào)制。將數(shù)字射頻信號(hào)與專網(wǎng)數(shù)字電視射頻信號(hào)混合后，經(jīng)同一張有線同軸分配網(wǎng)傳輸至各接收終端。終端電視機(jī)可以通過機(jī)頂盒收看低延時(shí)數(shù)字信號(hào)，同時(shí)還可收看專網(wǎng)數(shù)字電視信號(hào)。從運(yùn)維角度來說，該方案機(jī)房?jī)?nèi)設(shè)備操作較模擬處理設(shè)備復(fù)雜，需要一定專業(yè)知識(shí)，同時(shí)場(chǎng)館內(nèi)終端機(jī)頂盒數(shù)量較大，會(huì)增加維護(hù)量。此外，根據(jù)時(shí)延測(cè)試結(jié)果，使用歌華普通高清機(jī)頂盒觀看，端到端時(shí)延在620~1240ms；使用歌華4K高清機(jī)頂盒觀看，端到端時(shí)延在400~660ms，達(dá)不到小于350ms時(shí)延的目標(biāo)。

2.3基于互聯(lián)網(wǎng)協(xié)議的傳輸方案

隨著視頻領(lǐng)域的不斷創(chuàng)新，大量的直播業(yè)務(wù)涌現(xiàn)，同時(shí)用戶對(duì)體驗(yàn)要求越來越高，推動(dòng)了低時(shí)延、高碼率IP直播技術(shù)的發(fā)展。為了逼近時(shí)延的極限，這些方案不約而同地都選擇了基于UDP協(xié)議的視頻傳輸，如QUIC、SRT和WebRTC。近年來，隨著對(duì)GoogleQUIC協(xié)議研究的深入，不少項(xiàng)目開始用RTMPoverQUIC替代傳統(tǒng)的RTMPoverTCP。QUIC已成為HTTP3的標(biāo)準(zhǔn)協(xié)議，在超低時(shí)延傳輸方面有很多優(yōu)勢(shì)，最重要的就是其復(fù)雜度非常低。但QUIC作為低延時(shí)直播協(xié)議也有2個(gè)缺點(diǎn)：第一，其本質(zhì)上是一個(gè)可靠協(xié)議，無法便捷的主動(dòng)控制協(xié)議延時(shí)；第二，QUIC是傳輸層的通用協(xié)議，無法針對(duì)音視頻提供端到端的優(yōu)化方案。除QUIC，還有2種專門針對(duì)視頻場(chǎng)景優(yōu)化的超低時(shí)延傳輸協(xié)議，即SRT和WebRTC，二者是基于UDP協(xié)議實(shí)現(xiàn)的超低時(shí)延視頻傳輸解決方案。下面將對(duì)這兩種方案進(jìn)行比較，并介紹歌華有線在冬奧項(xiàng)目中的應(yīng)用情況。

3SRT與WebRTC分析比較

3.1優(yōu)點(diǎn)比較

在安全方面，SRT支持AES加密，保障端到端的視頻傳輸安全；在可靠性方面，SRT通過前向糾正技術(shù)（FEC）保證傳輸?shù)姆€(wěn)定性；在低時(shí)延方面，SRT底層使用UDT協(xié)議，UDT協(xié)議是一個(gè)基于UDP的可靠傳輸協(xié)議，但原生的UDT傳輸延遲較高，SRT在此基礎(chǔ)上優(yōu)化了相關(guān)擁塞控制策略，以降低傳輸時(shí)延。當(dāng)前，SRT在跨國傳輸場(chǎng)景下有不少的應(yīng)用，取代了一些過去需要使用衛(wèi)星作為傳輸媒介的場(chǎng)景。WebRTC主要用于Web端實(shí)時(shí)音視頻通信的互聯(lián)網(wǎng)協(xié)議，應(yīng)用層有JS的接口，使得Web網(wǎng)頁具備音視頻的采集和播放能力。此外，WebRTC的傳輸協(xié)議還支持P2P傳輸，提供了DataChannel，用于應(yīng)用層傳輸其他的數(shù)據(jù)，便于對(duì)直播增加交互等擴(kuò)展功能。

3.2抗抖動(dòng)性比較

視頻超低時(shí)延傳輸?shù)暮诵奶魬?zhàn)是保證播放流暢度，除了提升傳輸通道可靠性，還需要傳輸協(xié)議具備良好的抗抖動(dòng)性，在保持低延遲的同時(shí)穩(wěn)定播放。SRT的解決方法是設(shè)置一個(gè)固定的Latency，并在每個(gè)包頭寫入發(fā)送時(shí)間，在讀取時(shí)，按照發(fā)送時(shí)間延遲Latency讀取，復(fù)制編碼器的輸出。WebRTC則使用JitterBuffer來對(duì)抗網(wǎng)絡(luò)抖動(dòng)，其實(shí)現(xiàn)原理與SRT的方法類似，但有2個(gè)不同點(diǎn):一是根據(jù)當(dāng)前網(wǎng)絡(luò)抖動(dòng)的程度來調(diào)整延遲，網(wǎng)絡(luò)越穩(wěn)定，延遲越?。欢菑腏itterBuffer出來的幀，盡量保證以均勻的速率輸出，但不一定與發(fā)送方編碼器輸出一致。SRT的Tsbpd機(jī)制可以精準(zhǔn)地控制Latency，結(jié)合重傳機(jī)制，相對(duì)于其他協(xié)議有更低的延遲，缺點(diǎn)是不能動(dòng)態(tài)調(diào)整。WebRTC將傳輸抖動(dòng)和編碼渲染結(jié)合相互反饋調(diào)整，過程相對(duì)復(fù)雜。綜上所述，二者在核心抗網(wǎng)絡(luò)抖動(dòng)和傳輸上性能基本接近，但WebRTC優(yōu)點(diǎn)是其在各個(gè)平臺(tái)上都有相應(yīng)的成熟SDK，可以極大地減少整個(gè)系統(tǒng)的開發(fā)、升級(jí)和維護(hù)，同時(shí)解決不同終端播放的兼容性問題。因此，最終選擇WebRTC協(xié)議完成冬奧賽事的超低延時(shí)直播系統(tǒng)研發(fā)。

4WebRTC協(xié)議的應(yīng)用

根據(jù)服務(wù)規(guī)劃及北京冬奧組委的相關(guān)要求，計(jì)劃在競(jìng)賽場(chǎng)館和鳥巢為固定座席提供毫秒級(jí)超低時(shí)延直播服務(wù)，并在部分場(chǎng)館提供基于5G網(wǎng)絡(luò)的無線接入超低時(shí)延無線CATV服務(wù)，觀眾將不再因?yàn)槎虝弘x席或座位角度欠佳錯(cuò)過關(guān)鍵比賽內(nèi)容，為觀眾帶來更好的觀賽體驗(yàn)。4.1主要流程在本項(xiàng)目中，基于WebRTC典型的工作流程如圖3所示?？蛻舳薃：WebRTC的客戶端，此處特指機(jī)頂盒設(shè)備或?yàn)g覽器終端。RTCSTUN：WebRTC的STUN服務(wù)，用于客戶端與服務(wù)端之間建立雙向通信通道。RTC信令系統(tǒng)：WebRTC的信令服務(wù)，用于交換客戶端與RTC媒體系統(tǒng)之間的控制信令。RTC媒體系統(tǒng)：用于實(shí)現(xiàn)面向客戶端的高并發(fā)流媒體服務(wù)。（1）客戶端A首先創(chuàng)建PeerConnection對(duì)象，打開本地音視頻設(shè)備，將音視頻數(shù)據(jù)封裝成MediaStream，添加到PeerConnection中。（2）客戶端A調(diào)用PeerConnection的CreateOffer方法創(chuàng)建一個(gè)用于Offer的SDP對(duì)象，并保存當(dāng)前音視頻的相關(guān)參數(shù)。通過PeerConnection的SetLocalDescription方法保存該SDP對(duì)象，并通過Signal服務(wù)器發(fā)送給媒體系統(tǒng)。（3）RTC媒體系統(tǒng)接收到客戶端A發(fā)送過的OfferSDP對(duì)象，通過PeerConnection的SetRemoteDescription方法將其保存起來，并調(diào)用PeerConnection的CreateAnswer方法創(chuàng)建一個(gè)應(yīng)答的SDP對(duì)象，通過PeerConnection的SetLocalDescription的方法保存該應(yīng)答SDP對(duì)象并將它通過Signal服務(wù)器發(fā)送給客戶端A。（4）客戶端A接收到RTC媒體系統(tǒng)發(fā)送過來的應(yīng)答SDP對(duì)象，將其通過PeerConnection的SetRemoteDescription方法保存起來。（5）在SDP信息的Offer/Answer流程中，客戶端A和RTC媒體系統(tǒng)已經(jīng)根據(jù)SDP信息創(chuàng)建好相應(yīng)的音頻Channel和視頻Channel并開啟Candidate數(shù)據(jù)的收集，Candidate數(shù)據(jù)可以簡(jiǎn)單地理解成Client端的IP地址信息（本地IP地址、公網(wǎng)IP地址、Relay服務(wù)端分配的地址）。（6）當(dāng)客戶端A收集到Candidate信息后，PeerConnection會(huì)通過OnIceCandidate接口給客戶端A發(fā)送通知，客戶端A將收到的Candidate信息通過Signal服務(wù)器發(fā)送給RTC媒體系統(tǒng)，RTC媒體系統(tǒng)通過PeerConnection的AddIceCandidate方法保存起來。同樣的操作RTC媒體系統(tǒng)對(duì)客戶端A再來一次。（7）這樣，客戶端A和RTC媒體系統(tǒng)就建立了音視頻傳輸?shù)狞c(diǎn)對(duì)點(diǎn)通道，客戶端A接收到RTC媒體系統(tǒng)傳送過來的音視頻流，會(huì)通過PeerConnection的OnAddStream回調(diào)接口返回一個(gè)標(biāo)識(shí)RTC媒體系統(tǒng)音視頻流的MediaStream對(duì)象，在客戶端A渲染出來即可。4.2實(shí)現(xiàn)效果最終，經(jīng)過全流程調(diào)優(yōu)，在使用指定1080i50信源的情況下，編碼時(shí)延80ms，分發(fā)時(shí)延40~60ms，IP傳輸5~10ms，終端緩存解碼時(shí)延100~120ms，電視機(jī)時(shí)延35~70ms，除去差異較大的顯示終端，端到端時(shí)延控制在300ms以內(nèi)，實(shí)現(xiàn)了對(duì)異構(gòu)終端、異構(gòu)網(wǎng)絡(luò)的覆蓋，達(dá)成了項(xiàng)目預(yù)期目標(biāo)。當(dāng)然，WebRTC方案也存在一些缺點(diǎn)，比如不支持音頻AAC編碼和44.1KHz采樣率；不支持視頻B幀、H265等編碼特性，對(duì)多slice編碼支持性較差；在QoS策略方面，WebRTC的原生應(yīng)用場(chǎng)景是通話，基本策略是延遲優(yōu)于畫質(zhì)，這個(gè)策略在直播中不一定成立。因此，在后期存在一定的定制化優(yōu)化改造空間，即在保留WebRTC核心傳輸相關(guān)模塊（RTP/RTCP、FEC、NACK、Jitterbuffer、音視頻同步、擁塞控制等）的基礎(chǔ)上，利用定制化播放器封裝以上WebRTC的核心功能，解決以上存在的缺陷，在可控終端或者自有APP中實(shí)現(xiàn)更好的播出效果。

5結(jié)語

歌華有線通過對(duì)超低時(shí)延直播相關(guān)領(lǐng)域的研究，比較了現(xiàn)有各種直播標(biāo)準(zhǔn)、協(xié)議的優(yōu)劣，再有針對(duì)性地對(duì)最終選型結(jié)果的信源編碼、傳輸、終端解碼全流程進(jìn)行測(cè)試和調(diào)優(yōu)，確保端到端時(shí)延在350ms以內(nèi)，實(shí)現(xiàn)了異構(gòu)終端和異構(gòu)網(wǎng)絡(luò)下的業(yè)務(wù)分發(fā)，完成了項(xiàng)目設(shè)計(jì)要求，為后續(xù)廣電網(wǎng)絡(luò)運(yùn)營(yíng)商的IP化改造提供了知識(shí)和技術(shù)支持。

參考文獻(xiàn)

[1]屈振華,李慧云,張海濤,等.WebRTC技術(shù)初探[J].電信科學(xué),2012,28(10):106-110.

[2]何明亮.WebRTC技術(shù)的研究與應(yīng)用[D].南京:南京郵電大學(xué),2014.

作者：楊敬一 張辰 單位：北京歌華有線電視網(wǎng)絡(luò)股份有限公司