如何選擇音視頻開源項目，避坑指南
音視頻業(yè)務的繁榮，必定造就開源項目的繁榮，反過來說也是一樣的，互相成就。遍地都是開源的輪子，如何選擇？提供一個有效的角度，可作為避坑指南。如果已經入坑了，您躺平就好，入坑就已經有了門戶之見，死生有命富貴在天。
活躍程度
活躍程度，就是項目的年齡和更新頻率。
活得久就活得越久，一般活幾年的項目誰不遇到點問題，要死早死了，幾年還沒死那可能后面死的概率也小了。
不更新的項目就是坑了，沒有哪個開源項目拿來就能用的，除了那個996.ICU[1]，一般開源項目都是會遇到問題的，有人在更新維護就很重要。
SRS的Star是音視頻服務器中最多的，但是它的更新不穩(wěn)定，活躍度斷斷續(xù)續(xù)的。最近2年活躍度還不錯，如何持續(xù)10年是至關重要，也是非常大的挑戰(zhàn)。
Janus的Star雖然不是最多，但是一直持續(xù)活躍，長遠看是SRS的真正競爭對手。它背后有公司在支撐，這是一種活躍項目的典型思路。
業(yè)內口碑不錯的Mediasoup，很明顯已經走在停滯的邊緣，再過幾年估計就和NginxRTMP一樣停止更新了。當然它有值得學習的地方。
曾經直播大火時知名的開源服務器，目前Star也挺可觀的。雖然項目已經停止更新很多年，但是Star還是在平穩(wěn)增長，所以這是做開源不能過分在乎Star的原因，躺平也能漲Star。
Nginx雖然不是音視頻服務器，也是幾乎人盡皆知的服務器，很意外的是它一直在持續(xù)更新了很多年。它背后也是后一家商業(yè)公司在支撐，要想做好開源，沒有商業(yè)支撐很難持續(xù)活躍。
FFmpeg不是音視頻服務器，但是是音視頻業(yè)內的楷模，這活躍程度和持續(xù)的年數(shù)也是所有打算特別是沖動著做開源項目的楷模，18年持續(xù)活躍，請收下我的膝蓋。
Go和WebRTC在一起會發(fā)生什么？總有輪子能滿足你，總有語言粉絲要重新擼一遍，看起來pion作為庫的活躍度還可以，但是別著急，3年后再看看圖吧。PS：我個人不看好因為語言偏好就重新搞個項目，比如Go或Rust的RTMP server，呃。
ion是pion做的一個SFU，還沒出來多久就要掛了的圖像。所以請不要再宣傳ion多牛逼了，真的有點誤人子弟啦。PS：我其實是pion/transport的contributor，我覺得pion做測試框架不錯，壓測和回歸測試。
定位
為什么要做個開源項目？一言不合就造個輪子，反正也不要錢。
搜下RTMP Server[2]，有800多個項目，有C的[3]，有C++的[4]，有Nodejs的[5]，有Go的[6]，有Python的[7]，有Rust的，有Java的等等。
很大一部分是因為語言原因，自己做音視頻的更喜歡Rust，就搞個吧，占個坑吧。Go也是如此吧，新語言做老領域的開源項目，很多都是這種沖動。
老語言也一樣，比如C看不慣C++的浮躁所以要搞個，C++看不慣C的低效得搞個，C++11看不起C++98還是得再來一個，C++20出來肯定還得有RTMP server被創(chuàng)造出來。
因此，看開源項目的定位（介紹）就很關鍵，自己想清楚了定位，有自己的特點，才能和其他開源項目配合起來，才能做到長久更新。
看幾個音視頻服務器的介紹：
?nginx-rtmp[8], NGINX-based Media Streaming Server. 做Nginx的，缺個媒體服務器，所以我做了。?srs[9], SRS is a simple, high efficiency and realtime video server, supports RTMP/WebRTC/HLS/HTTP-FLV/SRT/GB28181. 簡單高效，直播和WebRTC互聯(lián)網(wǎng)場景。?janus-gateway[10], Janus WebRTC Server. 做會議(WebRTC)的服務器。?mediasoup[11], Cutting Edge WebRTC Video Conferencing. 一個CuttingEdge的WebRTC會議服務器。?licode[12], Open Source Communication Provider based on WebRTC and Cloud technologies. 基于云的WebRTC服務器。?FFmpeg[13], A complete, cross-platform solution to record, convert and stream audio and video. 強大完整的，跨平臺的，錄制轉碼和音視頻工具。
為何Mediasoup和Licode代碼看起來都比Janus牛逼，但為何就是干不過呢：
?Mediasoup的Cutting Edge到底是啥呢？是個技術點，和Janus有啥優(yōu)勢呢，其實技術都覺得自己牛逼，一般弄不清楚。?Licode是要基于云，現(xiàn)在好像也都是能基于云的，所以也沒看出來到底有何不一樣的目標。
同樣技術的還有NginxRTMP，不能拿著Nginx的錘子，就滿天下都能敲釘子，敲了Web的釘子，還要敲流媒體的釘子。
SRS有何不同：
?音視頻的門檻是核心的復雜性，門檻太高了，編譯就要死一片，各種場景死一片，太難了。所以SRS的核心目標是要簡單，足夠簡單，更簡單。?從業(yè)務上看，互聯(lián)網(wǎng)音視頻正在跨越行業(yè)，實現(xiàn)業(yè)務價值的同學不關注直播還是RTC，小孩子才做選擇，成年人我都要。客戶現(xiàn)在只說了要做直播，如果他回頭要連麥(RTC)呢；客戶現(xiàn)在說了只做會議，回頭他要錄制和轉CDN直播呢。直播和RTC已經融合了很久，業(yè)務并不區(qū)分是直播還是RTC，必須兩個都支持得很好。?互聯(lián)網(wǎng)音視頻服務器，云支持的SRS就支持，因為互聯(lián)網(wǎng)的業(yè)務特點是可能會暴增，如果云不支持就不能遷移上云。另外，開源是對云的很好配合，有些場景探索用開源，自建預研用開源，小規(guī)模快速跑通業(yè)務用開源，私有化部署用開源。
另外，為了簡單高效，SRS也不做客戶端和編解碼，F(xiàn)Fmpeg能做的RTSP或其他協(xié)議拉流都用FFmpeg做。
References
[1]?996.ICU:?https://github.com/996icu/996.ICU[2]?RTMP Server:?https://github.com/search?q=rtmp+server&type=repositories[3]?有C的:?https://github.com/arut/nginx-rtmp-module[4]?有C++的:?https://github.com/ossrs/srs[5]?有Nodejs的:?https://github.com/illuspas/Node-Media-Server[6]?有Go的:?https://github.com/gwuhaolin/livego[7]?有Python的:?https://github.com/theintencity/rtmplite[8]?nginx-rtmp:?https://github.com/arut/nginx-rtmp-module[9]?srs:?https://github.com/ossrs/srs[10]?janus-gateway:?https://github.com/meetecho/janus-gateway[11]?mediasoup:?https://github.com/versatica/mediasoup[12]?licode:?https://github.com/lynckia/licode[13]?FFmpeg:?https://ffmpeg.org/
???????????????? ?END ????????????????? 關注我的微信公眾號，回復“加群”按規(guī)則加入技術交流群。
點擊“閱讀原文”查看更多分享，歡迎點分享、收藏、點贊、在看。