開源流媒體服務器：為何一定得再擼個新的

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

文 / 楊成立

整理 / LiveVideoStack

視頻回放：

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

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

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

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

得益于我國通信基礎設施的日趨完善，尤其是Wi-Fi、4G網絡的下沉普及，我國互聯網市場音視頻產品服務在2015～2018年經歷了爆發式增長。當時消費者普遍擁有的可以觀看視頻的帶寬大約為1M，網絡環境較為穩定。

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

無論是傳統PC時代還是現在的移動互聯網時代，流媒體中主要使用的協議都是RTMP/FLV與Apple的HLS，流媒體播放器主要有Red5、Nginx-RTMP、CRTMP、Wowza、AMS等。大約是從2017年開始，Chrome中的Flash播放器就已經處于默認禁用的狀態，后續Flash也會逐漸退出互聯網歷史舞臺。

隨著互聯網的發展，移動端直播逐漸興起并且成為主流。例如當前移動辦公平臺中的互聯網直播：主要調用的是Native播放器，使用FLV協議。瀏覽器端則多采用HLS，二者共同構成了較為成熟完善的互聯網直播協議體系。

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

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

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

目前SRT、IoT等的發展仍需面臨很大挑戰，特別是現在國內互聯網的可能性不斷豐富，直播產業生態環境也會趨于向好，新場景層出不窮。

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

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

若想實現此開源流媒體服務器，我們需要考慮諸多關鍵約束和能力。

首先就是該平臺需要具有一定伸縮性，也就是足夠的彈性。互聯網業務可以從局部擴展到很大的領域，如果我們使用開源方案則需要清晰意識到如果業務規模變大之后，現有資源與經驗能否支撐起如此大規模的服務運行，這需要很多開發者的維護與云廠商的支持。如果沒有開源平臺和云廠商的支持，那么我們只能自主搭建平臺并部署服務器。對于很多企業來說，他們不可能有能力和資源開展這么多業務，所以開源方案至關重要。

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

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

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

1. Scenario

1.1 互聯網直播與連麥

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

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

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

1.2 互聯網實時通信

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

1.3 互聯網媒體中心

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

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

在特殊場景下，如為跨國直播設計的遠距離傳輸當中，數據大多是通過專項網絡進行傳輸，也可以走互聯網或SRT。這些特殊的場景與業務強相關，并不太適合用統一的標準來框定，其規模不足夠大也不能夠成為標準。

2. Scalability——基于Cloud或對接CDN

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

3. Latency

3.1 實時流媒體直播

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

3.2 實時流媒體系統

對GB28181進行測試，從上圖實驗結果我們可以發現，HIKVISION監控內網攝像頭延遲為280毫秒、阿里云服務器WebRTC延遲約為210毫秒、阿里云服務器RTMP延遲1100毫秒。我們可以看到WebRTC服務器比內網監控攝像頭的延遲還要低，出現這種情況主要是因為延遲并不單純是網絡問題。該場景下WebRTC延遲比監控還要低，且具備場景下載的能力。監控大多會走私有傳輸路線，傳統方案若想正常播放則需要安裝IE插件。而通過標準協議大家想要從手機端看到，手機只需要直接集成SDK，同時瀏覽器也可以直接看到畫面，這樣不需要安裝任何插件，各個攝像頭的流都可以看得到。

4. 舉例

4.1 Cloud Native

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

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

4.2 錯誤&日志

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

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

5. 高性能

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

6. SRS發展

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

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

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

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

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