干音视频这行的人，应该都有过这种体验：需求从来不是按教科书来的。今天要做桌面播放器，明天给直播平台搭转码切片，后天又接到一个给海量视频批量生成字幕的任务。每个需求单独看都像新问题，但拆到最底层，你会发现所有人都在同一批开源音视频项目上做排列组合——FFmpeg负责解封装和解码，VLC、MPV负责播放渲染，OBS负责采集推流，SRS、MediaMTX负责服务端分发，Audacity、SoX负责音频处理，Whisper负责语音识别，一环扣一环。

所以前段时间我特意挤出一周时间，把这几年真正上手评估过、部署过、在生产环境里因为没提前评估而付出过代价的项目，按“经典”和“还能继续投入”两个标准筛了一遍，最后留下来刚好36款。这篇就把完整清单、分类逻辑、选型思路和踩坑经验一次说清楚。刚入行的新人可以把它当作地图，老手也可以对照着查漏补缺。

1. 为什么我花时间整理这36个音视频开源项目：先说痛点与判断标准

1.1 音视频工程是一条又长又碎的链路

很多第一次接触音视频开发的人，容易把一个项目想得很简单：“不过就是播放一个视频、转个码、推个流嘛。”真动手之后才发现，完整链路至少包括采集、编码、封装、传输、解封装、解码、渲染、后处理、分发九个大环节，每个环节背后还有格式、协议、编码标准这些细分问题。比如一个最简单的直播功能，就涉及摄像头或屏幕采集、H.264编码、RTMP或SRT推流、服务端转码、HLS切片、CDN分发、播放器拉流，中间任何一段掉链子，用户看到的就不是卡顿就是黑屏。

更麻烦的是，这些环节往往不是同一个团队、同一个技术栈负责的。做客户端的人要处理播放器，做服务端的人要处理流媒体服务器，做视频平台的还要管转码和存储。一个人如果不主动把音视频领域的开源项目建立成一张“网络”，而是等需求来了再去搜，很容易搜到一堆过时项目，或者被某个看起来很火但协议很坑的项目拖进泥潭。

1.2 我筛项目时看的五个硬指标

这次筛选并不是简单按名气排列，我给自己定了五个指标，每个项目都要过一遍：

• 维护状态：最近有没有正式Release，社区是不是还在回答Issue。一个两年没动静的项目除非是FFmpeg这种生态基石，否则我基本直接排除。
• 跨平台能力：虽然我工作中主要用桌面和服务器，但很多项目会落地到手机端、嵌入式或NAS上，跨平台决定了以后要不要换轮子。
• 开源协议：GPL、LGPL、MIT、Apache的约束差别很大，做商业产品的人必须一开始就看清，而不是等代码都写完了才发现不能闭源分发。
• 不可替代性：有的项目虽然技术老，但生态地位摆在那里根本绕不开；有的项目虽然有替代品，但社区、文档、周边工具差了不止一个量级。
• 组合能力：音视频项目很少单独使用，能否跟FFmpeg、VLC这些“核心件”良好协作，是我很看重的点。

这五个指标筛下来，上榜的36款不一定是所有开源音视频项目里最“炫”的，但一定是实际工程里最容易被用到、也最值得投入时间研究的。

2. 36款项目全景：一张表分七个方向看清全貌

为了避免一上来就陷入细节，我先按用途把这36个项目分成七个方向：编解码与引擎、播放器、直播与流媒体、视频剪辑、音频工具、封装与字幕、下载与AI。下面这张表就是全景速查，项目名后面的描述都尽量压成一句话，方便你按照自己的需求先锁定相关类别。

2.1 编解码与引擎（8个项目）

2.2 播放器（6个项目）

2.3 直播与流媒体（7个项目）

2.4 视频剪辑（5个项目）

2.5 音频工具（5个项目）

2.6 封装与字幕（3个项目）

2.7 下载与AI（2个项目）

这张表把36个全部列完了。实际使用时，我的经验是：普通用户重点装VLC、HandBrake、Audacity、Aegisub、MKVToolNix就基本够日常使用；开发者则要优先吃透FFmpeg、GStreamer、libmpv、OBS、SRS，这五个项目几乎是其他音视频项目的地基。

3. 编解码与多媒体引擎：FFmpeg 和它的伙伴们构成的地基

3.1 FFmpeg：不只是命令行工具，更是行业标准

可以这么说：你现在能接触到的绝大多数音视频软件，底层都在某个位置调用过FFmpeg。它提供了一整套完整的解决方案，包括libavcodec、libavformat、libavfilter、libswscale、libswresample等模块，分别负责编解码、封装解析、滤镜处理、图像缩放、重采样这些事。

很多人认识FFmpeg是从命令行开始的。最基础的转码是这么写的：

ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 -c:a aac output.mp4

-crf 23是H.264编码的质量控制参数，数值越小码率越高画质越好，23是一个兼顾画质和体积的常见起点。如果你只是想截图做封面：

ffmpeg -i input.mp4 -ss 00:01:00 -frames:v 1 thumbnail.png

FFmpeg更强大的地方在于滤镜链，比如先缩放分辨率再统一调节对比度亮度：

ffmpeg -i input.mp4 -vf "scale=1280:720,eq=contrast=1.1:brightness=0.05" -c:a copy output.mp4

做服务端转码和推流时，它又是另一副面孔：

ffmpeg -re -i input.mp4 -c copy -f flv rtmp://your-server/live/stream

-re表示按原速读取输入，避免推流时瞬间把数据全读出来。这条命令在本地直播测试里非常常用。

作为库嵌入时，FFmpeg的路径就更复杂一些：打开输入、找到流、初始化解码器、循环读取包、解码出帧、处理完再编码封装。这套流程几乎每个音视频工程师都要亲手走一遍。我的建议是，做工具优先用命令行，做产品优先用库，但都要注意编译配置：FFmpeg的构建方式决定它对外是LGPL还是GPL，这会直接影响商业软件的合规风险，后面第八章我会专门展开。

3.2 GStreamer：以“插件+管线”的方式思考音视频

和FFmpeg那种一把瑞士军刀式的设计不同，GStreamer的核心思路是“管线”。你可以把不同功能的元素像乐高一样拼接起来，元素之间通过Pad连接，多个元素组成Bin，一条完整的处理链路就是Pipeline。

用命令行工具gst-launch-1.0可以直观感受这种思维。播放一个视频只需要：

gst-launch-1.0 filesrc location=input.mp4 ! decodebin ! autovideosink

filesrc读取文件，decodebin自动选择并调用解码器，autovideosink自动选一个窗口把画面显示出来。箭头!就是元素之间的连接符。

GStreamer的优势在于它天生面向复杂实时链路：开发视频会议客户端、车载多媒体系统、嵌入式图形应用时，你可以把采集、前处理、编码、传输拆成一个个插件，运行期动态调整链路。它的语言绑定也比FFmpeg更友好，Python、Rust、C++都有成熟接口。

选型上我的判断是：如果你只需要一个独立的转码/处理流程，FFmpeg就够了；如果你要长期维护一个会不断演化、需要插入新处理模块的系统，GStreamer的管线模型会让你后期好过很多。它最大的坑是插件版本匹配问题，系统自带的插件和项目里单独编译的插件经常互相打架，后面我会再提到。

3.3 六款经典编解码器各自的正确打开方式

选编码器时不能只看压缩率，还要看兼容性成本。x264的H.264是全网兼容性最好的选项，几乎所有设备都能硬解，所以直播场景我基本固定用它。x265的HEVC压缩率确实好，适合点播平台做高清文件归档，但低码率下如果参数没调好，画面细节容易糊，而且老设备硬解支持不完整。

libvpx的VP9在Web生态里很吃香，大多数现代浏览器都能直接播放，自适应流媒体场景里常用它配合DASH。LAME现在主要受众是车载系统、老式MP3播放器这类只认MP3的地方。Opus则是实时通信的王牌，从延迟到音质全面领先，语音会议类应用基本闭眼选。FLAC没什么好争论的——你需要无损归档音乐就是它，没有之一。

还有一点提醒：软件编码和硬件编码的选择不是简单的“软编画质好、硬编速度快”。新代显卡的硬件编码器质量已经相当可以，但不同品牌、不同代显卡的编码效果差异很大。我的习惯是先跑一轮同码率对比实测，再决定生产链路里用哪套。

4. 播放器项目：从桌面到客厅的四种体验路线

4.1 VLC、MPV、MPlayer：三代播放器的技术基因与取舍

MPlayer是最早影响整个播放器生态的项目之一，很多后来的播放器都直接或间接继承了它的代码。它短小精悍，至今仍有维护，但渲染方式、脚本机制相对陈旧，现代开发我不太建议从它起步，了解历史时倒是很好的标本。

VLC的强项是“完整成品”。它的核心是模块化架构，内置了几乎所有常见格式的解码器，不用用户另装解码包，跨平台覆盖Windows、macOS、Linux、Android、iOS。它提供的libVLC库也可以嵌到你自己的应用里，适合需要“一个开箱即用的完整播放能力”的产品。缺点是对深度定制不太友好，UI体系偏传统。

MPV是从MPlayer和mplayer2重写出来的现代播放器。它保留了命令行和脚本化的灵魂，支持Lua、JavaScript脚本，GPU解码、色彩管理、画面增强这些现代特性都非常激进。很多新桌面播放器干脆就直接把MPV当内核，自己只写一个壳。通过libmpv接入你自己的应用，是目前最推荐的播放器嵌入路径。

如果让我给一个快速判断：要完整桌面播放器，直接用VLC；要在自己的App里嵌入播放窗口，优先libmpv；想研究现代播放器技术的底层实现，源码啃MPV。

4.2 Kodi、IINA、SMPlayer：不同场景下的播放器答案

Kodi是完全为客厅媒体中心设计的，核心交互是遥控器，不是鼠标键盘。它管理本地媒体库，自动刮削封面和简介，还有庞大的插件体系，既可以当家庭影音库的前端，也能搭配NAS组成一套完整的家庭影音系统。对普通用户来说，把Kodi装在电视盒上，再接一个移动硬盘，比折腾其他方案省心得多。

IINA是macOS用户的好选择。它基于MPV，但界面和交互完全按照macOS习惯来做，支持画中画、系统媒体快捷键、Touch Bar（还有相关设备）这些系统特性。如果你在Mac上工作，IINA基本是默认播放器的最优解。

SMPlayer的定位则更偏向“家庭默认播放器”。它的经典功能是记住每个文件的播放位置，下次打开自动续播；还集成了字幕在线搜索，对不懂技术但需要字幕的家人朋友非常友好。从开发角度，这几款播放器也能看出一个规律：播放器项目的差异化已经不在“能不能解码”，而在于“能不能管理媒体库、能不能脚本扩展、能不能贴合某个平台的操作习惯”。

5. 流媒体服务器：推流、转码、分发链路里的主力们

5.1 OBS Studio：一切直播和录屏的起点

OBS Studio是我见过的开源项目里完成度最高的之一。它把直播这个复杂动作拆成了清晰的层次：场景、源、滤镜和输出。你可以把不同的摄像头、窗口、图片作为“源”放进同一个场景，再给每个源挂滤镜做调色、裁剪或遮罩，最后统一推流或录制。它的虚拟摄像头功能也很有用，把OBS输出伪装成一个摄像头设备，任何软件都能直接调用。

对开发者来说，OBS最有价值的是可编程控制能力。通过内置的WebSocket接口，外部程序可以动态切换场景、调整源、控制推流开始与停止，这为自动化直播、远程控制播控台提供了很好的基础。很多演唱会现场、课程直播推流工具，底层都是OBS加一层自动化脚本。

一个比较容易被忽略的细节是编码器差异。同样写着NVENC，不同代显卡的硬件编码器能力差别很大；AMD和Intel的硬件编码器也各有特点。部署直播主机时，不要只看接口支持，要实际推一段快速运动的画面，看暗部是否大范围糊掉。

5.2 服务端四选择：SRS、MediaMTX、nginx-rtmp、ZLMediaKit

服务端选型是整个流媒体链路里最要花心思的，因为直播延迟、并发能力和协议支持都跟它直接相关。

SRS是目前很多直播团队从零起步的首选，它把RTMP收流、转HLS、HTTP-FLV输出、SRT弱网推拉流、WebRTC低延迟播放都整合在一起，配置量和复杂度也控制得比较好。如果产品定位是“面向大众用户的直播”，我基本会先用SRS把整条分发链路搭出来。

MediaMTX的优势是极轻量，单二进制文件就能跑，主要工作是做协议转换。比如把RTSP摄像头流转成RTMP或HLS，或者把WebRTC拉流接到RTSP源上。它在边缘节点、弱网嵌入设备上很吃得开。

nginx-rtmp是很多老项目的遗迹。它跟NGINX集成方便，配置也简单，适合快速验证和低并发场景。但真要面对动态转码、多种协议分发、高并发下线，就会觉得处处受限。今天的新项目我一般不会推荐它作为主力。

ZLMediaKit则更偏专业流媒体服务，特别在安防监控领域优势明显。它内置了RTSP/RTP的完整处理能力，对GB28181这类国标协议集成也成熟。做服务器端的高性能流媒体处理系统时，它比SRS更贴近C++底层开发者。

5.3 Jellyfin与Icecast：媒体库与音频广播的特殊角色

Jellyfin做的是“个人媒体服务器”：你把电影、剧集、音乐、照片放进NAS或一台服务器，它负责整理媒体库、刮削封面和简介，并在客户端播放时按需转码。它所有客户端都开源，服务端转码能力也够家庭使用。如果你想把家庭里的影音素材集中管理，Jellyfin是目前完整度最高的开源方案。

Icecast则是网络音频广播领域的老牌项目。它稳定、轻量、资源占用小，主要承担“把一个音频流同时广播给大量听众”的任务。社区电台、校园广播、音频直播这类场景，Icecast加一个IceS编码器就能跑得很稳。

6. 剪辑、调音、字幕与封装：后处理工具链一盘棋

6.1 五款开源剪辑工具的定位差异

开源剪辑工具的格局比较明朗：Shotcut的定位是快速粗剪，界面直观，时间线简单，适合给自媒体做快速编辑；OpenShot的上手门槛最低，但大型项目和复杂时间线稳定度一般，我建议只在小项目里用；Kdenlive是功能更完整的专业非线性剪辑器，多轨视频、音频曲线、关键帧、字幕轨道样样都有，访谈类、教学类、中长视频项目我会优先选它；Blender的视频序列编辑器虽然只是它众多功能的一部分，但如果你本来就用Blender做三维动画，顺手用VSE把成品拼出来，流程非常顺；Olive的设计理念很现代，目标直指专业级剪辑，但还没完全打磨到生产级稳定，我现在的态度是观望。

如果要从工程角度看，Shotcut基于MLT框架，Kdenlive大量使用FFmpeg的能力，两者都可以作为“如何把开源多媒体组件拼成一个完整产品”的学习案例。

6.2 音频五人组：Audacity、Ardour、LMMS、SoX、Sonic Visualiser

Audacity是音频处理的“日常主力”。录音、剪辑、降噪、格式转换、音量归一化这些基础操作它都做得顺手，插件生态也够用。我做播客节目或音频降噪时第一反应就是打开Audacity。

Ardour更偏向“录音工程和混音台”。它有完整的轨道路由、总线、混音器、自动化曲线，适合录制乐队现场、做多轨混音。它的学习曲线明显比Audacity陡，但需要的专业控制能力它都有。

LMMS是音乐创作方向，适合用MIDI和采样做电子音乐、Beat和旋律编排。它对专业DAW的场景做了大幅简化，但该有的钢琴卷帘、效果机架、混音器都不缺。

SoX是命令行里的音频瑞士军刀。批量把几百个WAV转成MP3、统一响度、降采样，一条脚本就能跑完：

for f in *.wav; do sox "$f" "normalized_${f}" norm -3 done

norm -3把峰值归一到-3dBFS，批量处理音频素材时特别常用。

Sonic Visualiser是音频分析工具，可以把波形、频谱图、音高曲线叠在一起观察。做语音研究、音频质量评估、或者排查音频故障时，它比Audacity的视图精细得多。

6.3 HandBrake、MKVToolNix、Aegisub：转码、封装、字幕三件套

这三者经常作为一个组合出现。Aegisub负责“做字幕”，它的强项是ASS格式，支持精确到毫秒的时间轴、特效标签、卡拉OK模式。MKVToolNix负责“封装”，它不重新编码，只是把视频流、音频流、字幕流重新打包成MKV，命令行用mkvmerge：

mkvmerge -o output.mkv video.mp4 subtitles.ass

HandBrake负责“出片”，把封装好的MKV转成目标格式，同时控制体积和画质：

HandBrakeCLI -i input.mkv -o output.mp4 --encoder x264 --quality 22

一个完整的工作流是：Aegisub校对时间轴并制作ASS字幕 → mkvmerge把原始视频和字幕混流成MKV → HandBrake根据分发平台要求压缩成MP4。需要提醒的是，ASS字幕里的字体如果没有嵌入，换到别的设备播放时会变成替换字体甚至乱码，所以最后转码前最好确认字体已经嵌入。MKVToolNix也支持字体附件，可以把选定的字体一起封装进MKV里。

7. 下载与AI识别：音视频工具的新增长点

7.1 yt-dlp：素材获取环节的实用工具

yt-dlp是最流行的开源视频下载工具，也是早期youtube-dl项目的活跃分支。它不只是“下载视频”，还能获取字幕、缩略图、元数据、章节信息，也支持通过--write-auto-subs自动抓取字幕。最常见的用法是选流合并：

yt-dlp -f "bestvideo+bestaudio" --merge-output-format mkv URL

这条命令会分别拉取最高画质视频和最高音质音频，再用FFmpeg把它们封装成MKV。它在很多自动化媒体采集任务里相当于“素材管道”，抓取之后接FFmpeg和Whisper就可以做后续处理。

需要特别强调边界：这个工具提供的是技术能力，使用时要遵守目标站点的服务条款和内容授权规则，个人信息、传播范围都要自己把好关。技术是中性工具，但使用场景必须合规。

7.2 Whisper：开源语音识别如何进入音视频流水线

Whisper是目前开源语音识别领域影响最大的方案之一。它支持多语言转写、翻译和时间戳输出，而且对语音的强项是直接生成带时间轴的文本，天然适合做视频字幕。

一条比较完整的AI字幕流水线可以这么搭：先从视频里抽出16kHz单声道音频：

ffmpeg -i video.mp4 -vn -ar 16000 -ac 1 audio.wav

然后交给Whisper转写并导出SRT字幕：

whisper audio.wav --language zh --task transcribe --output_format srt

拿到初步字幕后再用Aegisub校对断句、打轴和术语，比纯手工做字幕快很多。模型大小方面，tiny和base适合快速粗略转写，small和medium是速度和准确度的平衡点，large系列准确率最高但对显存和耗时要求也高。长视频建议先切成10-20分钟的片段，分批转写再合并，不然内存占用和失败重跑的成本都比较难控制。

8. 协议、依赖与兼容性：把36个项目放进实际工程前要看的门道

8.1 开源协议是第一个筛选器

很多人选型时只盯着“功能全不全、口碑好不好”，却把协议放在最后看，这是很危险的习惯。我见过不止一个项目，代码写到一半才发现核心库是GPL，做闭源商业分发时会引入额外的开源义务。

FFmpeg和MPV、VLC这些项目都带有GPL相关组件，实际是否触发GPL义务，跟你的编译参数、链接方式、是否修改源码都有关系。我的建议是：商业产品立项前一天先整理一张“依赖协议表”，把每个组件的协议、链接方式和潜在合规风险写清楚，后面能省去大量麻烦。

8.2 依赖地狱与版本编排心得

音视频项目最经典的坑就是“换一个FFmpeg版本，原本好好的代码编译不过了”。因为几乎所有的音视频工具链最终都会绕回FFmpeg、OpenSSL、ZLIB这些底层依赖，而FFmpeg在版本升级时经常调整API和ABI，旧的应用跟着升级往往要改一大片代码。

我自己的处理习惯是这样的：如果是做工具脚本，直接用官方发布的静态编译版，不用自己从零编译；如果需要在平台里集成，一定要把依赖版本锁死，并记录对应版本号；如果在CI里构建，把包含依赖的基础镜像固定下来，而不是每次都拉latest。因为一次“顺手升级FFmpeg导致整个转码服务崩溃”的教训，我现在对依赖升级的态度就是：没有明确的性能或功能诉求，不做无谓升级。

8.3 看似经典但接入要谨慎的项目

我列一份“谨慎清单”，主要是想提醒大家“经典”不等于“适合现在接入”。

• MPlayer：技术历史价值很大，但现代渲染和脚本生态明显不如MPV，新项目没必要走回头路。
• nginx-rtmp：存量部署非常多，但功能边界很浅，遇到WebRTC低延迟、多协议分发就力不从心。新项目优先考虑SRS或MediaMTX。
• Olive：虽然理念很新，但项目成熟度还不足以支撑重负载生产项目，可以先跟踪学习，不要贸然作为主力剪辑工具。
• HandBrake的某些老旧预设：新版本里很多预设已经过时，建议直接自己给参数而不是迷信预设。

筛选任何一个开源项目时，可以先看最近一次Release时间、提交频率、对主流平台的CI结果，以及Issue区是不是一堆“长时间无人回复”的积压问题。音视频领域尤其怕停更项目，因为编码标准、硬件平台、系统API都在变，停更意味着早晚会被生态甩开。

最后分享一点整理过程中的真实体会：这36个项目，一开始我以为最花时间的是“列出项目名”，真正展开之后才发现，对比协议、API边界、维护状态和相互组合方式才是最耗精力的部分。而最有价值的产出，并不是那张表格本身，而是把项目串成流水线的能力——FFmpeg配SRS做直播分发，OBS配合ZLMediaKit做监控接入，Whisper配Aegisub做AI字幕，每一条链路都是几个开源项目协作的产物。所以我的建议是：别把这36个当作孤立的工具清单，把它当成一套可以拼装的零件库。下次遇到音视频需求，先别急着从零造轮子，翻翻这里面哪几个能组合出最优解，大概率最难的坑已经有人替你填平了。