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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Scenario

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

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

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

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

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

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

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

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

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

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

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

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

3. Latency

3.1 實時流媒體直播

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

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

對GB28181進行測試，從上圖實驗結(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)控攝像頭的延遲還要低，出現(xiàn)這種情況主要是因為延遲并不單純是網(wǎng)絡(luò)問題。該場景下WebRTC延遲比監(jiān)控還要低，且具備場景下載的能力。監(jiān)控大多會走私有傳輸路線，傳統(tǒng)方案若想正常播放則需要安裝IE插件。而通過標準協(xié)議大家想要從手機端看到，手機只需要直接集成SDK，同時瀏覽器也可以直接看到畫面，這樣不需要安裝任何插件，各個攝像頭的流都可以看得到。

4. 舉例

4.1 Cloud Native

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

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

4.2 錯誤&日志

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

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

5. 高性能

性能是一項基礎(chǔ)要求，一般情況下SRS的性能是其它服務(wù)器的兩倍左右。對性能的要求在RTC中其實會更嚴苛，因為RTC的性能消耗更多。

6. SRS發(fā)展

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

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

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

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

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