我们每天打开YouTube看视频，用Netflix追剧，开Chrome浏览网页，甚至用Discord跟朋友语音。
这些动作背后，有一个共同的技术底座在默默运转。
它叫FFmpeg。
Lex Fridman最近请了两位重量级嘉宾来聊这个话题。
一位是Jean-Baptiste Kempf（简称JB），VLC播放器的灵魂人物，VideoLAN的主席。
另一位是Kieran Kunhya，FFmpeg的长期贡献者，也是FFmpeg那个以"辛辣"著称的Twitter账号背后的人。
这期播客聊了四个多小时，信息密度极高。我把最值得关注的部分整理出来。
VLC的传说是"什么都能播放"。
他们曾经搞过一个比赛：谁能做出最奇葩、最恶心的文件，看VLC能不能播。
有人做了一个MKV文件，每一帧的分辨率、宽高比、旋转角度都在变。
还有人做了一个视频，画面全是黑的，但每一帧上面叠了一层动画字幕。
VLC全都播出来了。
这背后的设计哲学：永远不要信任你的输入数据。
VLC最早是为了在校园网络上播放卫星电视信号而设计的，UDP传输丢包是家常便饭。
所以从第一天起，VLC就被设计成能处理"坏掉的文件"。
这也是为什么当年盗版横行的时代，下载到一半的AVI文件别的播放器全部崩溃，VLC却能硬着头皮播出来。
顺便说一句，VLC那个交通锥logo，25%的网站流量来自搜索"cone player"。
很多人根本不知道VLC叫什么名字，只知道"那个锥子播放器"。
问题看起来简单，答案却可以写好几本书。
第一步：获取数据流。
你给播放器一个地址（文件路径、URL、DVD），它给你一串字节。
第二步：解封装（Demuxing）。
把音频、视频、字幕从容器格式（MP4、MKV、AVI）里分离出来。
容器就是"文件格式"，但比你想的要微妙得多。
MP4文件里面装的不一定是H.264，可能是别的什么东西。
VLC和FFmpeg的做法是直接忽略文件扩展名，打开文件看里面到底是什么。
扩展名只是一个"提示"，不是真相。
第三步：解码。
这是最复杂的部分。
视频压缩比通常是100倍到1000倍。你没看错，1000倍。
一个4K视频的原始数据量大到难以想象，但压缩后能塞进你的网络带宽里流畅播放。
怎么做到的？
JB解释得很形象：
你看一部电影，镜头在移动，但背景的云可能好几秒都没变。
那我就不需要每一帧都重新存储那朵云，只要告诉解码器"这一帧的云跟上一帧一样"就行了。
黑色背景也是，左上角和右上角的像素值一样，我只存一次。
所有的视频压缩，本质上都是在利用人类感知的局限性。
我们不在RGB色彩空间里工作，而是转换到YUV空间，把亮度和色彩分开处理。
因为人眼对亮度的敏感度远高于色彩。
光是这一步，不做任何压缩，数据量就减半了，大多数人完全看不出区别。
然后是频域变换、量化、熵编码……每一个步骤都是某个人一辈子的研究成果。
Kieran说了一句让人印象深刻的话："我们刚才说的每一句话，都是某个人毕生的工作。每一句话都有专门的书在讲。"
第四步：渲染。
解码出来的原始图像交给显卡显示，原始音频交给声卡播放。
整个过程必须在16毫秒内完成一帧（60fps的情况下）, 没有商量余地。
错过一帧，视频就会出问题。
FFmpeg是一套底层库和工具，用来处理几乎所有已知的音视频格式。
编码、解码、转码、流媒体、滤镜，全都有。
它被用在哪里？
YouTube、Netflix、Chrome、Firefox、VLC、Discord、OBS……基本上你能想到的任何跟视频沾边的产品，底层大概率在用FFmpeg。
据估计，超过90%的视频处理流程都涉及FFmpeg。
Kieran说了一个很有意思的观点：你奶奶的家庭录像和万亿美元的公司，用的是同一套技术栈。
有些大公司的视频处理管线，就是一条三千个字符的FFmpeg命令行。
JB说FFmpeg的命令行本身就是一门语言。
你可以用它做出Adobe After Effects级别的效果，全在命令行里完成。
很多人已经在用AI来生成FFmpeg命令，因为参数实在太多了，没人能全记住。
FFmpeg和VLC的关系，Kieran用了一个很精准的类比：VLC之于FFmpeg，就像Android之于Linux。
它们互相依赖，互相成就。
VLC用FFmpeg做解码，FFmpeg因为VLC获得了大量真实世界的奇葩文件测试。
x264（H.264的开源编码器）是VideoLAN的项目，80%以上的FFmpeg编码管线都依赖它。
JB解释开源有一个绝妙的类比：
买蛋糕，你去面包店，他们给你蛋糕。
开源呢？我们不仅给你蛋糕，还给你配方，告诉你怎么造烤箱，而且你可以修改配方再卖给别人。
软件就是一个超长的配方，只不过不是十几步，而是几百亿条指令。
FFmpeg从诞生至今，大约有两三千人贡献过代码。
但核心维护者只有十到十五个人，VLC的核心团队只有五六个人。
一千个贡献者里，只有1%会留下来。
换工作、结婚、生孩子、生活变故……大多数人最终都会离开。
所以留下来的人必须维护所有人写过的代码。
这就是为什么代码质量标准必须极高。
JB说得很直接："我们不在乎你是谁。你可能是一条狗，我不在乎。我只看你的代码。"
有人说"我是某某大公司的工程师"，回答是"我们不在乎"。
代码质量是社区的唯一标准。
这件事在Reddit上已经成了传说。
JB确实多次拒绝了数千万美元的报价，来源是那些想在VLC里捆绑工具栏、改浏览器主页、投放广告的公司。
他的理由很简单：这样做不对。
"我需要每天晚上上床睡觉的时候，对自己做的事情感到满意。如果我把项目卖了，我就背叛了所有为VLC工作过的人。"
他补充说，如果Netflix来说"我们想把Netflix集成到VLC里"，故事可能不一样。
但来找他的都是那些灰色地带的广告公司，如果接受了，三年后项目就死了，有人会fork一个新的出来。
最后一次报价的金额，他用了"obscene"（下流）这个词来形容。
对方甚至说"你可以用这笔钱做新的开源项目"。
但他还是拒绝了。
这是最近Twitter上最大的一场开源社区drama。
Google用AI工具对FFmpeg进行安全扫描，发现了一些漏洞，然后按照行业标准给了90天的修复期限。
问题是：
这些漏洞是在一个1993年的游戏编解码器上发现的。 一个几乎没人用的东西。
Google在漏洞修复之前就向媒体宣传了他们AI工具的能力。
所有报告都被标记为"高优先级"。 一个像素颜色可能出错的整数溢出，被标成红色7.5严重度。
AI生成的bug报告又长又啰嗦，对志愿者来说几乎是一种"DDoS攻击"。
Kieran用了一个很好的类比：这就像有人用高科技工具撬开你家的门锁，然后告诉你"你的锁不安全"。
但那是你家的门锁，不是保护核机密的。
而且他们有资源来修这个锁，却选择不修，只是报告问题。
前FFmpeg开发者Alex Strange在Hacker News上的评论更加犀利："安全研究人员找到你代码里的bug，他们会给它起个可爱的名字，建个网站配个logo，Google给他们一百万美元奖金，他们去DEF CON领奖。没人会为修bug的你做任何这些事。"
不过这场drama也产生了正面效果。
Google开始提交修复补丁了，而且设立了修复问题的奖励机制。
FFmpeg的捐款也大幅增加，虽然仍然不够覆盖一个全职开发者的薪水。
另一个经典案例。
微软Teams的某个项目经理在FFmpeg的公开bug追踪器上报告了一个问题，还特意强调"这对微软很重要，很多人在用"。
FFmpeg礼貌地建议微软签一份长期维护的支持合同。
微软的回应是：一次性支付几千美元。
Kieran在Twitter上把这件事公开了。
他的观点是：这些万亿美元的公司把开源项目的公开bug追踪器当成了他们的供应商Jira。
他们以为FFmpeg是一个有SLA的供应商，完全不理解这是志愿者在维护的项目。
JB说这不是个别现象。
很多大公司内部有OSPO（开源项目办公室），但这些部门往往没有把开源社区的运作方式正确传达给内部团队。
这可能是整期播客最让人震撼的部分。
dav1d是VideoLAN的项目，一个AV1视频格式的解码器。它的代码构成是这样的：
79.9% 汇编语言
19.6% C语言
0.5% 其他
总共24万行手写汇编代码。
作为对比，FFmpeg里所有编解码器加起来的汇编代码是10万行。
为什么要手写汇编？
因为编译器生成的代码不够快。不是差一点点，是差一个数量级。
Kieran展示过一个例子：手写汇编比C语言快62倍。
不是62%，是62倍。
这个数字每次发到Twitter上都会引发一场论战。
有人说"现代编译器有自动向量化"，有人说"intrinsics就够了"。
但两年来，FFmpeg团队展示了几百个手写汇编胜出的例子，反对者还是不信。
dav1d甚至不遵守操作系统的函数调用约定。
他们自己定义了内部的调用约定，因为标准约定需要保存和恢复寄存器状态，这会增加CPU周期。
他们知道这些函数只会在自己的库内部被调用，所以可以跳过这些开销。
JB说："我从没听说过除了dav1d之外还有哪个项目这么做。"
这些汇编代码还要支持多种指令集架构：x86的SSE、AVX、AVX-512，ARM的NEON、SVE，还有RISC-V。
每种架构都是手写的，运行时检测CPU能力，设置对应的函数指针，然后开跑。
社区里有两个汇编大师特别值得一提。
Henrik Gramner对Intel x86汇编的了解程度，连Intel自己的工程师都说"你有Henrik，为什么还来问我们"。
Martin Storsjö主攻ARM汇编，他在手机上用虚拟键盘写汇编代码，同时看着孩子在操场上玩。
FFmpeg支持的很多编解码器，最初并没有公开的规范文档，它们是通过逆向工程实现的。
社区里有一个传 奇人物叫Kostya Shishkov，一个乌克兰人，当时住在德国。
JB说他是"接近天才级别"的存在。
他的世界观很简单：二进制文件就是规范文档。
不需要别的文档，给他一个二进制文件，他就能把整个编解码器逆向出来。
逆向工程的过程大致是这样的：
找到目标软件里负责解码的模块（可能藏在一个20MB的二进制文件里）。
想办法hook进去，让它解码一个样本文件，把原始YUV数据导出来，作为后续对比的基准。
打开反汇编器，一条一条指令地跟踪，凭直觉判断哪里是DCT变换，哪里是熵编码，哪里是运动补偿。
在很长一段时间里，你什么都看不到。因为解码器有很多步骤，在所有步骤都正确之前，输出就是一堆乱码。你完全在内存层面调试。
可能走了很长一段弯路才发现某个系数缓冲区的理解完全错了，然后推倒重来。
Kieran自己也做过逆向工程，他逆向了CineForm编解码器。
他说关键是找到一个"好的起点样本"。
他运气好，找到了一个动画样本，里面大量平坦色块，没有用到太复杂的编码工具，可以先从简单的部分入手，然后逐步扩展。
JB讲了一个更生动的故事。
GoToMeeting（早期的视频会议软件）的编解码器是VLC用户长期以来排名第一的功能请求。
JB悬赏之后，Kostya说"我来搞"。两个月后搞定了。
他写的代码里到处是笑话和JB名字的彩蛋，代码本身写得非常漂亮。
JB还提到2003年他在巴黎中央理工学院时，亲眼看到Jon Lech Johansen（破解DVD加密的传奇人物）演示如何在虚拟机里调试Windows来破解Apple的FairPlay DRM。
"那个场景对21岁的我来说，简直是震撼级别的。"
这不仅仅是技术炫技。
JB强调了一个关键点：GoToMeeting是一个Windows 32位的程序。
再过10年15年，你可能在Android上、在iPad上、在RISC-V架构的设备上，根本没法运行这个程序。
但那些会议录像还在。
如果没有人逆向这些编解码器，这些数据就永远被锁死了。
这就是为什么这类工作对人类文明有极其重要的价值。
x264是H.264标准的开源编码器实现，也是VideoLAN的项目。
它至今仍然是所有新编码器的参考基准。
AV1、AV2、VVC、HEVC，每一个新编码器发布时，第一件事就是跟x264比。
x264做对了两件关键的事情，而这两件事都来自业余爱好者社区（主要是看动漫的人）：
第一，心理视觉率失真优化
学术界和工业界在此之前20年都痴迷于一个数学指标叫PSNR（峰值信噪比）。
但PSNR高的画面看起来反而模糊，因为算法会把误差均匀分散到每个像素上，导致整体画面变糊。
x264的开发者们（尤其是Loren Merritt）直接用肉眼在自己的笔记本上看效果。
他们的标准不是数学指标，而是"在普通人的笔记本上看起来好不好"。
第二，自适应量化。
把更多的比特分配给简单区域（比如草地），减少复杂区域的比特预算。
听起来反直觉，但视觉效果好得多。
有一个经典的测试视频叫ParkJoy，是瑞典电视台用胶片拍摄的，画面里有人在公园跑步，背景有树木、水面、草地、复杂的光影。
这个样本至今仍然是编码器的终极考验。
Kieran提到，华纳兄弟的工程师Chris Henderson用x264做了《Fringe》（危机边缘）整套蓝光碟的编码。
在大公司里选择用一个免费开源工具，这是需要勇气的，但效果确实更好。
Kieran自己到现在还会买实体蓝光碟来看最喜欢的电影，因为画质确实比流媒体好。
FFmpeg有一套叫FATE（FFmpeg Automated Testing Environment）的测试系统。
因为FFmpeg要在无数种操作系统、编译器、CPU架构的组合上运行，测试矩阵大到离谱。
打开fate.ffmpeg.org，你能看到macOS的各种变体（iOS、tvOS）、不同版本的GCC、Clang、Visual Studio、Intel编译器、Apple Clang，跑在x86、ARM、PowerPC、RISC-V上的各种组合。
所有这些测试机器都是志愿者提供的。
有时候编译器本身会有bug，生成错误的机器码。
在视频领域，哪怕一个微小的输出错误都会因为帧间依赖关系而级联放大，导致明显的画面故障。
FATE就是用来捕捉这些问题的。
JB提到VLC最新版本仍然支持Windows XP到Windows 11，macOS 10.7到最新版，iOS 9到iOS 26，甚至还支持OS/2。
全世界可能只有10个OS/2用户，其中一个在维护VLC。
这个几个人的小团队支持的操作系统数量，比微软、Google、Apple任何一家都多。
这是整期播客里最沉重的话题之一。
JB收到过死亡威胁。
2009年或2010年，他决定不再为PowerPC架构维护VLC新版本（因为Apple已经转向Intel处理器）。
有人寄了一封信，里面装着白色粉末（模仿炭疽恐吓），附带一封充满辱骂的信。
"我当时很年轻。我就想，为什么？我做了什么？我妈吓坏了，我们不得不去报警。"
他说现在回头看，这件事反而锻炼了他。
但开源维护者的心理健康问题是真实存在的。
XZ事件就是一个典型案例。
一个人独自维护一个关键的压缩库，被攻击者用社会工程学手段持续骚扰，在深夜不断提问题来消耗他的精力，最终他精疲力竭，把提交权限交给了攻击者。
AI让这个问题更严重了。
curl的维护者Daniel Stenberg一直在反对"AI垃圾"，因为AI生成的低质量bug报告和补丁大量涌入，给维护者带来了巨大的额外负担。
JB现在维护着大量多媒体和非多媒体库，因为原来的维护者撑不住了。
WikiLeaks的Vault 7文件揭露，CIA制作了一个修改版的VLC，里面加了一个恶意DLL（psapi.dll），会在你看电影的时候扫描你的文档文件夹，加密后发送出去。
这招很聪明。
你看电影的时候不会碰电脑，风扇转起来你也觉得正常，因为"在播高清视频嘛"，但实际上后台在偷你的数据。
类似的事情也发生在中国黑客针对印度用户的攻击中。
他们没有修改VLC本身，而是用了VLC的一个合法签名DLL，配合一个假的vlc.exe来做恶意程序。
这导致VLC一度被印度政府封禁，JB不得不去印度打官司才解封。
有情报机构直接找JB，问能不能在VLC里装后门，两个不同的机构。
JB的回答（用他自己的话说，"远没有这么礼貌"）：如果我们不得不妥协我们的软件，我们会直接关掉整个项目。
VLC的编译过程堪称偏执级别：在从未连接过互联网的离线机器上编译，先编译编译器本身，双重签名，全程离线。
因为他们相信有国家级别的攻击者曾经试图往他们的服务器里注入假的二进制文件。
JB的新创业公司叫Kyber，做超低延迟视频传输。
目标是4毫秒的延迟（从摄像头捕获到屏幕显示），目前已经做到了7毫秒。
应用场景包括：远程操控无人机、机器人、自动驾驶车辆的远程接管、云游戏、AR/VR眼镜的视频串流，以及远程手术。
技术上的关键点：
使用基于UDP的QUIC协议，避免TCP和HTTP的队头阻塞问题
在同一个连接上同时传输多路视频、音频和控制指令（鼠标、键盘、手柄）
精确的时钟同步，补偿时钟漂移，确保多个摄像头和传感器的数据在时间上完全对齐
前向纠错（FEC），多传一点冗余数据，允许丢失部分数据包而不需要重传
JB说他们在CES上演示了一个3D打印的小车，从法国远程控制，延迟低到可以实时操作。
Kyber是开源的，采用AGPL加商业双许可模式。
小团队和爱好者可以免费使用（但必须开源自己的产品），大公司需要购买商业许可。
FFmpeg社区里有一个特别酷的群体：视频档案保存社区。
他们的核心关切是：一千年后，人类还能播放今天的视频吗？
他们推动开发了FFV1，一个无损视频编解码器。
无损意味着压缩后的数据可以100%还原原始数据，不丢失任何信息。
档案保存者对有损压缩非常警惕，因为压缩可能改变画面的细微之处，影响历史记录的准确性。
Kieran说了一个很有意思的观点：C语言就像拉丁语。
一千年后它可能不再是主流语言，但它足够接近数学逻辑，人们仍然能读懂它。
FFmpeg用C写成，这本身就是一种对未来的保障。
英国曾经有一个项目叫"新末日书"，把大量资料存在BBC微型计算机上。
不到20年，就没人有合适的软件来读取了。
现在全世界有大量的磁带录像正在降解，而能读取这些磁带的磁头数量已经不够了。
档案保存者不得不做出选择：保存哪些，丢弃哪些。
这是一个巨大的道德困境。
当被问到FFmpeg和VLC是否会存在100年时，两人都对FFmpeg投了肯定票。
JB给出了一个很有野心的定义：多媒体是对人类感官的数字化表示。
只要是有时间维度的、能被人感知的数据，都属于多媒体的范畴。
所以未来FFmpeg和VLC会扩展到：
3D音频和空间音频（VLC已经在做了）
点云和体积视频（用于VR/XR）
深度信息（RGB-D，用于机器人和3D重建）
触觉反馈（VLC已经有一个4D影院的触觉插件）
气味（如果有一天有了标准化的气味传感器和扩散器）
脑机接口数据（如果Neuralink之类的设备普及了）
JB开玩笑说，解封装器会多一个新的轨道类型叫"气味"。
Kieran接话说"就像音频有左右声道，你会有左鼻孔和右鼻孔声道"。
FFmpeg已经在火星上运行了。
火星2020探测器用FFmpeg来压缩图片。
所以从技术上说，FFmpeg已经是一个多行星开源库了。
JB有一句话让我印象很深：
"后悔是对大脑的一种税。从错误中学习，但不要后悔。因为你已经做了，除非你有时间机器，否则后悔只会消耗你的精力。"
整期播客听下来，最强烈的感受是：我们每天理所当然地使用着的东西，背后是一小群人用热爱和执着在支撑。 他们不追名逐利，不为万亿美元公司打工，却构建了整个数字世界的地基。
FFmpeg和VLC不只是软件，它们是一封写给未来的信。
一千年后，当人类试图读取我们这个时代留下的影像记录时，这些用C语言写成的代码——就像刻在石碑上的拉丁文——仍然会是打开那扇门的钥匙。