做音视频开发这几年，经常有人问我：项目上手最快的方式是什么？我的答案永远是同一个——去找几个经典的开源音视频项目，边用边读，别一上来就啃协议文档。市面上不缺开源项目，缺的是成体系的清单。今天我把这些年实际折腾过、也在生产环境里用过的36款开源音视频项目摊开来讲，覆盖播放器、编解码、流媒体服务、WebRTC、移动端SDK、录播工具和周边产品。不吹不黑，只讲选型逻辑和我的实操经验，帮你少走弯路。

这份清单不是让你全部装一遍，而是当成一张地图。你做客户端播放，有对应的一组项目；你做服务端分发，有另一组；你做算法研究，编解码器就是最好的教材。我会把框架、协议、许可证、常见坑都说到，一次性把音视频开源生态讲清。

1. 36款开源音视频项目速查与分类盘点

1.1 先建立一张音视频生态地图

音视频开发之所以劝退，是因为每个环节都藏着大量隐性知识。一条典型的链路是这样的：

采集端要处理摄像头、麦克风、屏幕捕获；编码端要理解H.264、H.265、AV1的参数差异；封装格式要分清MP4、FLV、TS、MKV；传输层又分RTMP、RTSP、HLS、WebRTC。这些并不是一条单链，而是一张网状结构图。绝大多数开源音视频项目都只是这张图上的一个节点，组合起来才是完整的工程能力。

所以我一直觉得，学音视频最忌“零散”。今天看一个播放器源码，明天读一个编码器的码率控制，很容易迷失。正确的姿势是先有地图，再点技能树。下面这份36款项目清单，就是按照地图上的不同节点来组织的：播放器、处理与转码、编解码器、流媒体与WebRTC、播放器SDK、录制与创作、音频工具、下载与字幕周边。

1.2 36款经典项目速查清单

分类	项目	一句话定位	协议/备注
播放器	VLC	老牌通用播放器，插件体系庞大	GPL-2.0
播放器	mpv	极简播放器，脚本能力强、GPU渲染	GPL-2.0+，可编译为LGPL模式
播放器	IINA	macOS原生播放器，颜值和交互一流	GPL-3.0
播放器	Kodi	家庭影院中心，电视盒子场景首选	GPL-2.0
处理/转码	FFmpeg	音视频处理“瑞士军刀”	LGPL/GPL-2.0可选
处理/转码	HandBrake	图形化批量转码工具	GPL-2.0
处理/转码	GStreamer	管道式多媒体框架	LGPL-2.1
编解码器	x264	H.264编码器的事实标准	GPL-2.0
编解码器	x265	HEVC/H.265编码器实现	GPL-2.0
编解码器	libvpx	Google开源VP8/VP9编解码	BSD-3-Clause
编解码器	AOM AV1	AV1参考编码器（libaom）	BSD-2-Clause
编解码器	dav1d	AV1高性能解码器	BSD-2-Clause
编解码器	rav1e	Rust编写的AV1编码器	BSD-2-Clause
编解码器	Opus	低延迟语音/音频编码标准	BSD-3-Clause
编解码器	FLAC	无损音频编码	BSD
编解码器	LAME	MP3权威编码器	LGPL-2.0
流媒体	SRS	易上手的流媒体服务器，支持RTMP/HLS/WebRTC	MIT
流媒体	ZLMediaKit	高性能流媒体服务框架，适合二次开发	MIT
流媒体	Nginx-RTMP	给Nginx扩展RTMP能力的经典模块	BSD-2-Clause
流媒体	MediaMTX	多协议流媒体网关，原名rtsp-simple-server	MIT
流媒体	Live555	RTSP/RTP标准实现，适合学习协议	LGPL
WebRTC	Janus	通用WebRTC网关，插件化架构	GPL-3.0
WebRTC	mediasoup	SFU架构WebRTC库，嵌入式集成友好	MIT
WebRTC	LiveKit	开箱即用的WebRTC会议服务	Apache-2.0
WebRTC	Pion	Go语言WebRTC实现	MIT
WebRTC	Jitsi Meet	完整的开源视频会议产品	Apache-2.0
播放器SDK	IJKPlayer	B站开源，基于FFmpeg的移动播放器	LGPL-2.1
播放器SDK	ExoPlayer	Android官方媒体播放库，Media3前身	Apache-2.0
录制/创作	OBS Studio	直播推流与录屏神器	GPL-2.0
音频工具	Audacity	桌面音频编辑工具	GPL-3.0
音频工具	SoX	音频处理命令行工具	GPL-2.0
音频工具	PortAudio	跨平台音频IO库	MIT
音频工具	libsndfile	音频文件读写库	LGPL-2.1
周边	yt-dlp	视频下载工具，yt的社区分支	Unlicense
周边	you-get	Python写的视频下载工具	MIT
周边	libass	ASS/SSA字幕渲染库	ISC

说一句题外话：FFmpeg自带一个ffplay播放器，我平时调试经常用，但它严格算FFmpeg命令行全家桶里的一个工具，不算独立项目，所以这份清单里没有单列。但它对学习解码播放路径价值极高，后面实操部分我会重点提。

1.3 选型主线：按你的角色去挑项目

清单列出来容易，真正难的是知道自己该从哪些项目下手。我的建议很简单，按角色主线来选。

如果你做客户端播放器，先玩FFmpeg和mpv，理解解码、渲染、同步这三件事；移动端调研再看ExoPlayer和IJKPlayer。如果你做服务端流媒体，把SRS当作第一站，跑通直播推流和HLS分发以后，再深入ZLMediaKit或WebRTC网关。如果你做编解码算法，x264是必读的码率控制教材，AOM AV1是新一代参考模型，Opus则是音频方向绕不开的经典。如果你做测试与质量保障，yt-dlp、you-get、OBS、FFmpeg这一套组合足够搞定大部分数据采集和验证工作。

一句话总结我的经验：先按角色选三五个项目反复用起来，再横向扩展，比一次性泛读36个项目有效得多。

2. 核心原理拆解：这些项目为什么能成为经典

2.1 FFmpeg：几乎所有音视频项目的底座

说FFmpeg是底座，一点不夸张。上面36个项目里，有一半直接或间接依赖FFmpeg，有些人可能都没意识到，自己的项目里已经通过某个库引用了它。

FFmpeg的核心不是那个命令行工具，而是它内部的几个库：libavformat负责封装格式解析和封装，比如MP4、FLV、TS都是它的活；libavcodec负责编解码，从H.264到AV1都有支持；libavfilter是滤镜系统，缩放、裁剪、字幕叠加、降噪都在这里面；libswscale做像素格式转换和图像缩放；libswresample做音频重采样和声道布局转换。很多播放器和服务器，本质上只是在FFmpeg外面套了一层自己的策略和UI。

所以不管你最终做哪一层，FFmpeg的API和源码都值得花时间。比如后期排查音画不同步时，真正要懂的是libavformat和libavcodec里关于时间戳的处理逻辑；直播延迟优化时，要理解它在推流端的缓冲策略。我的建议是不要只知道ffmpeg命令，至少要看懂avformat_open_input、avcodec_send_packet、avcodec_receive_frame这几个核心调用链，音视频项目的地基就打牢了。

2.2 播放器三杰：VLC、mpv、IINA的定位差异

播放器看起来简单，其实是一个“什么都要懂一点”的典型场景。VLC是老大哥，模块化架构做得非常透，插件系统庞大，网卡抓包、UDP推流、浏览器插件这些能力都有，适合普通用户“下载即用”。但它的代码体量很大，二次开发有一定门槛。

mpv则完全走另一个路线。它的核心哲学是极简加可脚本化，Lua和Python脚本、JSON IPC控制、基于OpenGL/Vulkan的GPU渲染，这些都让它成为开发者最爱。很多商业产品里嵌入的播放内核就是mpv，因为它薄、快、可控性强。需要留意的是mpv在编译时可以选GPL或LGPL模式，如果你想拿它做闭源商业集成，LGPL模式这个选项就很关键。

IINA是macOS专属的播放器，用Swift写的，契合macOS用户对交互体验的高要求。技术上它调用mpv内核，所以播放能力本身不弱。Kodi则是家庭影院的定位，10英尺界面，专门为电视和遥控器场景设计，插件生态丰富。一句话：普通使用选VLC，开发者嵌入选mpv，macOS用户看IINA，客厅电视场景上Kodi。

2.3 流媒体服务器：SRS、ZLMediaKit、MediaMTX、Nginx-RTMP怎么选

流媒体服务器是服务端音视频的核心。SRS是我个人最推荐新手入门的项目，配置简洁，文档友好，而且默认编译打开RTMP、HLS、WebRTC等常用能力，一条命令就能跑起来。它的代码是用C++写的，整体结构清晰，生产环境也有大量公司在用，属于那种“能上生产的学习项目”。

ZLMediaKit更像一个流媒体服务框架，如果你需要在自有服务里嵌入媒体能力，或者做嵌入式边缘网关，它比SRS更合适。它也支持RTSP、RTMP、HLS、WebRTC等协议，但定位偏底层，二次开发空间更大。MediaMTX则以协议转换见长，我从它还叫rtsp-simple-server时就开始用，摄像头RTSP流直接转成WebRTC或HLS输出非常方便，尤其适合做低延迟网页预览这类场景。

Nginx-RTMP是上一代经典，给Nginx加RTMP能力，部署简单，但项目维护不活跃，延迟也偏高，新项目我一般不建议再选它。选型逻辑很简单：快速演示和整体直播方案选SRS；要深度定制或做嵌入式选ZLMediaKit；摄像头接入和协议互通选MediaMTX。

2.4 WebRTC阵营：从Jitsi到LiveKit的四个层次

WebRTC本身不是某一个项目，而是一套协议和浏览器API。围绕它，开源社区分化出了四类不同层次的项目。

最底层的是Pion，它是Go语言对WebRTC协议的实现，适合你在自己的后端服务里嵌入WebRTC能力，比如把实时音视频接进IoT或机器人控制链路。往上一层是mediasoup，它是一个SFU（选择性转发单元）库，只给你核心的媒体转发逻辑，信令、UI、录制这些都得自己搭。再往上是Janus，它是一个通用WebRTC网关，插件化架构，可以用来做媒体录制、视频会议、IoT控制这类相对标准的服务，但配置和插件开发也要花时间。

最高层是LiveKit和Jitsi Meet。LiveKit把SFU、信令、Token管理、录制这些能力都打包好了，部署体验非常顺，尤其适合快速搭一个产品原型。Jitsi Meet则是一个成熟的开源视频会议产品，网页端从零部署就能开会，适合需要“开箱即用”的团队。我的建议是：如果你要产品级体验，起点选LiveKit或Jitsi Meet；如果你要自己掌控协议细节，再往下看mediasoup和Pion。

2.5 编解码器：H.264、HEVC、AV1的路线之争

编解码器是音视频领域最硬核的部分。H.264（AVC）凭借极佳的生态和硬件支持，至今是统治级的存在，x264作为它的开源编码器，几十年来一直是编码器质量和速度研究的标杆。HEVC（H.265）压缩率比H.264更高，但专利与授权问题复杂，x265是它的开源实现，也是目前很多高码率影视资源转码的选择。

VP9和AV1则来自开放媒体阵营。AV1的压缩效率比HEVC还要好，且设计初衷是降低专利授权负担，但编码复杂度也高，实时软编很难；dav1d作为解码器性能非常出色，已经成为很多网页端和播放器优先选择的AV1解码方案；rav1e则用Rust重写AV1编码器，给现代系统带来了更好的内存安全体验。音频方面，Opus已经是现代音视频通话和WebRTC的事实标准，低延迟和压缩率兼顾；FLAC是无损音乐存档的首选；LAME在MP3领域至今难以被替代。

真实选型时，不要迷信“最先进”。我在项目里通常这么判断：移动端和直播推流优先H.264，因为它兼容性最好；超高清点播再考虑HEVC或AV1；实时通话用VP8或VP9都行，音频无条件上Opus。编解码选型本质上是在压缩率、编码速度、硬件支持之间做权衡。

3. 手把手复现：编译与跑通几个关键项目

3.1 从源码编译FFmpeg：先踩过依赖坑再说

直接apt install装FFmpeg虽然方便，但我还是建议你至少亲手编译一次，因为很多音视频项目的坑都出在依赖上。这里以Ubuntu/Debian环境为例：

sudo apt update
sudo apt install -y build-essential pkg-config nasm yasm \
  libx264-dev libx265-dev libvpx-dev libmp3lame-dev libopus-dev

然后克隆源码编译：

git clone https://github.com/FFmpeg/FFmpeg.git
cd FFmpeg
./configure --prefix=$HOME/ffmpeg-build --enable-gpl \
  --enable-libx264 --enable-libx265 --enable-libvpx \
  --enable-libmp3lame --enable-libopus --disable-doc
make -j$(nproc)
make install
export PATH=$HOME/ffmpeg-build/bin:$PATH

这里有几个点值得说清楚。--enable-gpl是必须的，因为x264本身是GPL许可证，如果你不声明启用GPL，FFmpeg不会把x264编进去。--prefix指定安装目录，建议统一放一个自定义路径，避免污染系统目录。不要一上来就--enable-nonfree，那里面的库会有额外的分发限制，新手很容易踩这个坑。编译完成后验证一下：

ffmpeg -hide_banner -encoders | grep x264
ffmpeg -i input.mp4 -c:v libx264 -preset veryfast -crf 23 -c:a aac output.mp4

如果编码器列表里出现libx264，说明依赖和编译都成功了。平时调试我还会经常用ffmpeg自带的ffplay，比如ffplay input.mp4可以极快地预览一个文件，暂停后按方向键做逐帧分析，特别适合排查音画同步和编码异常。

3.2 用SRS搭建一条可用的直播链路

SRS是对初学者最友好的流媒体服务器之一。拉源码编译：

git clone https://github.com/ossrs/srs.git
cd srs/trunk
./configure --full && make -j$(nproc)
./objs/srs -c conf/srs.conf

默认配置下，SRS会同时监听1935端口（RTMP）和8080端口（HTTP/HLS）。这时用OBS做一个推流测试，添加“自定义流媒体服务器”：

• 服务器：rtmp://127.0.0.1:1935/live
• 流密钥：livestream

然后拉流验证：

ffplay rtmp://127.0.0.1:1935/live/livestream
ffplay http://127.0.0.1:8080/live/livestream.m3u8

第一次跑通这个链路时，你会直观感受到采集、编码、推送、服务端转封装、分发、播放这整条链路是怎么协作的。一个小技巧：如果你在本地测试时不想占用摄像头和麦克风，可以在OBS里添加“媒体源”，循环播放一个本地视频文件作为输入，这样测试过程中不会因为桌面采集导致性能抖动，也能更准确地观察延迟表现。

3.3 用LiveKit五分钟跑通WebRTC会议Demo

WebRTC项目往往部署复杂，但LiveKit把体验做得很好。先装服务端：

# 官方推荐直接下载release二进制
# 如果本机有Go环境，也可以用：
go install github.com/livekit/livekit-server@latest

开发模式下直接跑：

livekit-server --dev --bind 0.0.0.0

它会用内置的测试key在7880端口启动服务。接着需要生成一个开发Token，可以用官方CLI：

livekit-cli create-token --api-key devkey --api-secret secret \
  --identity user1 --room test

然后把官方前端示例跑起来，在浏览器里连ws://localhost:7880?token=...就能进入房间。我实际测试下来，LiveKit的干净之处在于信令、媒体传输和Token机制都是现成的，不用像原生WebRTC那样自己维护SDP交换和ICE状态机。如果你只是想研究WebRTC原理，Pion和mediasoup会更适合，但要做产品，LiveKit确实省事很多。

3.4 想改播放器？从IJKPlayer与ExoPlayer看集成思路

IJKPlayer是B站开源的移动播放器，本质上是在Android/iOS上封装了一层FFmpeg的播放链路。想学习播放器集成的同学可以这样跑一遍：

git clone https://github.com/bilibili/ijkplayer.git
cd ijkplayer
./init-android.sh
cd android
./compile-ffmpeg.sh clean
./compile-ffmpeg.sh armv7a

编译完成后用Android Studio打开android目录，就能看到完整工程。IJKPlayer最大的价值是，你可以在一个真实的移动端播放器里看到FFmpeg如何被调用、音视频轨道如何被解码和渲染。但它的维护频率确实不高，新项目如果追求长期稳定，我更推荐Google官方的ExoPlayer，现在它已经演进成Media3的一部分，API设计更新，社区也更活跃。读这类项目源码时，抓住三个模块就够了：播放器状态机、媒体源加载、渲染器同步。

4. 实战避坑：音视频项目最常见的拦路虎

4.1 延迟高：先判断瓶颈在传输还是播放

做直播或实时音视频，延迟永远是老问题。很多人在客户端看到延迟高，第一反应是调整播放器缓冲，其实不对。RTMP和HLS本身的延迟通常在3到10秒，HLS的切片机制决定了它很难做到低延迟；RTMP虽然理论上可以做到1到2秒，但播放器端默认缓冲策略往往会吃掉这部分优势。WebRTC则能把端到端延迟压到几百毫秒，适合连麦、远程控制这类强交互场景。

我的排查顺序是：先推流端抓帧看编码缓冲，再服务端看转封装是否引入额外切片等待，最后在播放端看缓存水位。建议逐节点测量，而不是凭感觉切参数。生产环境里，大规模直播用LL-HLS或CMAF，低延迟交互用WebRTC，这个基本是如今的主流方案。

4.2 音画不同步：从容器和时间戳下手

音画不同步是最容易被用户感知的问题。常见原因有两个：一是录制的源文件本身时间戳不连续，二是转码过程中没有保持好PTS/DTS的顺序。遇到问题时，先用ffplay播放原始文件，判断是源头问题还是转码问题：

ffprobe input.mp4 -show_streams | grep -E "codec_type|start_pts|time_base"

如果源文件就不同步，说明问题在采集或封装环节；如果源文件正常但转码后出问题，重点看音频重采样和滤镜是否改变了时间基。常见做法是在转码时明确指定输出帧率或采样率，避免容器自动推断产生偏差。经验口诀是：容器负责打包，时间戳负责排序，渲染负责对齐，排查时顺着这条链找。

4.3 编译依赖地狱：模块化与静态编译的解法

音视频项目依赖多，最容易出问题的是编解码器版本和构建顺序。我看到很多朋友在编译FFmpeg时一次性开启所有库，然后被各种错误淹没。正确做法是按需启用，使用pkg-config检查依赖版本：

pkg-config --modversion x264
pkg-config --cflags --libs libavcodec

还要注意，系统包版本可能太老，编译项目时尽量使用项目源码依赖或子模块。官方源码树里一般有对应的依赖说明，跟着走比凭经验乱装包稳得多。我的习惯是先在隔离环境里编译一次，确认依赖都齐了再进入正式构建，避免污染系统环境后越来越乱。

4.4 协议与版权：选型时容易被忽略的坑

开源音视频项目最常见的项目风险其实是许可证。GPL库如果被嵌入到闭源商业产品里，会带来合规义务；LGPL相对宽松但也要满足一些条件；MIT、BSD、Apache则友好得多。选型时不能只看功能，还要看协议是否与你的商业模式匹配。我的建议是，商业闭源项目优先选MIT/Apache/BSD类协议的项目；如果必须用GPL库，建议提前和法务确认合规方案。另外，使用yt-dlp、you-get这类下载工具时，要特别注意版权问题，只下载你有权下载的内容，用于学习测试没问题，切勿侵犯他人权益。

最后留一句我自己的实操体会。音视频项目最忌讳的是只收藏不动手。我见过不少人看了很多盘点文章，最后连FFmpeg都没装过，然后抱怨代码看不懂。其实不是代码难懂，是链路还没在脑子里跑过一遍。真正有效的路径是：先用最简单的直播推流闭环，把采集、编码、分发、播放完整跑一遍，再回头去看SRS或FFmpeg源码中对应的模块。你会发现那些曾经陌生的数据结构和回调函数，全都有了具体的解释。这36个项目不是让你一天看完的，而是一张地图，需要哪个方向，直接往上靠即可。