# FFmpeg：互联网视频背后的惊人技术 > FFmpeg 如何支撑互联网上的视频编码、转码与播放，以及这套开源工具背后的工程哲学。 - 原标题：#496 – FFmpeg: The Incredible Technology Behind Video on the Internet - 期数：第 496 期 - 发布日期：2026-05-06 - 嘉宾 / 主题：FFmpeg 与视频技术 - 网页版：https://lexfridman-cn.pages.dev/ep/ffmpeg/ - 官方页面：https://lexfridman.com/ffmpeg/ - 精读字数：约 18962 字（阅读约 42 分钟） > 本文为 lex.qiaomu.ai 基于原始访谈的 AI 改写中文精读，非官方翻译；引用请注明出处并链接网页版。 dav1d 的代码仓库里，手写汇编有 24 万行，C 只有 3 万行。整个 FFmpeg 里所有编解码器加在一起，汇编是 10 万行。一个解码器的手写汇编量，是整个 FFmpeg 的两倍多。 这个解码器解的是 AV1。Netflix 上 30% 的视频、YouTube 上 50% 的视频，现在都是 AV1 编码。地球上大概有 30 亿台设备在不停地解它，而其中相当一部分设备没有硬件解码器，只能靠这几百 KB 的软件代码一个像素一个像素地算。 dav1d 是 VideoLAN 的项目，同一个组织还维护着 VLC。VLC 被下载了至少 65 亿次，核心维护者五到八个人。 这是 Lex Fridman 第 496 期播客的开场区域。两位嘉宾：Jean-Baptiste Kempf（圈内叫 JB），VideoLAN 主席，VLC 的主要维护者；Kieran Kunhya，资深编解码器工程师，FFmpeg 长期贡献者，运营着那个说话很冲的 @FFmpeg 推特账号，自己也开了一家公司叫 Open Broadcast Systems，做体育赛事直播的编码设备。整期节目里 Lex 头上一直戴着一顶 VLC 的交通锥帽子。 ## 按下播放键之后，发生了一连串没人看见的事 Kieran 把这套流程拆成了几层。第一层是从一个地址拿到字节流，URL、文件路径、DVD 都算。第二层是解复用，也就是容器层，把混在一起的数据切成视频帧、音频帧、字幕轨。第三层是解析每一帧的头部信息，判断这个编码能不能交给 GPU 硬解。Kieran 给了一个数字：大约 45% 的文件无法用 GPU 解码，必须走软件路径。 软件路径里最底层的一步叫熵解码，把比特流里的数学编码（霍夫曼编码、算术编码）拆开。然后是帧内预测，也就是 I 帧，在空间域里做，根据周围已经解出来的像素猜当前块长什么样。猜得不可能完全准，剩下的差值叫残差，残差存在频域里，量化之后做逆变换拉回空间域，叠加上去。 JB 补了一个容易被忽略的量级：音频从原始数据到 MP3 是 10 倍压缩，视频要到 100 倍、200 倍，目标是 1000 倍。 压缩到这个程度，靠的是信息本身有冗余。Kieran 说任何视频都有大量空间和时间上的冗余，编码器的工作就是把这些冗余去掉。JB 举的例子很朴素：镜头摇过去，背景那朵云一分钟没变，那就不用每帧都传一遍同样的像素；背景是全黑的，那就告诉解码器“这块跟左上角那个像素一样”，省掉整片数据。理论上可以无限往前引用，实际上被内存和算力卡死，比如在 4K 分辨率下比较两百帧之前的像素，计算量大到不现实。 > 压缩不是 ZIP。ZIP 是数据进、数据出，你要逼近的是无损的极限。这里我们在主动降质，而且必须用最聪明的方式降质。（Jean-Baptiste Kempf） 视频编解码器不负责保存真相，它负责骗人的眼睛。所以它不去碰 RGB，而是转到 YUV：一个亮度通道，两个色度通道。人眼里的视锥细胞和视杆细胞分工不同，对亮度的敏感度远高于对色彩细节的敏感度。于是色度分辨率直接砍一半，文件小一半，绝大多数人看不出来。 同理，所有现代编解码器都在频域里工作，用离散余弦变换把画面切成块，这就是为什么解码出错的时候你会看到一块一块的方格。 ## 容器和编解码器：VLC 从来不信文件后缀 Lex 问了一个很多人搞混的问题：把 MP4 和 H.264 混为一谈，算不算大错。JB 的回答是行业自己把水搅浑了。H.264 的正式名字是 MPEG-4 Part 10，而 MPEG-4 本身是个元规范，里面有 Part 2（早期的 MPEG-4 视频），有 AAC 音频，有好几种视频编解码器。所以你既可以说它是 MP4 的一部分，又不是。 Kieran 补了一句更实用的：现实中 99% 的 MP4 就是 H.264 加 AAC，其余是边缘情况。 真正有意思的是 VLC 和 FFmpeg 怎么处理文件后缀。它们不信任后缀。后缀只是一个提示，用来提高某个解复用模块的优先级。打开文件之后，程序会读文件内容本身判断这是什么格式。 > 我们不信任输入。VLC 最早的形态是给一个叫 VideoLAN 的流媒体方案做客户端，那时候视频走 UDP 在网络上传输，包会丢、会坏。所以整个架构从第一天起就是为“文件是坏的”这个前提设计的。（Jean-Baptiste Kempf） 这个设计选择后来变成了 VLC 的招牌能力。早年大家下盗版 AVI 的时候，元数据在文件末尾，下载到一半根本读不到，别的播放器直接罢工，VLC 说“这文件是坏的，但我还是试着解释一下”。 VideoLAN 年会上他们还办过一个比赛，看谁能做出最诡异、最糟糕的文件。有人做了一个 MKV，每一帧的分辨率、宽高比、旋转角度都不一样。还有人做了个“视频”，每一帧都是黑帧，全靠叠加在上面的逐帧动画字幕（SSA 格式）撑起整段内容。都放出来了。 Lex 提到有个文件同时是合法的 ZIP 和合法的 MP3。JB 说这种蠢文件比赛办过好几届。 ## 那个橙色交通锥，和一万封反对邮件 VLC 官网 25% 的流量来自搜索“cone player”。JB 说很多人不知道 VLC 这个名字，他们只认那个锥子。他去印度或者中国的偏远地方，人们认得那个锥。 有一年愚人节他们开玩笑说要换 logo，改成某种毛毛虫造型，收到大约一万封邮件说不行。 JB 对这事的分析挺有意思：你要做一个视频播放器，自然的想法是在电视上放一个播放按钮，那就是 YouTube 的 logo，毫无原创性。锥子是橙色的，很刺眼，很怪。怪到能变成梗，梗能变成文化，文化能撑二十年。 ## 开源是一份社会契约，也是一场长达十四年的追人游戏 JB 用巧克力芝士蛋糕解释开源：闭源软件是面包店给你成品，开源是给你成品、给你配方、告诉你怎么造烤箱，还告诉你允许你怎么改配方、能不能转卖。 FFmpeg 从诞生到现在，累计有两三千人贡献过代码。这个数字听着很美，Kieran 和 JB 反复强调的却是另一头：能留下来的核心维护者，FFmpeg 十到十五人，VLC 五到八人。 > 时间线上有一千个贡献者，最后留下来的就十个。也就是说，一个人来了并且留下来的概率是 1%。人会换工作、结婚、生孩子、出事故。你大概率不会回来。所以将来维护你代码的人是我们，你的代码必须可维护，必须优秀。（Jean-Baptiste Kempf） 这段话解释了那个社区为什么说话那么难听。它不是傲慢，是容量约束下的必然结果。 后面 JB 讲了自己主导的一次重授权，把 LibVLC 的核心从 GPL 改成 LGPL，理由有两个：一是让第三方应用能内嵌 VLC 引擎而不必开源整个产品（这是他能围绕 VLC 开咨询公司的前提），二是苹果 App Store 的条款让 GPL 应用几乎无法上架，LGPL 容易得多。iOS 和 tvOS 版本最后用的是 MPL。 改授权在法律上意味着要找到每一个贡献过代码的人，拿到同意。因为开源项目在美国版权法下是“共同作品”，版权分散在每个个体手里，而且即使后来那段代码被删掉了，只要新代码是基于它改的，版权主张依然成立。 他联系了三百五十多人。 > 我跑到某个人工作的地方去找他，因为他儿子写了那段代码，而他儿子已经去世了。我要向他解释开源是什么意思，解释我不是一家想白拿那五行代码的公司，解释整个社区都同意这件事。他完全不知道我是谁。那年我比现在年轻十四岁，几乎要哭了。这不是代码问题，这是人的生活。（Jean-Baptiste Kempf） Kieran 补了一句这个社区到底有多分散：有人在叙利亚战区，电力只有一部分时间；有人富，有人穷，有人老，有人少。能让这么一群人达成一致，本身就是成就。 JB 对“我们不在乎你是谁”这句话的解释，是整期里最能说明开源文化的一段： > 重要的是你的代码好不好。我们关心优秀的代码。我们不在乎你是谁，也许你是条狗，我也不在乎。我不在乎你从哪来，我要看你的代码。有人发来补丁被拒了，很不高兴，说“我可是意大利、德国、美国某大公司的工程师”。我们不在乎。我们在乎你代码的质量，因为这定义了我们的社区。（Jean-Baptiste Kempf） ## 那些拒绝掉的钱，和那封夹着粉末的信 Reddit 上有个流传很广的梗图，说 JB 拒绝了数千万美元，只为让 VLC 保持无广告。他自己确认了：是真的，而且不止一次。 找上门的都是些什么生意？捆绑工具栏（本质是间谍软件）、改浏览器主页、改默认搜索引擎、在 VLC 里塞广告。JB 说他不是反对赚钱，他自己开过好几家公司，现在还在开。他反对的是用不诚实的方式赚钱。 > 如果当时 Netflix 来找我们说想把 Netflix 放进 VLC 里，故事可能会不一样。但没有人来。来找我们的只有那些见不得光的广告公司。（Jean-Baptiste Kempf） 他给的理由很个人化：得能睡得着觉，得为自己做的事感到骄傲，如果卖了自己就背叛了所有一起干活的人。最后一笔报价被他自己形容为“下流”，对方的游说词是“有了这笔钱你可以去做新的开源项目”。他说那个心理陷阱很难躲。 Kieran 补充了时代背景：2000 年代，下载一个程序然后它偷偷装间谍软件是常态，那些条款埋在许可协议最底下的小字里，没人读。 然后是那段最沉重的。2009 或 2010 年，JB 决定不再为 PowerPC 架构维护 VLC 的新版本。当时团队四个人，VLC 1.0 即将发布。他收到一封信，里面有粉末，信里写着“你这个垃圾，你该去死，PowerPC 万岁”。那个年代正好有炭疽信件事件，他母亲吓坏了，他们去报了警。粉末是面粉。 > 现在回头看，我挺高兴这事发生在那个时候。它把我练出来了。我能承受很多恶意，我没问题。（Jean-Baptiste Kempf） Lex 接着说了句很真诚的话：他这辈子可能有几千次因为 FFmpeg 而露出笑容，但一次都没机会说谢谢，直到发现有这么个推特账号。 ## 24 万行手写汇编：为什么编译器赢不了 Kieran 解释 SIMD 的方式很朴素。标量汇编是“我有数字 10，加 5，得到 15”，一条指令一个数。SIMD 是单指令多数据，你有一整个向量，16 个不同的数，一条指令把 5 加到全部 16 个上。视频天然就是像素网格，所以这个模型契合得惊人。 FFmpeg 的做法是不用任何上层抽象，直接写汇编，寄存器自己分配。世界上的另一条路是用 intrinsics，那是长得像函数、行为接近汇编但不完全一样的东西，寄存器由编译器分配。 差距有多大？Kieran 给的数字是 10 倍到 50 倍。他发过推特，某个函数的提升是 62 倍。 这就引出了持续两年的推特骂战。软件工程界的直觉是：编译器在进步，自动向量化越来越强，你手写汇编迟早会被超越。@FFmpeg 账号这两年一直在发反例，几百个。 > 他们会说“你可以优化你的编译器”“自动向量化是你没搞懂”。我们试过了，试了很久。差距不是 5%、10%，是好几倍。（Jean-Baptiste Kempf） JB 从更宏观的角度解释为什么这件事现在更重要：摩尔定律到顶了，硬件不会再有过去那种代际跃迁，但我们对算力的需求在爆炸。大家的应对是堆核，堆到 250 核。而另一种应对是把每一寸机器都榨干。 榨到什么程度？Kieran 说他们会用跟用途完全无关的指令，比如拿密码学指令去做视频处理。dav1d 更进一步，它不遵守操作系统的函数调用约定。 调用约定这件事值得展开。你写一个函数调用另一个函数，数据怎么传、寄存器怎么保存，是有行业标准的，x86 上至少有四套（Linux 32 位、Windows 32 位、Windows 64 位、Linux 64 位）。早年 Loren Merritt 写了一个很轻的抽象层叫 x86inc，让你写一遍汇编就能适配四套约定，这是巨大进步。dav1d 反过来了：既然调用都发生在自己这个二进制内部，那就自己定一套约定，不保存那些用不上的寄存器，省掉 L1/L2 上的反复读写。 JB 强调这就是为什么必须懂计算机体系结构：流水线、SIMD、ALU、I/O。他见过社区里的人为一条汇编指令该用哪条争论半天，因为在这代 CPU 上是三个周期，在另一代上不是，而这个差别对最终输出影响巨大。 Kieran 用了一个比喻形容手写汇编的美感：像开一架喷火战斗机，操纵杆通过钢缆物理连着副翼，中间没有任何东西，你和处理器之间也没有任何东西。 他点名了两个他心目中的神。Henrik Gramner，住在瑞典，对 Intel x86 汇编和每一代 CPU 上每条 SIMD 指令的周期数熟到 Intel 自己的人都说“你们问我们干什么，你们有 Henrik”。Martin Storsjö，住在芬兰，主攻 Arm 的 NEON，他的编码方式是在手机上用虚拟键盘敲汇编，一边看孩子在游乐场玩。 ## 三个人、24 万行，和“每个周期都重要” dav1d 立项的时候，Alliance for Open Media 那边的普遍看法是：AV1 太复杂了，必须靠硬件解码。JB 和 Ronald、Henrik、Martin 几个人决定做一个极强的软件解码器，理由是硬件普及需要时间。 结果是 3 万行 C，24 万行手写汇编。项目口号是 every cycle matters。 效果是：一到两个核就能正确解 720p。JB 说这话的时候语气里带着明显的自豪，因为这意味着大量没有 AV1 硬解的老设备也能看 AV1 视频。 Kieran 发过一条推特，列了 dav1d 的代码构成：79.9% 汇编，19.6% C，0.5% 其他。他的配文是“这就是巅峰视频编解码器该有的样子”。下面吵了两年。 Lex 问如果有个工程师坐在家里听这期节目，C++ 写了十几年，后来转 Python，现在天天用自然语言让 AI 写代码，他该从这个故事里拿走什么。 JB 的回答指向 LLM 量化：为什么有人要做 FP8、FP4，甚至微软 Phi 做到 1.5 bit，因为被内存和算力卡死。实时场景里你没法总靠换更好的硬件，只能分析代码，找出那些被调用亿万次的热点。dav1d 一天要跑几十亿小时，值得为它手写 24 万行汇编；FFmpeg 的命令行胶水层不值得。 > AI 会帮我们写业务代码，这是好事。但真正没法被“氛围编程”替代的，是为硬件做的极致优化。（Jean-Baptiste Kempf） Kieran 补充了另一面：大多数公司会觉得“C 已经够快了”，而在他的公司里，同一段 10 bit 视频格式转换，手写汇编比 C 快 62 倍。10 bit 数据在 CPU 上没法原生处理，得塞进 16 位，浪费 6 位，于是有一堆打包格式；他的公司内部有一个 5×5 到 6×6 的矩阵，把每一种格式转到其他每一种格式，全部手写汇编，每个还支持不同代 CPU。 JB 引用了 Kieran 的话并称其为艺术：这是全世界唯一一个跑在几十亿设备上、还在这么干的代码库。高频交易也重视指令级优化，但那是跑在专用硬件上的极小众场景。 ## AI 生成的漏洞报告，和一辆 1993 年的赛车 推特上那场风波的核心事实是这样的：Google 开始用 AI 对 FFmpeg 批量生成安全报告，用标准的 90 天披露期限，而这个期限的设计前提是有一个拿工资的团队在处理。FFmpeg 这边是志愿者。 Kieran 用了一个比喻：你家的门锁是为了防住它该防的东西，不是为了防核武库。AI 现在用规模化的方式去撬锁，撬开之后告诉你“你的锁不安全”，而真正有资源修锁的正是撬锁的人。 > 那些报告非常啰嗦，AI 生成的漏洞报告在冷门编解码器上几乎构成了一种拒绝服务攻击。而且所有东西都被标成高危。（Kieran Kunhya） 他举了个更荒诞的例子：另一次所谓的漏洞，是一个滤镜里整数溢出，后果是某个像素颜色错了，标了 7.5 分高危红色警告。 JB 从另一个角度切入：发现漏洞的资源和修补漏洞的资源严重不对称。风波之后 Google 做了调整，开始直接发补丁，也设立了修复奖励。 然后是微软那条。Teams 有人在 FFmpeg 的公开 bug tracker 上写“这个问题是高优先级”，理由是 Teams 有大量用户。JB 说他想谈一个长期支持合同，对方给了一次性几千美元。 > 他们以为开源项目是传统供应商，以为公开的 bug tracker 是第三方供应商的 Jira。它不是。大公司里其实有 OSPO，开源项目办公室，本来就该负责跟开源社区对接，但他们经常没把这件事在公司内部讲清楚。（Jean-Baptiste Kempf） 结果呢？Kieran 说捐款显著增加，但仍然不够覆盖一个全职开发者。不过在认知层面和技术层面，这两年的效果是实打实的，很多人第一次意识到 FFmpeg 有多重要。 JB 讲了另一条路径：VLC 在 Android 上有一年多没法更新，因为 Play Store 的一个 bug。最后让 Google 有人回应的方式，是发一条语气很辣的推特说“我们准备停止在 Android 上分发 VLC”，涉及一亿用户。Windows Store 上也是同一招。 > 不幸的是我们太小了，唯一有效的力量就是在社交网络上喊话，因为它会滚雪球，然后他们才听。（Jean-Baptiste Kempf） 他补了一个具体的委屈：VLC 大概是 Windows 上使用量前十的软件，但他不在微软的 ISV 项目里，没有对接人。Adobe、Spotify 都有，他没有。 Kieran 把整件事定性成说唱对决。隔着屏幕互相放狠话，不代表真有私人恩怨。他说 Theo（OpenBSD 的 Theo de Raadt）那一段确实过界了一点，JB 后来打了电话把火压下去。 > 我们说了些什么，但我们留着没删。X 是一个完美的国际说唱擂台。你说我妈怎样，不代表我真对你妈有意见。这是 WWE，大家玩得开心，不必当真。（Kieran Kunhya） 一个 16 岁的贡献者叫 Ruikai Peng。他在 git 里发现并修好了一个问题，三天搞定，没有搞 CVE 编号、没有建带 logo 的网站、没有在 DEF CON 上领奖，就是修了。Kieran 的评论是“孩子们都挺好的”。 对比的是前 FFmpeg 开发者那条被广泛转发的帖子：安全研究者发现你代码里的 bug，会给它起个可爱的名字，建个带 logo 的网站，Google 给他们百万赏金，他们去 DEF CON 领奖，然后去某个大家都穿得像《黑客帝国》的秘密派对。你修好之后，没人给你任何东西。 ## Rust 能取代汇编吗 Lex 直接问了。两个人的意见确实不一样。 Kieran 认为内存安全这个方向有价值，但整体气质有问题，他用了两个比喻：世界语和 Sinclair C5。后者是 Sinclair 电脑创始人做的那辆电动三轮车，当年的宣传是“所有人都会开着这个上班”。Kieran 说 Rust 给他的感觉就是这样：社区有一种自我重要感，仿佛宣布了内存安全这个目标就等于解决了问题。他承认有人在用 Rust 重写一些基础工具，但“如果只做到所需功能的 85% 到 90%，剩下那 1% 要花 99% 的时间”。他用马斯克那句话收尾：原型都是简单的。要让真的电动车上路，你得做得跟现有产品一样好或者更好，而 Rust 还没到这个阶段。 JB 的态度更具体，因为他两边都干过。他在 VLC 里加过 Rust 模块，现在的新公司 Kyber 主要就是用 Rust 写的。 > Rust 是一个更好的 C++，它在乎内存，能做出别的语言目前做不到的所有权管理。它在从零开始的新项目里很棒，涉及解析文件、网络这些场景时那个内存检查和边界检查非常好用。但它跟已有代码互操作很糟。（Jean-Baptiste Kempf） 他给了一条几乎是工程师守则的话：我当工程师、管理者、创业公司 CTO 这么多年，几乎从不说重写。 理由是一个容易被忽略的不对称：写代码比读代码容易一个数量级。LLM 也印证了这点，它能写，但分析难得多。你带着最高效率写出的最好代码，六个月后自己都读不懂。所以新人接手一个复杂代码库时，读不懂那些没有文档记录的取舍和业务逻辑，第一反应往往是推倒重来，但那个判断通常是错的。 JB 接着给了一个很少见的反驳角度，专门针对他自己所在的领域。假设你把 dav1d 或 x264 的 C 部分用 Rust 重写，安全了。然后你进到汇编那一层，手写汇编可以在内存里跳到任何地方。C 部分用 Rust 重写了，汇编一进来，整个安全模型就没了。 > 所以我认为我们真正需要的是“安全的汇编”：编译期检查的汇编。这就是我们在 dav1d 和 x264 上做的 checkasm，在编译的时候给你的汇编插桩，检查它没有跳到任意地址。（Jean-Baptiste Kempf） 这次访谈里 checkasm 只是被提了两次名字就被带过了，Kieran 提到时说的是“一个疯狂但了不起的项目”。它是 VideoLAN 对这套体系最独特的技术贡献之一：在单元测试层面，同时跑汇编实现和 C 参考实现，逐位比对输出，确保手写的那 24 万行没有偏离语义。没有这个东西，手写汇编在工程上不可维护。 ## FATE：一张赌桌一样铺开的测试矩阵 Kieran 介绍 FFmpeg 的测试系统，名字挺中二：FFmpeg Automated Testing Environment，缩写 FATE。 Lex 打开 fate.ffmpeg.org 的时候看到的是这样一个界面：一排排条目按“81 分钟前”“76 分钟前”倒序排列，每一行是一个配置组合，macOS 有十几个变体因为要覆盖 iOS、tvOS、watchOS，再往下是各种架构（RISC-V、Arm、PowerPC、过去还有 DEC Alpha）、各种编译器（Apple Clang 的各个版本、GCC、Visual Studio、Intel 编译器）、各种指令集。 Kieran 管这个叫“已经不是矩阵了，是一张数据透视表”。这些机器全是志愿者提供的，排在最上面那些 Mac，就挂在他自己办公室。 它的必要性和 FFmpeg 的代码特征直接相关：C 代码写得很复杂，编译器会出错。这不是假设，是经常发生的事。编译器把正确的 C 编译成了错误的机器码，而视频帧之间有依赖关系，输出里一个极小的偏差会级联成一整片画面上可见的花屏。所以你要能在一个你没见过的编译器加指令集组合上测出这个问题。 JB 拿这个当自豪点：VLC 最新版还能跑在 Windows XP 上，也跑在 Windows 11 上；macOS 从 10.7 到最新；iOS 从 9 开始；各种 Linux、BSD、Solaris；甚至 OS/2。全世界大概还有十个 OS/2 用户，其中一个在维护 VLC。 > 你会发现这个围绕着 VLC 和 FFmpeg 的极小团队，支持的操作系统比微软、Google、苹果都多，而他们有无限的资源和人力。（Jean-Baptiste Kempf） 代价也真实。他说最头疼的是 iOS：为了在 iOS 9 上编译，需要把好几个版本的 Xcode 和 SDK 混起来，做一个弗兰肯斯坦式的拼装，因为苹果的编译器早就不支持了，而他们还要在 iOS 9 的 Arm32 上跑。 为什么值得？他说经常收到人说“谢谢，我的 iPad 2 还能看电影”。这背后是一个价值观选择：不强迫别人换新硬件。JB 把它和汇编那条线连起来：你本可以多优化一点，而不是让人一直买新的，而优化正在变成一门失传的手艺。 ## x264：一次对“数学指标”的叛变 Kieran 说 H.264 能成，一半功劳要记在一次观念叛变上。 在那之前的二十年，工业和学术界被一个指标统治：PSNR，峰值信噪比，本质是均方误差取对数。麻烦在于，最小化均方误差的最优解是把误差摊平到每一个地方，也就是让整幅画面均匀地糊一点。所以那个年代编码出来的东西，指标很好看，看起来一片模糊。 x264 的开发者是一群爱好者，为的是自己的个人视频，主要是动画。他们做了两件不一样的事。 第一件叫心理视觉率失真优化，用块的能量去做决策，把人类感知作为目标函数的一部分。第二件叫自适应量化，把比特从复杂的区域挪到不那么复杂的区域。Kieran 举的例子是草地：草地有高频成分，但整体复杂度低于别的东西，所以应该少给它比特。 用来验证这套东西的那个样本叫 ParkJoy，瑞典电视台在 HD 时代初期拍的，胶片拍摄，制作上不计成本，然后免费放出。画面是一群人在河边跑，水面有反射，树叶有光影流动，草地有纹理，运动很复杂。Kieran 说至今没有哪个公开测试序列比它更好用。 这个样本让分歧变得肉眼可见：开高 PSNR 的编码器会把画面糊掉，开心理视觉优化和自适应量化的版本明显更好看，但它的 PSNR 数字更低。 > 而当年这些指标被视为神圣不可侵犯。PSNR 是最重要的东西。（Kieran Kunhya） 更有意思的是当时怎么判断“好看”。没有 VMAF（那是 Netflix 后来用机器学习做的），没有专业监视器，就是开发者在自己笔记本上看。Loren Merritt 明确说过他不想在一个三万美元的屏幕上调参数，他要的是在别人家笔记本上看着好。 JB 补了两个样本。一个是《行星地球》里的鸟群：一群鸟，越往后鸟越多，最后像有几百万只。他说这是编码难度最高的东西之一，你在 YouTube 上看这段，能直接看出 YouTube 的编码有多差。另一个是动画，长时间以来动画编码得很糟，因为渐变多，会出现明显的色带，这块的优化主要也是 Loren 做的。 x264 的出身地也是 École Centrale Paris，跟 VLC 同一个地方，由 Laurent Aimar 发起，后来 Loren、Jason、Måns、Henrik、Anton 这些人接力。JB 说这个项目最神奇的地方是大部分人从没见过彼此。 而 x264 走出爱好者圈子进入工业界，靠的是 Blu-ray 时代的几个人愿意拿自己的职业生涯冒险。Kieran 提到 Chris Henderson 在华纳兄弟用 x264 做了整部《危机边缘》的蓝光套装。他说自己到现在仍然尽量避免在流媒体上看最讲究影像的电影，宁可买实体碟，因为不用买贵电视它也好看。 动画社群和这套技术的纠缠还有另一层。JB 说那时候大量动画没有商业渠道，在 Crunchyroll 之前根本看不到，所以字幕组自己翻、自己做时间轴、自己压片。这催生了一批工具，其中最有名的是 Aegisub。动画的编码难度也有特殊性：它大量在屏幕上制作，渐变极多，真人实拍里很少见这种纹理。字幕本身也复杂，日语原文要标假名注音（ruby），还要叠英文或法文翻译，多层样式在同一帧上处理。 > 所以字幕这个东西我们见过各种疯狂的样本。这是文化的一部分，也是因为当时没有官方渠道，没有别的办法。（Jean-Baptiste Kempf） ## I 帧、P 帧、B 帧，以及那个“未来”的问题 JB 用最朴素的方式解释帧类型：I 帧是关键帧，完整的图像，像一张 JPEGP 帧是预测帧，意思是“我要上一帧的第 5、7、42 号块”，只传增量。B 帧是双向预测帧，可以依赖前面的帧，也可以依赖后面的帧。 B 帧带来的后果是解码顺序和显示顺序不一致。要解这一帧，得先等到它依赖的那帧到达，缓冲，解出来，再回头解它。JB 说他刚入行时这件事最让他震撼：编码器要足够聪明，去决定“我要依赖未来的东西”。 Lex 感叹这整套机制每天都在平滑运行本身就是奇迹。一个编码器在某个地方产出的比特流，在地球另一端某家厂商的解码器上，逐位输出完全相同的东西。 后面 JB 提到一个 Kyber 里重度使用的技巧叫 intra-refresh：整个流里只有一个 I 帧，在开头，之后再不发送完整的 I 帧，而是随着流推进逐渐刷新画面的各个部分，把 I 帧“长”出来。这样避开了关键帧带来的码率尖峰。 Lex 提到 FFmpeg 里 H.264 的默认 GOP 大概是 250 帧，也就是好几秒才有一个完整帧，中间全靠预测链撑住，而普通人完全察觉不到。这段对话里最日常的一句话反而最说明问题，JB 说的是，你用 FFmpeg 压完一个东西，播出来还是顺的，这件事本身就像魔法。 ## 参数、码率和那些以此谋生的人 Lex 列了一串 FFmpeg 攒下来的旋钮：降分辨率、降帧率、换编码器、恒定码率还是恒定质量（CRF、QP）、GOP 长度、B 帧数量。 JB 说了一句容易被外行忽略的行业事实：一大堆人的工作就是调这些参数。你在 YouTube、Netflix、Meta 见到的那批人，很多不写编解码器，他们做的事是为特定内容找对参数组合。电影、手机拍的 UGC、屏幕录制、要拿去二次剪辑的素材，这四类要的东西完全不同。 几千个人的岗位就是干这个的。Lex 顺着说了 YouTube 的难度：Netflix 是单向广播，YouTube 还要处理从世界各地上传的、可能只有五个观众的、要在几秒内出多分辨率版本的视频。他的原话是“YouTube 基本上是网页版的 VLC”。 JB 接了个更有意思的史实：Google 在收购 YouTube 之前做的 Google Video，其实用的就是 VLC 插件，靠 ActiveX 在 Internet Explorer 里跑一个真的 VLC。而今天是反过来的，VLC 有 WebAssembly 版本，把 VLC 和 FFmpeg 一起编译进 JavaScript 虚拟机里跑。 他还讲了流媒体的真实瓶颈在别处。自适应码率这套东西本身不复杂，下个分片超时就降档，下载时间不到一半就升档，真正难的是 CDN 拥塞和人类心理。Kieran 补了一个更细的观察：观众对视频码率波动相当宽容，对音频码率波动极其敏感。从完整 AAC 切到用频谱带复制的压缩版本，声音会突然发薄，那种上下起伏很扎耳朵。视频侧平滑得多。 > 我们对跳帧和音频故障的容忍度其实高得惊人。我认识很多不是视频工程师的人，看体育比赛 30 帧也无所谓，本该是 60 帧。（Kieran Kunhya） ## Kyber：从“画质”转向“毫秒” JB 的路径是逐级下探的：先用 FFmpeg 编码文件，再用 FFmpeg 和 VLC 做流媒体，然后问一个问题，能低到哪去。 答案是低到有交互反馈的场景。看视频是被动接收，遥控是另一回事，你要控制它。无人机、人形机器人、远程车、云游戏，这些场景的约束彻底变了。 > 你不再在乎我们刚才聊了半天的那种画质，你在乎延迟。因为在控制一辆车的时候，一毫秒是有意义的。（Jean-Baptiste Kempf） 他举 Waymo 当例子：Waymo 不工作的时候，哪怕只有 1% 的情况，背后是有人在远程接管。这正是 Kyber 在做的场景，一个端到端控制机器的 SDK 平台。 技术选择上，Kyber 只用一条连接，基于 UDP 的 QUIC 协议，因为它是为低延迟设计的，避开了 TCP 和 HTTP 的队头阻塞，默认加密。在同一条线路上跑多路流：音频、视频，还有控制指令，鼠标、键盘、手柄，同时保持同步。 同步为什么难？因为所有时钟都会漂移。一台机器人上可能有十路摄像头、GPS、各种传感器，你要训练机器人 AI 模型，这些数据必须时间对齐且长期稳定。Kyber 在服务端做了重打时间戳的机制来补偿时钟漂移。现有的方案在一路摄像头上能工作，到了五六路就复杂了。 另一个机制是前向纠错：多传百分之几的数据，这样丢包时接收端能重建，而不用等重传。要保证所有包都到达，延迟就会暴涨；不要延迟，就只能靠冗余。 目标数字是 4 毫秒玻璃到玻璃延迟。4 毫秒意味着 240 Hz，如果你有一台 1000 帧每秒的相机，理论上能实时回传。目前做到的是 Windows 到 Windows 或 Windows 到 Mac 的 7 毫秒，其中 NVIDIA 硬件编码器占约 3.5 毫秒，Intel 解码器占约 2 毫秒，编解码加起来已经 6 毫秒。要再往下，得换编码器或者换更快的实现。 Lex 问这是不是没人做到过。JB 说专用硬件可以，SDI、专业设备能做到，但他要的是在互联网上、在任何一台装着 Jetson Nano 或者 N150 小主板的机器人上做到。 > 未来所有的远程车都会被 AI 模型远程监视，它说“一切正常”，不正常的时候说“这里有问题”，然后有人介入。这关乎安全。当你的机器人照顾你奶奶的时候，我要确保一切正常。（Jean-Baptiste Kempf） CES 上他们做了个演示：一辆全 3D 打印的小车，带伸缩臂，在拉斯维加斯，从法国远程控制，视频来自一个普通摄像头和一块很小的板子。他们还在做 3D 打印的机翼、帆船，后面会碰人形机器人。 商业模式是双授权：AGPL 加商业授权。你想在商业产品里用又不愿意开源整个产品，就买商业授权；小团队和爱好者可以免费用。JB 说这件事对他来说很有意思，因为视频他算做得还行，网络他还有太多要学，拥塞控制协议、实时的码率自适应。 ## 专利地雷：为什么谷歌要自己造一个编解码器 JB 给了最简洁的代际总结：每一代大概提升 30%。MPEG-2、H.264、HEVC、H.266 一路下来，AV1 比 H.264 省 40% 到 60% 带宽。他也承认从业者会来吵架：有人说 25%，有人说 50%，因为具体到某个内容，新一代工具可能省 70%，也可能只省一点点。屏幕录制就是收益极大的那一类。 命名混乱的来源是两个标准组织：ISO 是私营的，ITU 是联合国机构，两家合作，所以每个标准有两个名字。H.264 等于 MPEG-4 Part 10 等于 AVC，HEVC 等于 MPEG-H 加 H.265，H.266 等于 VVC。 真正的分歧不在技术，在专利。 > 多媒体是专利雷区。全世界专利最密集的两个地方，一个是 3G、4G、5G 和射频，另一个就是多媒体。因为它非常数学化，能做出来很大的增益。（Jean-Baptiste Kempf） 他解释了专利是怎么产生的：在 MPEG 的流程里，标准做完之后，各方跑来说“这个格式我有专利”，然后通常组成一个池子，MPEG LA，向所有使用者收费。他举了个荒谬的例子：本来是方块，我改成矩形，这个想法可以申请专利。 H.264 时代的专利费还算理智。到了 HEVC，因为钱太多，往规范里塞了大量在 99.9% 场景下没用的工具，唯一目的是能挂一个专利上去。结果是授权变得几乎不可能：MPEG LA 之外还有 HEVC Advance，诺基亚还在池子外面。费用没有上限，对 YouTube 或 Netflix 这种量级可能是每年几亿美元。 这笔钱算下来，结论很清楚：一年一亿美元，不如自己造一个。所以有了 Alliance for Open Media，有 AV1，有 AV2。JB 说 VideoLAN 也在这个联盟里。 > AV1、AV2 在标准化流程里有专门的专利审查环节，而 MPEG 那边专利是完全的禁忌话题，不谈。（Kieran Kunhya） 代价是需要双重创造力。既要更高效，又要确保不踩已有专利。Kieran 用了一个很好笑的例子：AV1 里有个工具叫 S-frame，本质上是一种 B 帧的变体，之所以叫这个名字，就是为了绕开专利，像“我能相信这不是黄油”那种命名。 VLC 和 FFmpeg 怎么面对这些？JB 说他们不需要面对，这是 VLC 落脚法国的原因之一：法国不承认软件专利，大部分这类专利在欧洲无效，因为它们本质上是数学专利、想法专利。他算过一笔账，如果 VLC 要为每个用户付全部专利授权费，得每人两百多欧元。 他还顺手回应了欧洲不适合创业的论调。英国早就走盎格鲁-撒克逊那套商业模式，而法国这十五年变化很大：过去创业失败会背上污名，不让你再开公司，现在这个 stigma 已经没了，市场上大多数人想的是做 startup。 ## 情报机构、后门，和“我们会关掉它” Lex 问有没有政府来找过要后门。JB 说有，两家。 > 如果我们要妥协自己的软件，我们会把它关掉。这一点是明确的。（Jean-Baptiste Kempf） 具体防护措施他说得很细，而且他自己承认听起来像偏执：没有任何代码能进 VLC 而他们不控制；编译在离线机器上做，第一步是先编译编译器；全部在从没连过网的机器上完成；签名做双重签名。原因是他们发现并且相信有非西方国家的政府机构试图往他们自己的服务器里推一个假的二进制文件，这件事让他们非常警觉。 Lex 追问万一被施压怎么办。JB 的回答是开源软件没法被杀掉：我搬到马耳他、开曼群岛，换个域名，重新开始。VLC 是一个工具，不是平台。 关于内容审查，答案是不可能。VLC 完全离线，不跟任何服务器通信，没有遥测，所以谁也不知道你在看什么。有政府问过“我想知道这个人有没有看过那类视频”，回答是不知道。 他们跟执法机构唯一的合作形式是技术支持。JB 讲了一个案子：美国警方说有个谋杀案，关键文件损坏了或者在那个版本上放不出来。他说这类支持跟普通用户没区别，他们从来没有视频内容。另一个故事是阿富汗战争期间，一个军人写邮件说新版本 VLC 在 RTSP 服务器上放不出来，而那个服务器上的电影是地面部队的士气来源。JB 改坏了对 RTSP 的支持，于是给他单独做了一个版本。 他还顺口说了 VLC 大概是被允许装在美军笔记本上的，因为开源，有人审过代码和处理方式。而整个 VideoLAN 在法律层面只有他一个人。 Lex 问他怎么不焦虑。JB 说他以前非常焦虑，现在不是。 > 我的思考方式是永远先想最坏情况。像下棋一样，最后的问题是：我会死吗？会还是不会。做创业公司也一样，最坏是破产，公司有生有死，这没关系。我的道德判断一直是：我会死吗？我伤害到别人了吗？如果答案都是不，那就随它去。律师会不高兴？他们能怎么样，把 VideoLAN 的钱都拿走？哇，五万块。源代码在外面，这是挡不住的。（Jean-Baptiste Kempf） 整期节目里这段最接近他自己说的“禅”。它的内核不是乐观，是把最坏情况算到底之后发现它不致命。 Kieran 在这里插了一句实务观察：在欧洲应对法院传票不至于让你破产，在美国可以。JB 说他每周都收到律师函，VideoLAN 一年花在律师费上的钱不到一万美元。 关于那次著名的 CIA 事件，JB 讲得挺平静。WikiLeaks 的 Vault 7 文件披露，CIA 做了一个定制版 VLC，二进制的其余部分都是真的，只加了一个 DLL，叫 psapi.dll，功能是读你的文档目录，加密，然后发出去。伪装得很聪明：你在看电影，两个小时不会碰电脑；高清片源让风扇轰鸣、CPU 占用拉满，这也是正常的；所以你不会察觉。 同一套手法还被用在了别处。有中国黑客针对印度用户做了同样的事，结果导致 VLC 在印度被封禁，JB 不得不在印度政府那里打官司，证明那不是 VLC。他们只是拿了那个签名正确的 DLL 去做别的事，真正的 vlc.exe 调用 libVLC，但指向的是一个假的。 > 这种事我们其实没什么办法阻止。（Jean-Baptiste Kempf） 他还说了另一件更让人无力的事：德国有一个假冒 VLC 的网站，被举报了十二年，谷歌知道里面是什么，但因为那个二进制文件太大、超出他们病毒分析器的处理上限，所以一直没动。那个网站用德语，在德国的搜索排名比 VideoLAN 官网还高。装上去之后三周内什么都不做，三周后才有一个作为服务安装的小程序苏醒，开始下载间谍软件和广告软件。这三周的静默期就是它躲过检测的设计。 ## 档案：让一千年后的人还能按下播放 Kieran 说开源多媒体里最酷的社群之一是档案保存社群，主要由 Dave Rice 推动，他在纽约市立大学。这个群体预算紧张，但他们清楚 FFmpeg 是那块罗塞塔石碑，是让多媒体在一千年后还能被播放的东西。 他举了一个警示性的例子：英国当年做过一个“新末日审判书”项目，把大量内容存在 BBC Micro 微机上，十来二十年后没人有能读它的软件，得有人去逆向。 二十年就要逆向。想象一千年。 这个社群资助了 FFV1 的开发，一个无损编解码器。他们的顾虑很直接：有损压缩可能会改变素材呈现的样子，某个角落里有东西，被压掉了。所以既要不损失，又要编码够快。他们资助了 FFmpeg 里 FFV1 的 GPU 编码来提速。他们还特别在乎容错：存在磁带或者硬盘上，坏了几位要能快速恢复，不能因为丢了一位就整段 GOP 全废。 JB 说他每次跟 Dave Rice 或者英国电影学院的人聊，都能学到新东西，而他做视频二十年了。对方最懂的是色度学和颜色，还有存储介质。他提到胶片扫描仪这个话题，说光这一个题目能再讲五小时。 Kieran 说这个社群还把工作流免费教给没有档案机构的国家，在印度教小孩写 FFmpeg 命令。他把他们称为我们想达成的模式的样板社群。 > 一千年后我们可能淹在 AI 生成的内容垃圾里。这些东西需要被认真保存。当时的生活是什么样的？（Kieran Kunhya） Lex 把这层意思说得更明确：二十世纪到二十一世纪是一个转折点，从数据稀缺转向内容过剩，这个转折本身值得被保存。 而现状是紧迫的。三十、四十、五十年代有大量影片已经失去了价值载体；七十、八十年代的磁带还在，但全世界的磁带读取机磁头不够用，读不完所有带子。所以他们必须做取舍，决定哪些数字化，哪些扔掉。 > 这是人类历史的数字记录，而他们要做的决定里有一种巨大的道德风险。（Kieran Kunhya） Kieran 还给了 FFmpeg 会被保留的一个技术理由：它是 C 写的。C 是最接近数学和逻辑的语言，一千年后 C 大概会像拉丁语，是你要从过去学的东西，但仍然可用。 ## 未来：气味、触觉和脑机接口 JB 给的五年十年预测很轻松，难的是更远。问题在于会不会出现全息，会不会出现别的东西。 Lex 把话题推到 Neuralink 那种程度：如果多媒体的定义变成“大脑通过脑机接口想消费的任何数据”，那编解码器长什么样。 Kieran 直接接了一句，会有 FFmpeg -i 输入格式 human brain，用来压缩神经信息。 JB 说这不是纯想象。今天已经有针对点云、体积视频的编解码器，有大量关于 RGB-D 的研究，也就是带深度信息的视频，深度编码对机器人和 3D 场景很有用。VLC 已经有 VR 和 XR 版本，Kyber 也在为算力不足的眼镜、Apple Vision、Quest 做 XR 内容的流式传输。 他给多媒体下了一个可以外推的定义：多媒体是对人类多种感官的数字表示。所以如果将来有气味传感器和气味扩散器，它就会进 FFmpeg，你的解复用器会多出一种叫“气味”的轨类型。 Kieran 顺着玩：像音频一样，左鼻孔和右鼻孔两条轨。 VLC 其实已经有触觉的插件，服务于 4D 影院那种液压座椅，有同步的数据流传输运动信息。这个模块不在正常版本的 VLC 里。 Lex 问标准怎么形成。JB 描述了一个几乎每次都重复的曲线：新领域出现，人人都做，冒出五种标准；热度降下去；然后两三家非领导者的公司推动做标准；然后我们实现标准；然后曲线结束。他举了 3D 音频的例子：六七年前满世界都是 3D 音频，安卓上有 Cardboard，有两种音频格式，全死了，现在带着真实用例回来，并且吸收了上一轮的教训。 Lex 顺口提到 JB 对杜比意见不小。JB 的回答挺克制也挺重：这曾经是一家了不起的公司，有着了不起的工程师，他们定义了声音是什么。现在主要是律师和授权业务。他们不像过去那样创新了。 ## 火星、CERN、围场，和那些奇怪的落点 Lex 问最得意的推特。Kieran 说两条。一条是“Talk is cheap, send patches”，因为它概括了一个基本事实：东西不会从以太里冒出来，得有一个人去做。另一条是“FFmpeg, nothing is beyond our reach”，那句话来自一颗美国军用卫星的补丁。 JB 提了一句 FFmpeg 跑在火星车上。Kieran 确认了：Mars 2020 的火星车用 FFmpeg 压缩图像，NASA 为此写过论文，他们的原则是尽量用现成的商用技术。所以这个库是多行星的。 VLC 的落点更杂。JB 说他们经常看到有人在奇怪的地方用 VLC：F1 各个围场里的人在用它播直播流；欧洲空间局；SpaceX 用它监视发射。 他自己经历过的最好的一次是去 CERN。大型强子对撞机的环周长 27 公里，上面布满了各种传感器和模拟摄像头，CERN 用采集卡把模拟信号转进 VLC，再由 VLC 推到他们自己的组播网络上，让全 CERN 都能看。2010 年他和 Laurent 一起去，一小时就修好了他们的问题，大概是个当时文档没写清楚的参数。修完之后对方问“今天你想干什么”，然后带他们看了个遍，反物质、对撞机，全看了。 > 那是我物理学背景里最神奇的一天之一。（Jean-Baptiste Kempf） 还有那个关于代码本身的故事。JB 小时候想当工程师，想做汽车，中间在意大利佛罗伦萨住过一年，数学老师让他们用 Logo 语言画乌龟。他自己说，也许将来某天会回去做车。 Kieran 的第一门语言是微软 QBasic，在 Windows 3.1 和 95 上写 10、20、30、40 的循环，然后画了一堆草图，觉得自己能做一个足球游戏。他后来承认，从 BASIC 加几张画跳到一款真正的游戏，中间的工作量他当时完全没概念。 ## 遗憾是一种税 Lex 问 Kieran 有没有后悔发过的推特，然后自己接了那首法国歌：*Je ne regrette rien*。 JB 接过来说了一段可以直接抄下来贴在显示器上的话。 > 不要后悔。因为后悔是对你大脑征税。从错误里学习，但不要后悔。事情已经发生了，除非你有时光机，否则后悔只会消耗你的脑子。学习，可以。后悔，不必。（Jean-Baptiste Kempf） Lex 说这让他想起约翰尼·德普那句关于恨的话，恨是一种很贵的情绪。JB 的反应是：你是在把我比作约翰尼·德普吗，那会是你今天的第一个错误。 整期节目里，两个人都没有把开源说成一种道德姿态。他们反复讲的是一组非常具体的约束：五到八个人维护着几十亿人用的东西；来了又走的人占 99%；一个补丁的质量决定这个项目还能撑多久；一封夹着面粉的信可以来自一个因为 PowerPC 停产而愤怒的人。 最后 Lex 收尾时说，他感谢这些软件，感谢那些辛辣的推特，请永远不要停，也感谢那顶让他看起来像个巫师的帽子。Kieran 和 JB 道谢。节目用林纳斯·托瓦兹的一句话作结：大部分优秀程序员写程序，不是为了拿钱或者被公众追捧，是因为写程序本身好玩。 ## 如果你读到这里想做点什么 这期播客里最扎人的一件事实是，地球上大部分视频流量经过的那套代码，核心维护者只有十到十五个人，而且全是志愿者。Kieran 说得很直白，捐款增加了很多，但仍然不足以覆盖一个全职开发者。如果你从这套东西里得到过任何东西，下面这些是可以立刻做的。 - 给 FFmpeg 和 VideoLAN 捐款。Kieran 在节目里被 Lex 提到捐款时说的第一句话就是“谢谢”。金额不重要，重要的是让“这件事有人在管”变成一个可持续的事实，而不是靠几个人的热情和失眠撑着。 - 去关注 @FFmpeg 和 @VideoLAN 这两个账号。不是为了看吵架，是因为这两个账号是目前最能迫使大公司在流程上低头的杠杆。JB 说得很清楚：他们太小了，唯一有效的力量就是社交网络上喊话，因为会滚雪球。 - 下载任何软件时手动确认域名。VLC 在德国有一个持续了十二年、至今还在的假冒网站，搜索排名比官网还高，安装后三周才开始下载间谍软件，这个延时本身就是它躲过检测的手段。谷歌知道，没动。这个坑对所有开源软件都成立。 - 如果你会 C，去看 Kieran 那套 asm-lessons。他明确说了门槛只有高中数学和指针，不是完整的 C。这套课按 FFmpeg 的实际做法重新组织，不逐个讲指令语法，直接上手解决真实问题。已经有 16 岁的人学完之后提了补丁。 - 如果你是工程师，找一个你真在乎的东西去做贡献，不要为了简历。JB 的原话是做你热爱的东西，他自己是因为爱看电影才做 VLC，社区里有大量人是因动画进来的。你也别指望能留下来，统计上留下来的概率是 1%，但那 1% 决定了整套基础设施能不能继续存在。 - 如果你在决定要不要重写一个别人写的系统：先别。写代码比读代码容易一个数量级，你觉得它烂，很可能只是因为你还没读懂那些没有文档记录的取舍。 - 如果你在公司里跟开源项目对接，确认一下你们有没有 OSPO，以及它有没有把“这不是我们的供应商”这件事讲给业务团队听。微软 Teams 那个几千美元一次性买断长期支持的报价，根源不是恶意，是一个中层管理者从来没被告知过这套东西是怎么运转的。 - 如果你的工作涉及长期保存数据，去看 FFV1 和档案社群的工作流。他们面对的约束比大多数工程团队都严苛：无损、可验证、单比特翻转要能局部恢复、一千年后还得有人能读。他们是怎么在这些约束下做取舍的，比任何架构课都实用。