如何选择音视频开源项目，避坑指南

音视频业务的繁荣，必定造就开源项目的繁荣，反过来说也是一样的，互相成就。遍地都是开源的轮子，如何选择？提供一个有效的角度，可作为避坑指南。如果已经入坑了，您躺平就好，入坑就已经有了门户之见，死生有命富贵在天。

活跃程度

活跃程度，就是项目的年龄和更新频率。

活得久就活得越久，一般活几年的项目谁不遇到点问题，要死早死了，几年还没死那可能后面死的概率也小了。

不更新的项目就是坑了，没有哪个开源项目拿来就能用的，除了那个996.ICU^[1]，一般开源项目都是会遇到问题的，有人在更新维护就很重要。

SRS的Star是音视频服务器中最多的，但是它的更新不稳定，活跃度断断续续的。最近2年活跃度还不错，如何持续10年是至关重要，也是非常大的挑战。

Janus的Star虽然不是最多，但是一直持续活跃，长远看是SRS的真正竞争对手。它背后有公司在支撑，这是一种活跃项目的典型思路。

业内口碑不错的Mediasoup，很明显已经走在停滞的边缘，再过几年估计就和NginxRTMP一样停止更新了。当然它有值得学习的地方。

曾经直播大火时知名的开源服务器，目前Star也挺可观的。虽然项目已经停止更新很多年，但是Star还是在平稳增长，所以这是做开源不能过分在乎Star的原因，躺平也能涨Star。

Nginx虽然不是音视频服务器，也是几乎人尽皆知的服务器，很意外的是它一直在持续更新了很多年。它背后也是后一家商业公司在支撑，要想做好开源，没有商业支撑很难持续活跃。

FFmpeg不是音视频服务器，但是是音视频业内的楷模，这活跃程度和持续的年数也是所有打算特别是冲动着做开源项目的楷模，18年持续活跃，请收下我的膝盖。

Go和WebRTC在一起会发生什么？总有轮子能满足你，总有语言粉丝要重新撸一遍，看起来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被创造出来。

因此，看开源项目的定位（介绍）就很关键，自己想清楚了定位，有自己的特点，才能和其他开源项目配合起来，才能做到长久更新。

看几个音视频服务器的介绍：

•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互联网场景。•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有啥优势呢，其实技术都觉得自己牛逼，一般弄不清楚。•Licode是要基于云，现在好像也都是能基于云的，所以也没看出来到底有何不一样的目标。

同样技术的还有NginxRTMP，不能拿着Nginx的锤子，就满天下都能敲钉子，敲了Web的钉子，还要敲流媒体的钉子。

SRS有何不同：

•音视频的门槛是核心的复杂性，门槛太高了，编译就要死一片，各种场景死一片，太难了。所以SRS的核心目标是要简单，足够简单，更简单。•从业务上看，互联网音视频正在跨越行业，实现业务价值的同学不关注直播还是RTC，小孩子才做选择，成年人我都要。客户现在只说了要做直播，如果他回头要连麦(RTC)呢；客户现在说了只做会议，回头他要录制和转CDN直播呢。直播和RTC已经融合了很久，业务并不区分是直播还是RTC，必须两个都支持得很好。•互联网音视频服务器，云支持的SRS就支持，因为互联网的业务特点是可能会暴增，如果云不支持就不能迁移上云。另外，开源是对云的很好配合，有些场景探索用开源，自建预研用开源，小规模快速跑通业务用开源，私有化部署用开源。

另外，为了简单高效，SRS也不做客户端和编解码，FFmpeg能做的RTSP或其他协议拉流都用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  ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧
关注我的微信公众号，回复“加群”按规则加入技术交流群。

点击“阅读原文”查看更多分享，欢迎点分享、收藏、点赞、在看。