2026 年 GitHub 上顶级的 WebRTC 开源媒体服务器

作者：Tsahi Levent-Levi
原文：https://bloggeek.me/webrtc-open-source-media-servers-github/

2026 年的 WebRTC 开源媒体服务器都有哪些，基于 GitHub 星标来看哪些最好。

这类文章属于那种事后会被人吐槽的”敏感文章”。所以我先用几条免责声明开场：

• 不同的工具适合不同的场景。也就是说，这里排位靠后的一款 WebRTC 媒体服务器，可能恰恰最适合你的需求。
• 查这些资料的过程挺有意思，所以我非得把它写下来。
• 我确实爱你们所有人，请别生我的气。

核心要点速览

• WebRTC 开源生态仍在不断变化与迁移。
• Jitsi Meet 以 29,875 颗星标领先，LiveKit 20,731 颗、Pion 16,759 颗。所有数据取自 2026 年 9 月。
• 若改用活跃度而非星标排序，榜单会重新洗牌。在本文介绍的五者中，mediasoup 星标排第五，提交量却排第三：过去 52 周 541 次提交，而 Janus 只有 66 次。
• 提交频率未必是健康度指标，必须结合厂商自身的语境来看，如类型、规模等等。
• 本文介绍的五者中有三个实质上由一个人撑起。mediasoup 的头号作者贡献了去年 86.7% 的提交，Janus 为 68.2%，LiveKit 为 61.9%。Jitsi 是例外，85 个人的贡献里最高占比仅 32.8%。
• 没有唯一的最优解。会议选 Jitsi，可编程后端选 LiveKit，嵌入式与特殊项目选 Pion，大规模自建选 mediasoup，需要付费支持的全能选手选 Janus，摄像头与流媒体选 MediaMTX。

WebRTC 开源生态

WebRTC 是免费的。至少，作为一项开放标准的那部分是免费的，而且它有一个商业级开源实现，已经在所有现代浏览器中可用并内置。

这为它带来了一个相当不错的开发者生态，其中一部分天然就是开源的。在 GitHub 上简单搜索”webrtc”，会返回超过 3.2 万个结果。

GitHub 上的 WebRTC 项目有很多不同的方向，我脑子里首先蹦出来的主要有：

• 媒体服务器
• 信令服务器与框架
• 各种语言实现的 WebRTC
• 示例与实验
• 基于 WebRTC 之上构建的应用
• ……

本文我只聚焦媒体服务器。

我心目中的”五佳”WebRTC 开源媒体服务器

WebRTC 媒体服务器数量不少，其中很多是开源的。不过大多数并不广为人知，也没到让我注意的程度（通常有人告诉我他把它用在商业用途上时，我才会留意）。

这些年来，热门 WebRTC 媒体服务器的名单一直在演变。下面是我目前画的现状图：

如今我的”五佳”就是上面提到的这几家。偶尔我还会加上 OpenVidu，它算是坐在 mediasoup 或 LiveKit 之上的一层封装（取决于你的偏好：用 LiveKit SFU 的社区版，还是用 mediasoup + OpenVidu 的商业 PRO 升级版）。

在我 WebRTC 工具库里的媒体服务器页面，你可以看到它们相互之间的对比，且更新得比较及时。下面是我对这些数据的解读方式。此外，这五家我按字典序呈现：Janus、Jitsi、LiveKit、mediasoup、Pion。

想更好地理解我眼中/统计口径下的”媒体服务器”是什么，可以看看这个视频：对我来说，2026 年它就是一个现代 SFU，外加实现群组会议所需的那套工具链。其余的都只是附加功能与能力。

https://www.youtube.com/watch?v=d2N0d6CKrbk

开始之前

先说一句：MediaMTX 是一款媒体流媒体服务器，它最近开始频繁出现在我的网页搜索里（20,037 颗 GitHub 星标，排名相当靠前）、AI 结果里，以及和我交流的厂商口中。它适合流媒体场景，但并不符合我在这里要找的”媒体服务器”。

如果你做的事需要多个人互相说话，或者 2 个以上的人在线讨论、同时有任意数量的人在旁听，那么你需要的正是媒体服务器。说得简单点：如果对部分用户来说媒体需要双向流动，那你就来对地方了，继续往下读。

如果你想要的是把多路视频拼到一个画面上、把监控摄像头接到观看端，或者笼统地说把媒体视为单向流动的东西，那你要找的是流媒体（MediaMTX 属于这一类）。这种情况直接看我 WebRTC 工具库里的流媒体服务器分类即可。

用 GitHub 来办一场 WebRTC 人气大赛

到底该怎么判断哪个 WebRTC 开源媒体服务器项目用得最多？

一种办法是数星标，GitHub 星标。这次我决定同时看人气（星标）和活跃度（项目提交量）。这让我得到了一个与以往对比略有不同、也颇为有趣的视角。

这些项目在人气与活跃度上的相对位置如下：

第一眼的直观感受是什么？

• mediasoup 人气不算高，但它绝对是在”真干活”。
• Jitsi 面向的是另一类受众，至少从它拿到的星标来看是这样。
• LiveKit 已经超过了它内部所使用的 Pion。

另一个有趣的视角是：每个项目对单一主要贡献者/维护者的依赖程度。

Project	Stars	Forks	Contributors	Commits (52w)	Language
Jitsi Meet	29,875	8,020	362	814	TypeScript
LiveKit	20,731	2,307	117	584	Go
MediaMTX	20,037	2,360	129	710	Go
Pion	16,759	1,880	239	227	Go
Janus	9,159	2,624	297	66	C
mediasoup	7,354	1,250	55	541	C++, Rust / Node.js
OpenVidu	2,125	478	32	473	TypeScript

mediasoup、Janus 和 LiveKit（！）​ 都高度围绕单一主要贡献者组织。Jitsi 看起来是团队作战。​Pion 则是另一种”不同”。我会在各个项目的章节里分别谈到。

下面我们快速逐个深入看看。

Janus

Janus 是最古老的 WebRTC 媒体服务器之一。它用 C 语言编写，这可能是它采用率有限的原因——如今大多数开发者连用 C 写个 hello world 都不会，更别说搞懂它的内存使用概念（你必须显式释放自己分配的内存）。

Janus 的优势在于它背后有一家公司。Janus 的维护方 Meetecho 围绕 Janus 提供付费支持与开发服务，这是其他开源 WebRTC 媒体服务器所欠缺的。

Janus 的发展轨迹已经很久没有变化了。他们运营着一艘成熟、稳定的船，整体提交量是这里所有项目中最少的。

至于贡献分布，Janus 基本围绕 Lorenzo Miniero 构建。其余都是来自其他人的少量、轻微贡献。

Jitsi Meet

Jitsi Meet 很可能是最古老的 WebRTC 媒体服务器。它由 BlueJimp 创立，BlueJimp 被 Atlassian 收购，之后又转手给了 8×8。

虽然 Jitsi 并不为 Jitsi 提供直接的支持与开发服务，但它提供了 JaaS，一项面向开发者的托管式 Jitsi 服务。

Jitsi 用 Java 编写，并有一个 React 实现的 UI。

它一飞冲天的一个原因是疫情。Jitsi 是唯一一个开箱即用、且针对群组通话做过完整构建与优化的开源方案。从一开始，他们的使命就是打造一个开源的 Google Hangouts（也就是今天的 Google Meet）。而他们成功了。

通过把适用范围收窄到特定场景，他们反而把自己的可用性开放给了更大的目标受众，远远超出了”构建应用的开发者”这一群体。

这个不公平优势让他们坐上了头把交椅。但这并不意味着他们适合所有人，恰恰相反他们适合那些要打造”类 Google Meet 体验”的人。超出这个场景的需求，先去别家媒体服务器看看。但如果是要做一个类 Google Meet 的服务？从 Jitsi Meet 起步。

有意思的一点是：Jitsi 是这些开源项目中唯一一个团队作战的。它是这批项目里提交分布最分散的一个。Jitsi 背后的那个人 Emil Ivov 打造了这个工具和团队，带着它完成了一次成功的收购和原团队大部分（还是全部？）成员的迁移，又在第二次收购中与团队一起挺了过来。他现在刚刚离开 8×8 和 Jitsi。近几年他已不再是贡献者，所以这套团队协作不会因为他的离开而消失。

请注意：对 Jitsi，我看的是 Jitsi Meet，而不是 Jitsi Videobridge。绝大多数情况下，厂商会选择这一层而不是更底层的 videobridge，原因是它更简单、他们懒，还是别的什么，就不好说了。

LiveKit

LiveKit 是一家商业化的 Video API / Voice AI 厂商，同时也是一个开源媒体服务器项目。

它是我 Video API 报告中的领先者之一，并在 2026 年 1 月以 10 亿美元估值完成了 1 亿美元 C 轮融资。

其开源部分用 Go 编写，并且同样基于 Pion。

如今，在我几乎所有关于开源媒体服务器采用的对话中，都会出现它的身影。

他们的不公平优势就是”开源”这件事本身，它让人们可以先把它当作 SFU 采用，等事情变复杂了再切到托管云。对于那些想给决策”去风险”的人来说，这也提供了一条从托管到自托管的简单迁移路径。至于这种”去风险”有多少真实性，那就是另一个故事了。

有意思的是：一个如此热门、又有商业公司背书项目，居然集中于单一作者，贡献占比达 62%。

mediasoup

mediasoup 是开源 WebRTC 媒体服务器的 Node.js 实现。它面向高性能设计，有个独特理念：把应用直接构建在同一个 Node.js 进程里。如今也提供了 Rust 接口；而繁重的媒体处理一直是用 C++ 完成的。

mediasoup 的挑战在于它无法提供官方支持与开发服务。原因很简单，主要创建者和贡献者如今都在 Miro 做开发者。

这个挑战大概也是 mediasoup 在 GitHub 人气大赛中增长缓慢的原因。

从贡献者分布看，这是一个由一个人跑完全场、并拥有主导权的项目。87% 的提交来自单一作者，另外仅有 5 位不同作者，是本文所有备选中最集中的一组。请把它视为一项潜在风险。

话虽如此，如果你去看看许多大规模群组通话部署，它们用的就是 mediasoup……

Pion

Pion 相比其他项目成长得很快。它的贡献者分布也是最好的。原因有三：

• Pion 用 Go 语言编写。不知为何，Go 有一群热爱这门语言的开发者粉丝。这让 Pion 成为他们（名副其实的）”Go-to”开源项目。
• Pion 是通用型的。它既能用来构建客户端，也能构建服务端。在 Pion 之上有多个媒体服务器实现，但总的来说，能用它做出更多东西这一点，本身就立刻为项目带来更多星标。
• Sean DuBois。创办 Pion 的这个人有着极强的、极具感染力的个人魅力，推动了 Pion 向前。其他开源项目也有各自独特的灵魂人物，但任何有机会直接和 Sean 聊过的人都会明白我在说什么。

Sean 在这里有多受欢迎、多有感染力？

• 这个项目有相当多维护者，且有一条健康的”长尾”。这意味着厂商会把自己需要的东西加进去，并直接回馈贡献给 Pion。
• Sean 本人。他已经不再是最主要的维护者了。

随着 Pion 人气增长，基于 Pion 的商业服务也越来越多，其中包括 LiveKit。

最好的 WebRTC 开源媒体服务器

没有。

全都是。

看情况。

为了不耸肩摊手、不把你晾在这儿没答案，下面是我脑子里大多数时候对这批工具的定位框架。

快速选择菜单：

• 会议 → Jitsi
• 可编程后端 → LiveKit
• 嵌入式与”特殊”项目 → Pion
• 大规模、自建 → mediasoup
• 需要付费支持的全能选手 → Janus
• 摄像头与流媒体 → MediaMTX

对管理者，我的建议几乎总是：让你们的开发者去试用，然后自己挑选他们认为合适的开源 WebRTC 媒体服务器。这些备选之间确实存在差异，但归根结底，如果有人试图强迫开发者用一个他认为不对的方案，那位开发者一定会向逼他的人解释清楚这个决定为什么是错的。换句话说，别跟你的开发者对着干。

对开发者，我会根据他们的场景、需求乃至公司基因来推荐不同的媒体服务器。如何做这个判断，我在我的《高级 WebRTC 架构》课程里一步步讲过。

所以简短地说：没有最好的 WebRTC 开源媒体服务器。有几个都很棒，你只需要挑那个最适合你的 😀

常见问题

最好的开源 WebRTC 媒体服务器是哪个？

没有”最好”这一说。会议选 Jitsi。可编程后端选 LiveKit。嵌入式与特殊项目选 Pion。自建的大规模群组通话选 mediasoup。需要付费支持的全能选手选 Janus。摄像头与流媒体选 MediaMTX。

这是简短快速的回答，实际效果因人而异，决定也可能随你的具体需求而变。

媒体服务器之外，我是否还需要信令服务器？

需要，而且两者干的活不同。媒体服务器负责路由音频和视频。信令则是参与者找到彼此、并就发送什么内容达成一致的方式，而 WebRTC 故意没有定义它，好让你自己选择。这里的一些服务器自带信令，比如 Jitsi Meet 和 LiveKit；另一些则指望你自己带，尤其是 mediasoup 和 Pion。

MediaMTX 是 WebRTC 媒体服务器吗？

它支持 WebRTC，但它是一款流媒体服务器，而不是会议服务器。RTSP 之类的协议进，WebRTC 出，面向的是摄像头和单向媒体。如果你的部分用户需要媒体双向流动，那你该用上面那五款中的一款。

LiveKit 是开源的吗？

是，同时它也是一家商业公司。其服务器是开源的，用 Go 编写、构建于 Pion 之上，LiveKit 还配套销售托管云服务。代码采用 Apache 2.0 许可。