開源流媒體服務(wù)器：為何一定得再擼個(gè)新的

作為開發(fā)者，我們需要有一個(gè)服務(wù)器來支持新視頻行業(yè)的互聯(lián)網(wǎng)化，有哪個(gè)開源方案能支持新爆發(fā)的業(yè)務(wù)？該方案需要支持哪些關(guān)鍵的能力或需求？本文由自阿里云RTC服務(wù)器團(tuán)隊(duì)負(fù)責(zé)人楊成立在LiveVideoStack線上分享的內(nèi)容整理而成。

文 / 楊成立

整理 / LiveVideoStack

視頻回放：

https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=7955f5f3e1c942fa9ae4314b991beb1c

大家好，我是來自阿里云的楊成立，本次分享將會(huì)和大家詳細(xì)介紹開源流媒體服務(wù)器的關(guān)鍵技術(shù)及未來發(fā)展。

我從2009年開始從事FFmpeg流媒體相關(guān)工作，2012年開始參與流媒體服務(wù)器的開發(fā)，2013年開始做開源流媒體服務(wù)器SRS，至今也有七年多的時(shí)間了。在這短短幾年間，隨著視頻直播的爆發(fā)，SRS也迎來了快速增長(zhǎng)。2017年我來到阿里云之后換成了WebRTC方向。我們可以看到目前Live WebRTC在整個(gè)視頻的應(yīng)用非常廣，包括在線辦公、在線教育、在線娛樂等各個(gè)行業(yè)都大展拳腳，音視頻已經(jīng)成為當(dāng)前互聯(lián)網(wǎng)交流與信息傳播不可或缺的媒介手段。

這次的分享內(nèi)容將主要圍繞SRS的誕生與歷程、SRS接下來的發(fā)展計(jì)劃等，帶領(lǐng)大家深入研究SRS存在的價(jià)值與意義。

得益于我國(guó)通信基礎(chǔ)設(shè)施的日趨完善，尤其是Wi-Fi、4G網(wǎng)絡(luò)的下沉普及，我國(guó)互聯(lián)網(wǎng)市場(chǎng)音視頻產(chǎn)品服務(wù)在2015～2018年經(jīng)歷了爆發(fā)式增長(zhǎng)。當(dāng)時(shí)消費(fèi)者普遍擁有的可以觀看視頻的帶寬大約為1M，網(wǎng)絡(luò)環(huán)境較為穩(wěn)定。

直播背后的技術(shù)早在功能機(jī)時(shí)代就落地成熟。例如2010～2012年，消費(fèi)者主要通過PC上的Flash來觀看網(wǎng)絡(luò)直播視頻，因?yàn)镕lash可以跨主流PC端瀏覽器。而移動(dòng)端盡管也支持Flash，但效果很不好。移動(dòng)端如Android或IOS則主要支持HLS，早期Android對(duì)HLS的支持效果并不佳，后面有明顯改善。

無論是傳統(tǒng)PC時(shí)代還是現(xiàn)在的移動(dòng)互聯(lián)網(wǎng)時(shí)代，流媒體中主要使用的協(xié)議都是RTMP/FLV與Apple的HLS，流媒體播放器主要有Red5、Nginx-RTMP、CRTMP、Wowza、AMS等。大約是從2017年開始，Chrome中的Flash播放器就已經(jīng)處于默認(rèn)禁用的狀態(tài)，后續(xù)Flash也會(huì)逐漸退出互聯(lián)網(wǎng)歷史舞臺(tái)。

隨著互聯(lián)網(wǎng)的發(fā)展，移動(dòng)端直播逐漸興起并且成為主流。例如當(dāng)前移動(dòng)辦公平臺(tái)中的互聯(lián)網(wǎng)直播：主要調(diào)用的是Native播放器，使用FLV協(xié)議。瀏覽器端則多采用HLS，二者共同構(gòu)成了較為成熟完善的互聯(lián)網(wǎng)直播協(xié)議體系。

隨著移動(dòng)基礎(chǔ)網(wǎng)絡(luò)的建設(shè)不斷升級(jí)，移動(dòng)端和IoT/5G時(shí)代來臨，實(shí)時(shí)通信互聯(lián)的需求日趨旺盛，F(xiàn)lash被禁用之后出現(xiàn)了更加完善的替代方案——H5播放器，其所使用的技術(shù)規(guī)范是MSE。H5播放器現(xiàn)可被絕大多數(shù)PC瀏覽器支持，同時(shí)H5也能播放FLV等格式。MSE擴(kuò)展和Flash比較相似，提供的是JS接口，將FLV或HLS等解封裝，然后打包為MP4后，送到MSE接口中播放。H5是替代Flash的標(biāo)準(zhǔn)方案，F(xiàn)LV、HLS、DASH等都可以直接通過MSE播放。

除此之外，大家所追求的另一個(gè)方向是低延遲直播，一般傳輸協(xié)議其延遲可達(dá)十幾秒，而RTMP可以將延遲降低到3～5秒，公網(wǎng)上的TCP有時(shí)會(huì)出現(xiàn)抖動(dòng)，此時(shí)延遲會(huì)變大。

目前大家都在探索更好的降低直播延遲的方法，在此方面WebRTC是大家公認(rèn)的理想解決方案。盡管5G可以帶來更低的延遲，但從通信角度來說可用性更加重要。5G網(wǎng)絡(luò)的盛行意味著整個(gè)網(wǎng)絡(luò)基礎(chǔ)設(shè)施的穩(wěn)定，有更多的通信設(shè)備可以達(dá)到相應(yīng)要求。例如疫情期間使用視頻直播的用戶出現(xiàn)井噴式增長(zhǎng)，而現(xiàn)有網(wǎng)絡(luò)直播服務(wù)依舊未因此而出現(xiàn)重大宕機(jī)，這主要是得益于過去十多年的通信網(wǎng)絡(luò)基礎(chǔ)設(shè)施建設(shè)，以及整個(gè)開源環(huán)境、商業(yè)、云計(jì)算等領(lǐng)域的保障與進(jìn)步相關(guān)。

目前SRT、IoT等的發(fā)展仍需面臨很大挑戰(zhàn)，特別是現(xiàn)在國(guó)內(nèi)互聯(lián)網(wǎng)的可能性不斷豐富，直播產(chǎn)業(yè)生態(tài)環(huán)境也會(huì)趨于向好，新場(chǎng)景層出不窮。

首先，不同場(chǎng)景對(duì)網(wǎng)絡(luò)基礎(chǔ)設(shè)施以及整個(gè)商業(yè)環(huán)境的要求是完全不一樣；其次，業(yè)務(wù)與開源往往是相互促進(jìn)的，業(yè)務(wù)驅(qū)動(dòng)新開源方案的不斷落地實(shí)施，而開源方案也為業(yè)務(wù)提供技術(shù)支持；最后，不同行業(yè)之間往往存在很深的代溝，例如監(jiān)控行業(yè)往往不會(huì)需要APP，而直播行業(yè)也不會(huì)用到私有協(xié)議。我們需要SRT做遠(yuǎn)距離傳輸、GB28181支持物聯(lián)網(wǎng)接入，WebRTC開展互動(dòng)和在線溝通。

我們希望有一套開源的解決方案能滿足不同行業(yè)不同場(chǎng)景下的低延遲直播需求。現(xiàn)在的云計(jì)算有融合的趨勢(shì)，無論是CDN還是云計(jì)算都開始逐漸滿足在線直播的需求。作為開發(fā)者，我們需要有一個(gè)服務(wù)器來支持這些新視頻行業(yè)的互聯(lián)網(wǎng)化，有哪個(gè)開源方案能支持新爆發(fā)的業(yè)務(wù)？該方案需要支持哪些關(guān)鍵的能力或需求？

若想實(shí)現(xiàn)此開源流媒體服務(wù)器，我們需要考慮諸多關(guān)鍵約束和能力。

首先就是該平臺(tái)需要具有一定伸縮性，也就是足夠的彈性。互聯(lián)網(wǎng)業(yè)務(wù)可以從局部擴(kuò)展到很大的領(lǐng)域，如果我們使用開源方案則需要清晰意識(shí)到如果業(yè)務(wù)規(guī)模變大之后，現(xiàn)有資源與經(jīng)驗(yàn)?zāi)芊裰纹鹑绱舜笠?guī)模的服務(wù)運(yùn)行，這需要很多開發(fā)者的維護(hù)與云廠商的支持。如果沒有開源平臺(tái)和云廠商的支持，那么我們只能自主搭建平臺(tái)并部署服務(wù)器。對(duì)于很多企業(yè)來說，他們不可能有能力和資源開展這么多業(yè)務(wù)，所以開源方案至關(guān)重要。

開源的前提是必須要有云計(jì)算的支持，現(xiàn)在能看到的CDN，包括阿里云和騰訊云等其實(shí)都支持RTMP、FLV、HLS，并且現(xiàn)在也開始支持WebRTC，在此基礎(chǔ)上擴(kuò)充生成了諸多商業(yè)落地應(yīng)用，具備大規(guī)模應(yīng)用的能力。我們自己基于開源方案搭建平臺(tái)并將其對(duì)接到CDN上，即可妥善解決彈性問題。如果沒有云服務(wù)的加持，開源平臺(tái)的價(jià)值也無從談起。

低延遲是我們需要注意的第二點(diǎn)。現(xiàn)在視頻發(fā)展的一大趨勢(shì)是低延遲，例如TCP類的協(xié)議其延遲可達(dá)3~5秒，這不僅僅是TCP協(xié)議本身所致。而像HLS切片、播放器延遲、編碼延遲等都可能會(huì)提高延遲至8～10秒甚至更多。WebRTC通訊場(chǎng)景延遲一般小于一秒甚至可達(dá)400毫秒。常見的語音溝通場(chǎng)景延遲高于400毫秒就需要人工對(duì)兩個(gè)人的講話進(jìn)行同步。

第三點(diǎn)是搭建的服務(wù)平臺(tái)需要具備較為出色的易用性。如Red5、NGINX-RTMP、CRTMP、Wowza、AMS、Helix等。還有一項(xiàng)關(guān)鍵是協(xié)議之間的互通，一個(gè)業(yè)務(wù)可能需要基于多個(gè)協(xié)議，打通其中的隔閡至關(guān)重要。若想快速部署該方案，以上三點(diǎn)至關(guān)重要。

1. Scenario

1.1 互聯(lián)網(wǎng)直播與連麥

互聯(lián)網(wǎng)直播和連麥的應(yīng)用場(chǎng)景想必大家并不陌生，其中一些技術(shù)細(xì)節(jié)值得我們重點(diǎn)關(guān)注。例如在編解碼方面，H.264相對(duì)比較完善，而PC等設(shè)備上則有硬件編解碼。商用編解碼方面，比如國(guó)內(nèi)的虹軟、國(guó)外的HaiVision等，包括一些廣電行業(yè)也有其自己的編解碼器。除了編解碼，再往上如推流OBS、FFmpeg等則主要被集成在系統(tǒng)當(dāng)中。如果從主播端直接推流，那么基于OBS修改的方案比較多。

傳輸方面，我們需要把內(nèi)容分發(fā)給許多觀眾，這一塊的開源方案有NGINX-RTMP與SRS等，商業(yè)解決方案有Wowza和AMS等，商業(yè)解決方案更多是直接通過CDN網(wǎng)絡(luò)直接進(jìn)行分發(fā)。

播放器中的方案則主要是H5播放器，設(shè)備中大多會(huì)集成播放器來實(shí)現(xiàn)編解碼，當(dāng)然現(xiàn)在還有開源SDK來實(shí)現(xiàn)這一需求。直播連麥主要通過RTC與WebRTC的交叉功能來實(shí)現(xiàn)。

1.2 互聯(lián)網(wǎng)實(shí)時(shí)通信

互聯(lián)網(wǎng)實(shí)時(shí)通信的典型應(yīng)用范例是視頻會(huì)議，視頻編解碼方面與上一場(chǎng)景類似。但音頻編解碼方面，互聯(lián)網(wǎng)直播多采用AAC而互聯(lián)網(wǎng)實(shí)時(shí)通信則使用Opus，因?yàn)镺pus的延遲更低。客戶端包括推流與播放主要是WebRTC框架，推流與播放需要服務(wù)器，才能把流分發(fā)給很多人。此時(shí)大家會(huì)發(fā)現(xiàn)這里的服務(wù)器和前文提到的直播服務(wù)器完全不同，其支持Janus、Mediasoup、OWT與SRS等。在線會(huì)議場(chǎng)景中有一個(gè)特殊的應(yīng)用就是等格式，我們希望實(shí)現(xiàn)電話之間的互聯(lián)互通，這一塊的開源方案是FreeSWITCH，其本身就是一個(gè)龐大的系統(tǒng)。

1.3 互聯(lián)網(wǎng)媒體中心

互聯(lián)網(wǎng)媒體中心作為一大應(yīng)用場(chǎng)景，主要用于對(duì)內(nèi)容的管控。例如當(dāng)需要錄制視頻時(shí)，我們希望該視頻可以被反復(fù)觀看，如錄制好的培訓(xùn)課程。還有一些內(nèi)容并不會(huì)被頻繁重復(fù)觀看，如國(guó)慶直播、足球賽直播等，這里就需要設(shè)計(jì)對(duì)于已錄制內(nèi)容的妥善管控，如不良內(nèi)容鑒定、自動(dòng)剪輯等。媒體中心的設(shè)計(jì)和內(nèi)容強(qiáng)相關(guān)，其需要包括轉(zhuǎn)碼、編碼、存儲(chǔ)等全流程的加持。傳統(tǒng)方案是將媒體流傳輸給多個(gè)CDN或者借助CDN將流分發(fā)給多個(gè)CDN。此方案本身非常浪費(fèi)資源，更好的方案是建立一個(gè)媒體中心。

安全方面，CDN也有播放的鑒權(quán)，例如限制一定的參與人數(shù)，對(duì)內(nèi)容進(jìn)行加密等，Token也是一種鑒權(quán)方式。除此之外，我們還需要一種接入標(biāo)準(zhǔn)如GB28181《安全防范視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)信息傳輸、交換、控制技術(shù)要求》，盡管其屬于一種標(biāo)準(zhǔn)，但非常私有，CDN不太好去支持該標(biāo)準(zhǔn)。云計(jì)算CDN更適合去做標(biāo)準(zhǔn)的事情，基礎(chǔ)設(shè)施、分發(fā)等都需要標(biāo)準(zhǔn)來規(guī)范。如果接入?yún)f(xié)議非常私有，那么自建一套媒體中心更符合企業(yè)需求。將內(nèi)容轉(zhuǎn)換成標(biāo)準(zhǔn)協(xié)議發(fā)送至CDN或者其他企業(yè)，相對(duì)而言更加容易實(shí)現(xiàn)互聯(lián)網(wǎng)化。

在特殊場(chǎng)景下，如為跨國(guó)直播設(shè)計(jì)的遠(yuǎn)距離傳輸當(dāng)中，數(shù)據(jù)大多是通過專項(xiàng)網(wǎng)絡(luò)進(jìn)行傳輸，也可以走互聯(lián)網(wǎng)或SRT。這些特殊的場(chǎng)景與業(yè)務(wù)強(qiáng)相關(guān)，并不太適合用統(tǒng)一的標(biāo)準(zhǔn)來框定，其規(guī)模不足夠大也不能夠成為標(biāo)準(zhǔn)。

2. Scalability——基于Cloud或?qū)覥DN

上圖展現(xiàn)了基于云部署或?qū)覥DN的部署圖，SRS的Demo網(wǎng)絡(luò)就是這么部署的。其主要用K8s來部署，也可以用二進(jìn)制來部署，包括邊緣集群、媒體中心、源站等。流的輸入端會(huì)退回非標(biāo)準(zhǔn)協(xié)議下的傳輸流，并將標(biāo)準(zhǔn)的RTMP流推送到源站。隨后沿邊緣CDN，經(jīng)過RTMP、FLV等標(biāo)準(zhǔn)協(xié)議進(jìn)行分發(fā)，如果規(guī)模不夠大則直接從云機(jī)房當(dāng)中播放分發(fā)，即便是切片協(xié)議也可以通過NGINX分發(fā)。因?yàn)閿?shù)據(jù)可以對(duì)堆積到CDN，所以該系統(tǒng)具備伸縮能力。協(xié)議主要通過RTMP，也可以通過CDN，CDN現(xiàn)在也支持WebRTC，也可以通過RTC來對(duì)接，但RTC中有很多私有的東西，未來RTC可以走CDN，但還需要一定時(shí)間才能實(shí)現(xiàn)。

3. Latency

3.1 實(shí)時(shí)流媒體直播

關(guān)于延遲，SRS現(xiàn)在支持了WebRTC的播放，推流很快會(huì)被支持。上圖視頻畫面顯示的是一個(gè)時(shí)鐘，OBS抓取時(shí)鐘運(yùn)行的畫面。OBS本身有100毫秒左右的延遲，通過RTMP和WebRTC播放器播放該時(shí)鐘運(yùn)行畫面，可以看到時(shí)鐘指示數(shù)字出現(xiàn)明顯不同，這也體現(xiàn)了二者的延遲差異。

3.2 實(shí)時(shí)流媒體系統(tǒng)

對(duì)GB28181進(jìn)行測(cè)試，從上圖實(shí)驗(yàn)結(jié)果我們可以發(fā)現(xiàn)，HIKVISION監(jiān)控內(nèi)網(wǎng)攝像頭延遲為280毫秒、阿里云服務(wù)器WebRTC延遲約為210毫秒、阿里云服務(wù)器RTMP延遲1100毫秒。我們可以看到WebRTC服務(wù)器比內(nèi)網(wǎng)監(jiān)控?cái)z像頭的延遲還要低，出現(xiàn)這種情況主要是因?yàn)檠舆t并不單純是網(wǎng)絡(luò)問題。該場(chǎng)景下WebRTC延遲比監(jiān)控還要低，且具備場(chǎng)景下載的能力。監(jiān)控大多會(huì)走私有傳輸路線，傳統(tǒng)方案若想正常播放則需要安裝IE插件。而通過標(biāo)準(zhǔn)協(xié)議大家想要從手機(jī)端看到，手機(jī)只需要直接集成SDK，同時(shí)瀏覽器也可以直接看到畫面，這樣不需要安裝任何插件，各個(gè)攝像頭的流都可以看得到。

4. 舉例

4.1 Cloud Native

第三部分是部署，SRS支持K8S和Docker部署，包括我們每個(gè)新發(fā)布版本都會(huì)支持Docker。上圖主要展現(xiàn)了如何部署K8S，這里我就不再贅述，大家可以仔細(xì)觀看相應(yīng)文檔。

以前我們主要通過二進(jìn)制安裝包來部署，其實(shí)SRS有多個(gè)鏡像倉庫，可以加速代碼下載。倉庫小下載速度也很快，編譯、安裝、啟動(dòng)等相對(duì)容易，其實(shí)Docker的部署方式更容易。最近陸陸續(xù)續(xù)有一些朋友反饋說編譯存在一些問題，但Docker實(shí)際上可以在任何平臺(tái)上部署，例如windows就完全可以部署Docker并運(yùn)行，ARM平臺(tái)上則可以交叉編譯。有時(shí)需要我們解決的問題會(huì)比較多，但如果使用ARM的Docker編譯就沒有問題。因?yàn)镈ocker的環(huán)境是不變的，Docker是將環(huán)境、編譯等問題統(tǒng)一解決，包括k8s等都可以在發(fā)布的時(shí)候?qū)崿F(xiàn)不中斷服務(wù)升級(jí)，業(yè)務(wù)低峰期時(shí)就可以發(fā)布新版本。

4.2 錯(cuò)誤&日志

上圖展示了SRS的日志，其中存在進(jìn)程號(hào)與ID。一個(gè)ID代表服務(wù)器上的一個(gè)連接，一個(gè)服務(wù)器為成百上千個(gè)用戶與進(jìn)程提供服務(wù)，ID用于定位問題出現(xiàn)的位置與所屬上下文日志。流媒體與HTTP不同，作為傳輸流存在上下文。長(zhǎng)時(shí)間的數(shù)據(jù)交換使得其日志不僅僅只有一條，中間發(fā)生的事情都會(huì)通過日志來呈現(xiàn)。特別是RTC的日志非常多，如何從服務(wù)器中摘取關(guān)鍵信息？其實(shí)SRS設(shè)計(jì)了一套機(jī)制，也就是知道每個(gè)用戶的日志究竟是什么，并及時(shí)從中摘取出。

除了日志之外，上圖還展現(xiàn)了SRS中的錯(cuò)誤反饋，錯(cuò)誤參考了Go的機(jī)制，因?yàn)镚o中出現(xiàn)錯(cuò)誤可以Wrap打包錯(cuò)誤，這樣大家在反饋錯(cuò)誤時(shí)就可以粘貼相應(yīng)日志，就可以知道堆棧是什么。常規(guī)情況下出現(xiàn)錯(cuò)誤只會(huì)呈現(xiàn)一個(gè)錯(cuò)誤碼，開發(fā)者并不知道究竟發(fā)生了什么。但如果有錯(cuò)誤相應(yīng)的堆棧以及給出每一層堆棧的變量，查詢定位錯(cuò)誤的過程就會(huì)變的非常方便。一般在關(guān)注一個(gè)新的開源項(xiàng)目時(shí)大家不太會(huì)關(guān)注這個(gè)問題。但當(dāng)問題出現(xiàn)需要大家去查找問題源頭時(shí)，堆棧的作用非常關(guān)鍵。這意味著我們不僅能夠確定該問題的源頭，也能妥善解決問題。

5. 高性能

性能是一項(xiàng)基礎(chǔ)要求，一般情況下SRS的性能是其它服務(wù)器的兩倍左右。對(duì)性能的要求在RTC中其實(shí)會(huì)更嚴(yán)苛，因?yàn)镽TC的性能消耗更多。

6. SRS發(fā)展

關(guān)于SRS的發(fā)展，從2013年開始SRS一直都在穩(wěn)步發(fā)展。初期由于應(yīng)用場(chǎng)景相對(duì)固定，更新力度并不大。而現(xiàn)在，隨著Original Cluster邊緣集群相繼得到支持，直播場(chǎng)景的覆蓋也愈發(fā)完善，RTC也在不斷發(fā)展。大家可以看到最近各個(gè)視頻行業(yè)都在互聯(lián)網(wǎng)化，因此最近SRS的活躍度也非常高。

2019年左右，SRS-Forks超越了NGINX-RTMP，預(yù)計(jì)未來SRS-Forks的增長(zhǎng)是NGINX-RTMP的兩倍。

回顧SRS的發(fā)展脈絡(luò)，2013年v1.0實(shí)現(xiàn)了對(duì)直播基礎(chǔ)協(xié)議的支持如RTMP、HLS等。隨后的v2.0則主要支持FLV等以及移動(dòng)互聯(lián)網(wǎng)應(yīng)用，v3.0則提供了對(duì)Original Cluster的支持，同時(shí)很早就提供了對(duì)邊緣集群的支持，邊緣集群主要應(yīng)對(duì)很多人播放的場(chǎng)景。而Original Cluster則主要用于支持流播，例如監(jiān)控?cái)z像頭等。邊緣不會(huì)存儲(chǔ)流而Original Cluster則會(huì)存儲(chǔ)流，所以需要集群的存在，目前對(duì)直播場(chǎng)景的支持相對(duì)完善。

2020年初SRS支持了SRT，SRT主要用于解決遠(yuǎn)距離傳輸。同樣也是用于直播與廣電互聯(lián)網(wǎng)化的綜合場(chǎng)景，例如一些專業(yè)賽事、海外直播推流等。包括最近的GB28181、WebRTC等都能得到SRS的支持。

未來我們需要滿足更廣泛的互聯(lián)網(wǎng)直播場(chǎng)景與需求，例如支持SFU、IoT、AI能力與云存儲(chǔ)錄制、安全以及MCU、SFU、AV1、SIP等。希望能夠在2024年具備基本滿足以上所有場(chǎng)景的能力。