直接看一个现象你随便打开一个视频会议、一个直播平台、一套监控系统背后站着的几乎都是开源音视频项目的影子。FFmpeg负责转码SRS或者ZLMediaKit负责推拉流WebRTC体系负责实时通话mpv或者ExoPlayer负责播放。这几年我折腾过的项目从嵌入式板卡到云端转码集群从桌面工具到移动端播放器绕来绕去始终没离开这摊东西。所以当有人让我盘点“经典开源音视频项目”时我脑子里第一反应不是某个软件的名字而是一条完整的数据链路。这篇内容适合谁刚入行想做音视频开发、想搭一套自己的直播推流服务、或者在选型阶段纠结于项目方案的技术负责人。我会按自己的习惯把36个项目拆成编解码、播放器、流媒体服务端、实时通信、音频处理五大块每块讲清楚项目定位、选型逻辑和实操经验最后再给一些组合打法和排队坑的笔记。全部都是真实用过的项目没有凑数。1. 先从一张音视频链路图说起1.1 一个视频从采集到播放到底经过哪些环节我不喜欢一上来就堆项目清单那样看完也记不住。先建立一个坐标系后面每个项目都能对号入座。一条典型的音视频数据流大概分六个环节采集、编码、封装、传输、解码、渲染。采集阶段你面对的是摄像头、麦克风、屏幕录制这个环节最常见的开源项目是OBS Studio和PortAudio。编码阶段把原始画面压成H.264、HEVC、AV1这里就是x264、x265、libvpx、libaom这些编码器的主场。封装阶段负责把编码后的数据写进MP4、FLV、TS这些容器FFmpeg是绝对主力。传输阶段要解决“数据怎么从一端到另一端”RTMP、RTSP、HLS、WebRTC各有各的玩法对应SRS、ZLMediaKit、Live555、MediaMTX这类服务器。解码和渲染阶段回到播放端VLC、mpv、ExoPlayer、ijkplayer都是干这个的。之所以先把链路画出来是因为你在选型的时候大概率不会只用某一个项目而是每个环节挑一个拼起来。比如一个最简单的直播场景OBS推流给SRSSRS再转成HLS给浏览器播放中间可能还要挂一个FFmpeg做转码。链路意识一旦建立后面所有项目在你眼里就不是孤立工具而是可替换的模块。1.2 我判断“经典”的标准标题里有“经典”两个字我的理解有三层。第一层是时间沉淀。项目活了五年以上还没死社区还能持续发版本这本身就说明它解决的问题是真实且长期的。第二层是被广泛集成。经典不是自己说自己好用而是别人在它基础上做了多少东西。FFmpeg被几百个播放器、转码工具引用这种生态地位没法伪装。第三层是解决了一个核心痛点而不是一个花哨功能。Live555虽然界面老旧、文档粗糙但它把RTSP客户端这套东西做得足够标准所以至今还有人在嵌入式项目里用它。我不太看GitHub Star总数那个数字在很多项目里说明不了质量问题。我更关心的是如果你要基于它二次开发文档全不全、模块划分清晰不清晰、社区提问有没有人搭理。这三点比什么都实在。2. 底层编解码音视频链路最硬的一环2.1 FFmpeg绕不开的万能工具箱如果整个开源音视频领域只能留下一个项目我会毫不犹豫留FFmpeg。它不是一个单纯的转码工具而是一整套音视频处理库加命令行工具。从解封装、解码、滤镜处理、编码到封装FFmpeg全链路覆盖。你平时听到的“转码”、“切片”、“抽帧”、“加水印”、“音视频拼接”本质都是FFmpeg命令或者基于其库开发的功能。我的感触是FFmpeg的命令行工具基本能解决日常90%的临时需求但真正体现功力的地方是它的库接口。有一次在嵌入式设备上做视频分析摄像头输出的是H.264裸流我需要用硬件解码器解出YUV帧再送进推理模型。当时的做法就是用libavcodec接硬件解码用libavformat处理裸流和MP4文件的输入输出用libavutil管理内存和像素格式转换。这些库接口之间的关系就像积木按需拼装灵活度比命令行高一个量级。使用FFmpeg有几个高频注意点。像素格式和颜色空间转换是新手最容易忽略的地雷YUV420P、NV12、NV21看起来差不多实际对齐和内存布局差很多转换错了画面会绿或者颜色偏色。时间戳处理也容易出问题转封装的时候如果ts不连续播放器就会快进快退卡顿。我的习惯是拿到任何流先跑一遍ffprobe看流信息再动手转码或者解析省掉大量后面排查的时间。2.2 编解码器家族x264、x265、libvpx、OpenH264、dav1d、libaomFFmpeg是“处理框架”具体把画面压成什么格式要靠各家编解码器。这里我按使用场景说几个主流选择。x264是H.264编码器的事实标准兼容性最好几乎全平台都能解直播和短视频绝大多数场景都适用。x265对应HEVC编码压缩率比H.264高大概30%到50%但是编码慢、硬解支持不如H.264所以更适合点播场景直播里用得少。libvpx是VP8和VP9的实现VP9主要用在浏览器生态里Chrome和Firefox默认支持。OpenH264是兼顾性能和专利许可的H.264实现通常用于WebRTC这种对允许条件敏感的场景。到了AV1时代编码端看libaom解码端速度最有优势的就是dav1d这个项目做得确实漂亮早期AV1软解卡顿的问题就是被它缓解的。选编码器本质上是在算一笔账压缩率、编码速度、解码兼容性、专利条款。直播要求低延迟和高吞吐我一般首选x264的ultrafast到medium档位按机器性能调整。点播追求画质就上x265甚至AV1。实时通话场景OpenH264加VP8的组合足够稳妥硬件编码支持也比较全面。2.3 音频编码与处理LAME、Opus、FLAC、libyuv、SpeexDSP视频之外音频也有自己的硬骨头。LAME是MP3编码器的老牌实现虽然MP3格式老了但在兼容性上有不可替代的地位。Opus是现代音频编码的标准答案低码率下音质表现优秀延时也低VoIP和直播配乐都喜欢用。FLAC负责无损压缩做音乐存档和音频分析时很常用。libyuv严格说不是编码器而是像素格式转换和缩放库。为什么把它放进音视频核心清单里因为视频处理里几乎没有哪一步不需要它。把YUV转成RGBA给UI显示把NV12缩放成模型输入尺寸这些底层操作写起来很繁琐libyuv用SSE/NEON优化过比自己手写循环快好几倍。SpeexDSP则是在音频前处理领域非常实用的库主要负责回声消除、降噪和自动增益控制搞过实时语音通信的人一定不陌生。这类底层库的调试体验通常都不太好因为它们缺乏直观的图形界面。我的经验是每个库单独写一个极小测试用例输入一张固定图片或者一段已知的音频输出之后再比对确定每一步都符合预期再进项目集成。直接跳到端到端联调出了问题你会完全无从下手。3. 播放器与端侧工具从桌面到移动端3.1 VLC、mpv、IINA、Kodi桌面播放器各有所长播放器是普通用户感知最强的开源音视频项目。VLC大概是知名度最高的几乎什么文件格式都能播网络串流支持也强。如果遇到一个异常的文件打不开我第一反应是丢给VLC试试它能放就说明文件本身没有结构性问题问题出在别的播放器上。物理上VLC的优势是“通吃”解码能力全面网络协议支持丰富几乎没有它吃不了的格式。mpv则是我日常主力播放器跟VLC相比它更“极客”。mpv基于MPlayer和MPlayer2的代码演进而来它的核心哲学是简洁和脚本化配置文件写得好可以用键盘操作一切。在Linux服务器上我没有图形界面也会用mpv来做快速画面验证。IINA是macOS上体验最好的开源播放器界面风格跟macOS原生应用很统一底层用的就是mpv的引擎。Kodi定位差异比较大它不是纯粹的播放器而是一个家庭影院中心本地媒体库管理、刮削器、插件生态都做得完善适合做整套影音媒体系统。桌面播放器选型这件事我个人的分法很简单普通用户直接用VLC喜欢折腾配置的人用mpvMac用户在意界面就IINA家里有NAS和整柜蓝光片子就上Kodi。3.2 移动端与嵌入式ExoPlayer和ijkplayer移动端的播放器选型相比桌面要复杂得多因为要考虑平台解码能力、硬解开关、自定义协议这些细节。ExoPlayer是Android平台上公认的主力播放器它不是把FFmpeg一股脑编进去而是提供模块化设计视频、音频、加载器、扩展都可以按需组合。需要播放RTSP或者特殊格式时可以通过FFmpeg扩展模块补上。我经常看到有人在Android项目里直接硬套VLC的Android版或ijkplayer但对于复杂业务需求ExoPlayer的可定制性和稳定性反而更好。ijkplayer是明确基于FFmpeg的轻量级播放器它的价值在于提供了跨平台Android和iOS的播放能力曾经在直播场景里非常流行。不过这个项目现在更新频率不高新格式支持要靠自己编译最新的FFmpeg进去。如果你只是需要一个能播RTMP、HTTP-FLV的播放器ijkplayer依然省事如果要做长期演进ExoPlayer加自研扩展更靠谱。嵌入式场景下播放端一般不看完整播放器而是直接用FFmpeg的解封装和解码库自己做轻量播放逻辑。资源受限时每多一个模块都是负担播放器的功能边界反而要往回缩。3.3 GStreamer和HandBrake框架和批处理工具GStreamer跟FFmpeg的定位不一样。FFmpeg更像一个集中在命令行和库调用的处理工具GStreamer则是一个完整的多媒体框架用插件化的方式把采集、编码、处理、输出串成一条流水线。它的学习曲线比FFmpeg陡峭但灵活性极强非常适合理想要长线演进自己的音视频处理管道的团队。做智能硬件或者嵌入式多媒体系统的人多半会跟它打交道很多厂商的多媒体中间件底层就是GStreamer。HandBrake是转码工具里很顺手的一个提供图形界面和命令行可以批量把DVD、蓝光原盘或者各种视频转成MP4/MKV内置了预设队列和批量处理能力。我自己做视频素材归档时经常用它做批量转码一方面它的默认参数比较合理另一方面它支持硬件编码大文件批量处理效率很高。4. 流媒体服务端直播和点播的枢纽4.1 SRS和ZLMediaKit两个非常值得花时间研究的服务端流媒体服务端的核心功能是收流、转协议、分发。SRS是我在直播场景里用得最顺手的开源项目它围绕RTMP、HLS、HTTP-FLV、WebRTC等协议做了很完整的一套服务从简单的单机直播到大规模集群分发都能支撑。SRS的设计思路是“配置驱动”一个配置文件搞定大部分场景部署和运维成本很低。早期我用它的一个原因很简单拉流鉴权、转码、秒开、集群回源这些直播里高频要用的能力它都开箱即用。ZLMediaKit的定位更偏向底层库和插件化服务。它对标的是集成商和二次开发场景代码结构清晰C实现性能和跨平台能力都很强。如果你要做自己的流媒体网关或者私有化部署ZLMediaKit在灵活度上会更好。它可以用来接收摄像头RTSP流再以RTMP、HLS、WebRTC等多协议转发出去这种多协议互转能力在监控和直播混合场景里特别值钱。SRS和ZLMediaKit之间怎么选我的经验是目标是把直播服务快速搭起来跑业务选SRS目标是做流媒体平台级产品需要深度改造协议和私有化功能选ZLMediaKit。两者的社区都很活跃出问题基本搜得到答案。4.2 轻量级方案MediaMTX、Live555、nginx-rtmp-module并不是所有场景都需要一套完整的流媒体服务很多场景一个轻量级工具就够。MediaMTX非常适合IPC摄像头的接入和转发场景。以前我叫它rtsp-simple-server后来改名了。它的核心能力是把RTSP流转换为其他协议输出比如把摄像头的RTSP推成RTMP给直播平台或者转成WebRTC给网页播放。在安防项目和IoT场景里这个工具几乎是我必装的几行命令就能解决协议互通问题。Live555是另一个老牌RTSP实现。它不提供完整的产品级服务更多是作为RTSP协议栈存在很多公网摄像头和服务器的RTSP底层就是用的它。它的文档和代码风格比较“学院派”刚开始接触会觉得难啃但如果你想深入理解RTSP协议读它的代码确实非常有收获。nginx-rtmp-module是Nginx的一个模块把RTMP收流和HLS切片能力直接挂在Nginx上。它的优点是跟Nginx的配置体系完全打通静态文件服务和动态流服务混布非常方便。缺点是模块本身更新慢HLS切片功能稳定但性能上限不高。小规模的内部直播或者低并发测试环境用它很合适。4.3 更重型的服务端Red5Red5是一个基于Java的流媒体服务器支持RTMP等协议。Java技术栈的团队在集成Red5时会更顺手因为它可以嵌入企业已有的Java后端体系权限控制、业务逻辑都容易写。性能上Red5不如C实现的服务端但胜在开发和维护的门槛低团队如果对Java更熟悉Red5的效率反而更高。它在视频会议、在线教育这类对业务逻辑要求多的项目里还经常作为定制化开发的起点。5. 实时音视频链路与WebRTC生态5.1 WebRTC如何改写实时通信的格局WebRTC是目前实时音视频通信的事实标准它解决的是浏览器和移动端之间低延迟音视频互通的问题。这个项目最关键的贡献不是某一个编码器或协议而是把一整套实时通信链路采集、编码、传输、抖动缓冲、回声消除、网络自适应整合成了浏览器原生能力。过去做一套视频通话要自己搞定NAT穿透和码率自适应有了WebRTC之后这些基础问题直接被框架层解决掉了。但直接基于WebRTC做项目还有工程化的问题要处理。多人在线会议不能所有人都连在一起那样带宽和编码压力会爆炸所以通常要用SFU架构转发媒体流。这时候就要用到Janus-Gateway、MediaSoup这类开源网关。5.2 开源网关选型Janus-Gateway、MediaSoupJanus-Gateway是一个非常灵活的WebRTC媒体网关它把WebRTC服务和业务解耦得非常彻底核心只处理媒体流具体的业务逻辑通过插件机制实现。视频会议、直播、录制、VoIP网关心等都有对应插件。我在做教室互动项目时用过它Janus的录像插件和RTCP反馈能力很稳定文档例子也多。缺点是对初学者来说概念偏多上手曲线稍长。MediaSoup的定位更纯粹它就是一个SFU选择性转发单元专注把每路参与者的音视频流转发给需要的人。它的API我理解是“给懂WebRTC的人用的”你只要能自己状态机MediaSoup会把媒体层面的工作做得很干净。它的更新和社区活跃度都很高新版在带宽评估和音视频优先级方面做了大量优化。如果团队能力足够MediaSoup值得投资源去深入研究。5.3 周边套件Pion WebRTC和Jitsi MeetPion WebRTC是一个很有意思的Go语言实现。它让我印象最深的一点是在不依赖浏览器环境的情况下完整实现了WebRTC协议栈。用Go写实时音视频服务时Pion几乎是不二选择。我们用它做过网关服务和自定义的信令服务器好处是编译部署简单而且Go的并发模型处理媒体会话很适合。Jitsi Meet则是WebRTC生态里少见的开箱即用的产品级方案。它不只是网关还自带网页端、iOS和Android客户端、服务端部署脚本装好之后就是一个能跑的多人视频会议系统。它的优势在于系统完整拿来即用劣势也是完整的系统往往不好“动刀”。用它做私有化部署满足中小规模会议完全没问题团队可以先把业务跑起来以后再做深度定制。6. 音频处理与分析容易被忽略但极其关键6.1 SoX和Essentia命令行小钢炮和分析框架SoX在音频领域的地位相当于音频界的FFmpeg。合并音频、转换格式、调节音量、降噪、变速、提取频谱它都能在命令行里操作。我在批量处理音频素材时会先跑一个SoX命令看参数再决定用脚本批量还是手动处理。它有个好玩的地方是把一段音频的图表可视化打出来虽然简单但比盲听靠谱。Essentia是更接近研究用的开源音频分析库主要做特征提取。节拍、音高、和弦、频谱特征、响度、音色特征都有现成的算法。它支持实时分析和离线分析Python绑定也做得顺手。做语音情感分析、音乐推荐、声纹预处理这类方向值得直接拿它当底座。6.2 噪声抑制与回声消除RNNoise、SpeexDSP实时语音产品里用户投诉最多的问题往往不是编码质量而是回声和噪声。RNNoise是专门做噪声抑制的深度学习模型结合信号处理和神经网络做语音增强体积小、速度快CPU资源占用很友好。我曾在一个低性能嵌入式平台上跑过RNNoise延迟可以接受降噪效果对键盘声和风扇声抑制非常明显。SpeexDSP侧重的是回声消除、降噪、自动增益、丢包补偿这一整套音频前处理链路。它诞生于Speex编码器时代但编码器本身已经边缘化前处理模块却被广泛沿用至今被很多VoIP和会议系统集成。如果你做实时通话类App回声消除是绕不开的坎SpeexDSP的WebRTC AECM算法在常规场景下表现可以。6.3 端口音频抽象PortAudio和OBS StudioPortAudio不是一个面向用户的功能软件而是一个跨平台的音频输入输出库处理Windows、macOS、Linux、Android这些平台的音频设备访问差异。很多开源采集软件、音乐软件、语音工具底层就是靠它屏蔽平台差异。写过音频采集程序的人都清楚直接在Linux下操作ALSA会把人折磨疯PortAudio把这些底层细节全部封装掉了。OBS Studio我已经在前面提到它是开源视频采集和推流工具里无可争议的王者。它的本质是一个基于插件架构的实时音视频混合引擎核心是做视频场景切换但音频采集、降噪、压缩器、推流设置这些功能也都内置了。做直播和录屏产品时我通常会把OBS当作“参考实现”它的滤镜、场景切换、推流策略设计得很值得学习。7. 选型组合拳与实战排查经验7.1 常见场景的推荐组合把这些项目串起来用比单独看每一个更有价值。我做过的几种典型组合供你参考。直播开播场景OBS Studio推RTMP给SRSSRS负责接入需要转码就挂FFmpeg需要录制就开SRS的DVR功能播放端用VLC或者浏览器直接看HTTP-FLV或HLS。如果你想省掉SRS流量不大时也可以用nginx-rtmp-module直接收流。监控摄像接入场景摄像头RTSP裸流先用MediaMTX收进来转成RTMP或WebRTC给上层应用需要录像就用FFmpeg定时拉流存MP4也可以把ZLMediaKit当中间网关同时接多个摄像头再统一对外输出RTSP和WebRTC。会议室级联场景客户端走WebRTC信令服务器用Pion WebRTC来写媒体转发用Janus或MediaSoup。需要整体系统快速落地直接部署Jitsi Meet省去自己拼装的过程。离线转码场景大批量视频用HandBrake的队列需要精细控制参数就用FFmpeg命令归档编码建议x265需要最好的兼容性就H.264。7.2 代码仓库编译和依赖基础设施的坑编译这些问题虽然琐碎但几乎每个人都会碰到。第一次编FFmpeg建议只开最少的模块先过一遍不要一上来就全功能编译。我遇到过很多依赖缺失导致配置失败的情况大多是因为在configure阶段缺了libx264的开发包。编x265的时候这玩意比较吃硬件耐心点中途中断再继续也比重新开始强。x264和ffmpeg的版本匹配也有讲究先装好编码器库再编FFmpeg否则FFmpeg编译时识别不到外部库等于白白多了一次编译。另外还有一点容易被忽略ffmpeg的configure日志信息量很大关注enabled和disabled部分你以为开了一堆功能实际全被跳过后面用的时候才发现功能没有。我的习惯是编完之后立刻ffmpeg -version看一眼输出里有没有对应库的标注再拿一个真实文件跑一遍功能可用才算可以。7.3 延迟优化和兼容性的经验跑直播或者实时通信延迟永远是绕不开的问题。很多人一上来就想着换协议其实问题往往在别的环节。GOP设置太大会导致解码端无法快速出画面B帧使用不当会增加大量缓冲播放端的缓冲策略过于保守也会增加延迟。一般我会先把GOP调小到1到2秒关闭不必要的B帧播放端的缓冲设到100到300毫秒再逐层排查瓶颈。兼容性问题是另一个高频战场。同一个H.264流在不同硬件解码器上的表现可能相差很大。为此我通常会在上线前跑一个设备兼容矩阵覆盖高低端安卓机、iPhone老机型、不同浏览器内核。编码配置也要留余量比如分辨率不要卡着上限音频采样率用最常见的48000赫兹。再好的开源组件如果只在一种设备上表现好项目也走不远。8. 最后写点个人体会我发现做音视频项目久了最深的感触不是某个库有多强而是“串联”的能力比“单点”的能力更重要。FFmpeg、SRS、MediaSoup这些项目单个拿出来都是各自领域的好东西但真正的难点在于让它们在一个系统里磨合协议互相转换、时间戳一致、缓冲和延迟可接受。如果你刚开始接触这些项目我建议你别急着搭大系统。先拿一台机器装好FFmpeg用命令行把一个文件转码、抽帧、切片玩明白再装一个SRS或者MediaMTX把自己手机上录的视频推到服务器上播出来最后再用浏览器开一个WebRTC的Demo看看信令和数据通道是怎么走的。这三步跑通之后你对整个音视频开源生态的理解会完全不一样。另外有个细节想提醒细读项目文档永远比刷论坛帖子有效很多问题不是别人没遇到过而是你自己没看到文档里写的那句话。把文档当作第一信息来源把社区帖当作补充线索这个习惯会帮你节省大量时间。