去年帮一个做知识付费的播开朋友搭直播系统，他预算不到两万，播开却要求支持500人同时在线、播开连麦互动、播开还能录播回放。播开我第一反应是播开让他去用SaaS，但他说数据必须留在自己服务器上。播开折腾了两周，播开最后靠一套开源方案跑通了——延迟控制在400毫秒以内，播开服务器成本每月不到600块。播开这件事让我重新审视了web直播开源生态的播开现状。

市面上能用的播开开源直播方案其实分两类。一类是播开完整的端到端平台，比如Owncast和Ant Media Server。播开Owncast特别适合个人主播，播开一个Go语言写的二进制文件扔到服务器上就能跑，自带聊天室和HLS推流。我实测过，单核2G的VPS撑50个观众没问题。但它的短板也很明显——没有连麦功能，互动全靠文字。Ant Media Server功能更全，支持WebRTC和低延迟HLS，社区版免费，但企业版才解锁集群和自适应码率。朋友那个项目最后选的就是Ant Media社区版，自己写了点胶水代码补上鉴权和录制。

另一类是底层组件拼装。SRS（Simple Realtime Server）在国内用的人不少，纯C++写的，把RTMP、WebRTC、HLS、SRT全揉在一起了。它的文档是中文的，这点对国内开发者友好。但SRS本身不提供前端播放器，你得自己接flv.js或者hls.js。我见过一个在线教育团队用SRS加Vue自己搭了一套，连麦走WebRTC，大班课走HLS，切换逻辑写了将近两千行。这种方案灵活，代价是维护成本高——每次SRS升级都要重新测一遍边缘情况。

真正让我意外的是WebRTC生态的成熟度。以前做低延迟直播必须上SFU（选择性转发单元），现在Mediasoup和Janus把门槛拉低了不少。Mediasoup的Node.js库设计得很干净，一个房间开四个Worker就能扛住上百路流。但它的坑在于客户端兼容性——Safari对Simulcast的支持一直不太稳定，iOS上偶尔会掉到360p。另一个选择是LiveKit，Go写的SFU，API设计比Mediasoup更现代，还自带TURN服务。不过LiveKit的社区版限制同时在线人数，超过就得买License。

推流端反而没什么悬念。OBS是绝对主流，开源免费，插件生态也全。移动端推流用Larix或者Streamlabs的SDK，但后者要商业授权。有个做户外直播的团队自己改了OBS的源码，把推流码率动态调整逻辑换成了基于网络抖动的算法，据说弱网下卡顿率降了四成。这种深度定制只有开源方案能玩得转。

播放器这块，flv.js已经停止维护了，现在新项目基本转向hls.js或者dash.js。但HLS的延迟天生就高——苹果官方推荐6秒以上。要压到3秒以内得用LL-HLS，可服务端支持LL-HLS的开源方案不多。SRS从4.0开始支持，但配置项藏得很深，我翻了半天文档才找到那个hls_fragment参数。WebRTC播放器倒是延迟低，可它跟CDN的兼容性一直是个麻烦事。阿里云和腾讯云的WebRTC加速服务都收费不菲。

开源方案最大的价值不是省钱，是让你能控制整个链路。商业SaaS出问题时你只能提工单等回复，开源方案出问题你可以直接翻源码。上个月有个客户反馈直播画面偶尔绿屏，我追到SRS的issue列表里发现是某个版本对H.265支持有bug，降级到4.0.198就解决了。这种排查效率在闭源系统里根本不可能。

但别误会，开源不等于免费。时间成本、人力成本、试错成本都得算进去。那个知识付费朋友的项目，我前后投入了将近80个小时。如果按我的时薪算，够买三年商业SaaS了。所以选开源之前先问自己：团队里有没有人能读懂C++或者Go？出故障时能不能在半小时内定位到是推流端、服务端还是播放端的问题？如果答案是否定的，老老实实买云服务更划算。

未来半年我比较看好两个方向。一是WASM编解码器，能让浏览器直接处理AV1，省掉转码服务器。二是基于QUIC的推流协议，SRS和Mediasoup都在做实验性支持。不过这些离生产环境还有距离。眼下最务实的做法是：小规模用Owncast，中等规模用SRS加自研前端，大规模直接上商业方案——开源方案在超大规模场景下的运维复杂度，不是一般团队能扛住的。