#496 – FFmpeg：互联网视频背后的关键技术

有很多人在用 VLC 录制 VHS 视频，对吧？比如接上一块采集卡，基本上就能录制 VHS 视频。

基本上就是那种 capture card，可以接 Peritel 或 RCA，把它接上之后，VLC 实际上可以播放这类卡的输入，而且还有一个 module，可以直接控制某些 VCR camcorder。我们最近也支持了 DVD audio，对吧？整个夏天我们都在做 DVD audio support，而现在几乎没人再做 DVD audio support 了。里面还有自定义的 encryption scheme。

对。还有当然是各种奇怪的 codec support，FFmpeg 支持的 game codec。

有意思的是，在一次 VideoLAN conference 上，我们办过一个比赛：做出最奇怪、最糟糕的文件，然后看 VLC 能不能播放。

是 Derek 做的一个 MKV file，每一帧都在改变 resolution、aspect ratio、rotation。然后问题是：能播吗？能。还有另一个，整个视频其实都是 animated subtitles，对吧？SSA。所以每一帧都是黑帧，但上面叠着一条每帧都在变化的 subtitle。

所以我们确实办过一个愚蠢文件比赛。

对，绝对是。VLC 的 logo 太有辨识度了。我们团队人数很少，但这个 icon 到处都有人认识。我去印度或中国很偏远的地方，人们也知道这个 cone。我们主网站大约 25% 的流量来自“Kun Player”这个搜索词。很多人其实不知道 VLC，他们知道的是 Kun Player。

对，他们去 Google 输入 Kun Player，然后下载 VLC。所以这很有标志性。我们有一次还开玩笑说要换 logo，说会换成一种 caterpillar construction 的样子。那是在 4 月 1 日说的。结果我们收到了大约 10,000 封邮件，说不要换 logo 之类的。所以它确实太有标志性了，也很独特。如果你要做一个 video player，通常会在电视上放一个 play button，对吧？那就像 YouTube logo。这一个是原创的，是橙色的，很亮，而且很怪。

然后你会一直保留它，记得它。20 年后，你仍然会有这些 cone，并且记得：对，那是一个 video player。

我们确实希望如此。不过也有很多 meme，大家说：我相信我把一块 pancake 放进 DVD drive，VLC 也能播放。能吗？不能，我们试过，不行。但我们确实有一段视频记录我们尝试这件事。没有成功。

还真有人做过类似的事。他打印了一个小 cone，就像我们作为 goodies 发的那种。里面放了一个 RFID chip，用这种方式来播放电影。于是他把它放到 RFID player 上，一放上去，就会播放比如 The Last Star Wars 之类的电影。所以他不是摆一堆 DVD 盒子，而是到处放 VLC cone；你把那个接上，它就像一种 physical object。

这里有几个阶段。第一个阶段，是从一个 address 开始，也就是某种 URL，得到一串 byte stream。比如 HTTP file、DVD。你给出 media 的 path，它就给你一串 data stream。

对，因为人们没有意识到 video 和 audio 的压缩是 100 倍级别的。大家没有意识到我们压缩得有多厉害。对于 audio，从普通 audio 到 MP3，压缩大约是 10 倍。到了 video，就需要 100 倍、200 倍。所以你必须去掉所有你并不在意的细节，因为我们做的所有压缩——这一点非常重要，但人们常常忘记——都是为了给人观看。所有 codec，无论是用于 audio，基本上都是在模拟你的耳朵如何工作，也就是耳朵响应中的很多特性；眼睛也是一样。所以比如在 video 中，我们并不使用 RGB。大家都以为会用 RGB，但并不是。我们会转到 YUV，其中一个是 luminance，也就是亮度，另外的是颜色。这和你的眼睛相匹配，因为你的眼睛里有 cones 和 rods，其中一些更多关注亮度，另一些更多关注颜色。我们需要大量压缩，因此必须降低质量。但为了降低质量，我们必须匹配 human perception。这就是为什么它这么难。然后我们还需要使用最大的数学能力，非常复杂的技术。像 Kieran 说的，我们会转到 frequency domain。我们做大量 dequantizing，以获得最佳压缩，但看起来仍然不错。

没错。正是如此。这一点非常重要。Compression 不像 zip。zip 是数据进来、数据出去，然后你用各种 zip compression 尽量接近极限。但这里我们是在 degradation signal。我们需要以尽可能好的方式 degradation audio 和 video signal。我们可以做到，但这首先涉及大量关于眼睛如何工作的理论知识，也涉及大量数学变换和数学技巧。比如，当你从 RGB 转到 YUV 时，我们经常做的一件事是，相对于亮度，把颜色的 resolution 降低。大多数时候，仅仅这样，在没有 compression 的情况下，大小就能减半，但大多数人看不出来。诸如此类。然后你会进入非常复杂的数学变换。当然有 Fourier transform，事实上它们并不是 Fourier transform，而是 discrete cosine transform，但思路相同。也就是 frequency domain，我们把 video 按 block 拆分。所以当 decoding 错了，或者 encoding 很差时，你会看到那些 block，等等，以达到非常高的 compression state。每一代 codec，在相同质量下大约都能再减少 30%。而这需要巨大的 computational power。

整体上发生的是，你有一个 address，它通过 operating system 给你一串 byte，也就是一串 data。这是第一步。第二步是 demuxing，你会把 audio、video、subtitle 分离成不同类型的 track。然后对每一条 track，你会 decompress、decode，用 audio codec 处理 audio，用 video codec 处理 video，用 subtitle codec 处理 subtitle。等你把这些东西 decompress 之后，你就有了 raw image、raw 内容，然后你会和 screen 上的 graphic card 通信并显示出来。audio 也是一样，你会和 audio card 通信，然后它会以 analog 形式传到你的 speaker。

container 也就是我们所说的 muxer，对吧？我说 demuxing 的时候，意思就是 decontainerizing。实际上你看，mux 是 multiplexer，demux 是 demultiplexer，对吧？mux 和 demux 就是这些概念。同样，codec 其实是 coder decoder，对吧？所以 container 是多个 track 的集合。普通人会把它叫作文件格式，但它比这个说法更细一些。最常见的当然是 MP4。但我刚开始做的时候，是 AVI。AVI 是 Microsoft 的视频格式，而 MOV，M-O-V，后来变成 MP4，是 Apple 的格式。在 open source 社区里，有一位现在仍然活跃在 Videolan 的人叫 Steve Lorme，他发起了 Matroska 格式，这个格式更复杂一点，也更面向未来。还有很多其他格式。

不算，因为从技术上说，H.264 的名字是 MPEG-4 Part 10，因为 MPEG-4 实际上是一个 meta-specification，里面包含好几类东西。它有 Part 2，也有 audio codecs。AAC 实际上可以说是 MP4 audio 之类的东西。MPEG-4 specification 里实际上有好几个 video codecs。其中一个就是 MPEG-4 Part 10，也叫 AVC，也叫 H.264。所以这完全是行业自己的问题，把事情搞得很难理解。于是人们就很难明白，为什么有时候你说 MPEG-4 Part 10，指的是 H.264，以及为什么它又不是 MP4。

这一点非常重要。比如在 VLC 和 FFmpeg 里，我们会丢开文件格式本身。我们会查看文件内部，理解里面到底有什么，因为很多人会说，哦，这是个视频，那一定是 .mp4，但技术上它可能是 .mov，或者可能是 .mkv。所以我们会实时分析手头的一切，不信任格式。

它有帮助，给你一个提示。就像，哦，它以 .mp4 结尾，那我会先用 MP4 container demuxer 打开、probe 一下，看看它是不是应该是这个格式，但我不会完全信任它。如果我不确定，我会说，好吧，也许我试一下。所以它会提高这个 module 的优先级。

是的。

这就是 VLC 受欢迎的原因。但原因在于，VLC 最初其实只是一个叫 VideoLAN 的 streaming solution 的 client，那是很久以前的事了，大概是 90 年代末。当你播放通过 UDP 在网络上传输的视频时，它们可能是损坏的，对吧？所以你不能信任输入。在今天的安全语境里，这一点也非常重要：不要信任输入。因此，VLC 里的所有东西都准备好处理 broken files。这是从一开始就有的理念，整个工程也是围绕这个设计的。这是一种文化。比如，VLC 因此变得很流行，因为很久以前，当人们还在 pirating content 的时候——当然现在少多了。

当然没有。像 AVI 这类文件，用来播放的一些 metadata 在文件末尾。你在下载的时候，还拿不到那部分。所以 VLC 就会说，好吧，这个文件坏了，但我还是会尝试解释它。这非常有用。

为了让不熟悉的人更有画面感，比如你看任何类型的电影，镜头会 pan，会移动。你会发现，比如整个背景在一分钟或 30 秒内都是一样的。于是你可以复用背景里看到的那朵云，可以从一个 frame 复用到另一个 frame。这样一来，你拥有的 memory 越多，算力越强，就能做越多比较，也就能压缩得越多。大多数现代 codecs 基本都在做这件事。

1,000x，对吧？

目标是 1,000x，对吧？

举个例子，你有一张云的图片，对吧？到下一帧，它仍然会是同一朵云，所以这是冗余的。你可以只存一次，不再重复存，对吧？或者比如我身后是黑色背景，整张图里的黑色都是一样的。你就可以说，在这张图里，取左上角和右上角的像素。我不再给出具体数值，只告诉你它和左上角一样。然后对于第 1 帧，你还可以复用前一帧，或者再前一帧里的某些内容，以此类推。原则上这可以无限做下去，但实际上会受到 memory 或 compute power 的限制。比如，如果你需要在 4K 分辨率下比较过去 200 帧里的像素，那 compute 量会非常大。

没错。这其实是两个不同的取舍。你是要压缩得更多，但可能更难 decode？还是要做一个 encode 更复杂、decode 更容易的 codec？或者做一个更容易 encode 的 codec，因为你需要速度快，但 client 端的 player 要花更多时间？这就是为什么会有这么多不同类型的 codecs，因为这件事并不总是简单。更复杂的是，现代 codec，比如 AV1、AV2 或 VVC，实际上并不是单一的 codec。它们是一组 tools。也就是说，同一个 codec 里有多个 tools、多个 codecs，会根据图像内容选择更高的压缩率。

FFmpeg 基本上是 codec 的 low-level libraries，也就是 compression 和 decompression、muxers 和 demuxers，以及 filters。它的核心就是这些。然后还有几个 tools，可以让你创建某种 pipeline，用来处理任何类型的 video files。它作为 library 被用在几乎所有地方，从 VLC 到 Chrome，到 smart TVs，再到基本上你在网上看到的任何 video，通常都会用到 FFmpeg。FFmpeg 里面有所有这些类型的 tools，有时也依赖其他 libraries，比如 x264、libvpx 等等。所以它现在实际上已经是处理 images 的事实标准工具。

它是一种 language，是真正的 language。

当然。大多数人会用 FFmpeg，指定 input file、output file，再指定 format，对吧？但我们见过几千个字符的命令，也见过有人通过编程生成 command lines 来使用 FFmpeg。现在有很多人用 AI 来生成 FFmpeg 的 command lines，因为你根本不知道那些参数是什么，但你可以指定非常多 filters，对吧？在 command line 里。FFmpeg 就是这样一套 multimedia processing 的 toolbox，所有人都在用。每个观看你 videos 的人其实也在用。你在 YouTube 上看内容，client side 用的就是 FFmpeg。你的 server side 也是；client side 可能是 Chrome，那你同样也在用 FFmpeg。你用 OBS 录制，也是 FFmpeg。你使用很多重要的、专业的大型设备时，也很可能在某个内部环节运行着 FFmpeg 的一部分。

但如果你看，比如你可以在 FFmpeg 的 command line 里做一些原本会用 Adobe After Effects 做的事情。这很有意思，因为在 imaging 领域，并没有这样一个工具。也有一些工具，但没有 FFmpeg 这么广的覆盖面。

是的，但你不会用它做某些 filters，尤其是 complex filters。你没有一个 command line 版 Photoshop 的等价物，对吧？但在 video 领域，你有 command line 里的 FFmpeg。

VLC 和 FFmpeg 背后的 vision 是一样的：把对普通人、对所有人来说非常复杂的东西，做得容易使用。我们的目标是把技术上极其复杂的东西做成易用的工具。人们用 VLC，把一个 file 拖进去，他们不会意识到这个 file 有多复杂，但它就是能播放。或者人们把各种东西放进 FFmpeg，配上复杂 filters，它就像魔法一样能工作。这就是我们的使命：处理非常复杂的东西。

你也会注意到，一切都在从 text 转向 images，再从 images 转向 video，对吧？看看 social networks。video 无处不在。它是现有最强大的媒介，对吧？当你看 Shorts、Reels 和 TikTok 的时候，就会明白 video 在这方面非常有力量，对吧？但其中的复杂性也很重要。

是的，FFmpeg、VLC、x264、Videolan，我们做的一切都是完全 open source 的。对于不了解 open source 的人，我通常会用一个巧克力芝士蛋糕来打比方。通常，当你想买芝士蛋糕时，你去面包店，他们给你芝士蛋糕。另一种拥有芝士蛋糕的方式，是让你的奶奶给你一份制作它的 recipe。我们做 open source 时，会把巧克力蛋糕给你，也会把能够重新做出同样蛋糕的 recipe 给你；同时还会告诉你如何建造烤箱，以及你可以怎样修改 recipe，并把它转卖给别人。

这是因为 software 本质上就是一份由很多小 instruction 组成的很长的 recipe。computers 并不聪明，它们只是运行得非常快。所以一个普通 program 有数百亿条 instruction，而你的巧克力 recipe 可能只有几十条。很大一部分 software industry 做的是销售 software，也就是只给你最终的芝士蛋糕。在 open source 里，我们把一切都给你。这样就让很多人能够一起工作，对吧？因为你决定要为 video 做出最好的 program、最好的 recipe，于是就形成了 communities。自 FFmpeg 一开始以来，可能已经有 2,000 到 3,000 人参与贡献，对吧？这和 Linux kernel 完全一样。Linux kernel 可能有 10,000 人在各处贡献，他们聚在一起，主要是在 online，对吧？也就是虚拟地聚在一起，为某件事创造最好的 tool。在 FFmpeg 和 VLC 里也是这样，比如这个 codec 不能用，那我就去修这个 codec，并把对这个 file 的支持加入 FFmpeg。这样所有人都会受益，因为我们是在为更大的公共利益工作。我们是在为所有人工作。这就是 open source。

确实有人这么做。很多问题主要出在 cloud providers 身上，他们基本上是在 cloud 里运行一些 open source tools，然后只给你 API 来访问它。像 Mongo 或 Elastic 这样的很多 databases，为了避免这类场景，都修改了自己的 license。

从 Rousseau 的角度看，license 实际上是 community 的 social contract。community 除了 license 之外，在很多事情上并没有共识。人们之所以围绕它参与、讨论，是因为 license。license 也允许出现 fork，对吧？有时 community 会分裂，但也正因为有 license，之后才有可能再 merge 回来。我们已经见过很多次了，对吧？GCC 和 GC、eGCC，过去的 W3C。比如所有 web browsers 也是这样，对吧？它们最开始是 KHTML，后来变成 WebKit，再后来变成 Blink。所以 open source license 是 community 的核心。人们来自世界各地，有非常不同的宗教、政治边界，却以同样的方式在一个 project 上工作，去解决一个具体问题。而我们正在解决的具体问题，是让 multimedia 对每个人都变得简单。

Apache 是大家比较理解的。

有很多 license 适用于很多不同的事情。人们不理解的是，public domain 并不是在全世界都存在的概念，对吧？所以所有 open source licensing 都使用 copyright law，也就是 international copyright law，来授予你如何使用 software 或如何修改它的 rights。它事实上是一种 copyright license contract，授予给 end user 或 developer。所以你会有第一类，基本上非常 permissive，比如 MIT、BSD。你给出 code，然后基本上别人想做什么都可以，对吧？拿走、修改、做任何想做的事。这在 JavaScript 和 BSD operating system 这类项目中很流行。

是的。在这类 permissive license 中，有些要求你在使用时声明，这叫 attribution；有些则不需要。然后还有另一类 license，也就是 copyleft，你需要把自己的 modifications 回馈给 community，并且带有不同的附加条件。有些是 weak copyleft license，比如 Mozilla Public License；有些更强一点，比如 GPL；还有非常强的，比如 AGPL。所以这些都是不同类型的 licensing，取决于你的目标是什么，以及你想如何组织你的 community。这也是为什么我说它是 social contract，因为理解这一点非常重要。FFmpeg 和 VLC 大多是 GPL 或 LGPL。Linux kernel 是 GPL，但 Android 是 Apache。大量正在使用的 JavaScript frameworks 大多是 MIT。所有 BSD kernels，比如 OpenBSD、NetBSD，当然都是 BSD。所以这基本上是在“你希望人们如何回馈贡献”这个问题上的哲学差异。

是的。所以你需要意识到，license 总是可以从更宽松变得更不宽松，对吧？因为这些 license 本质上就是一种声明。所以如果你要限制，总是可以限制得更多，对吧？在一个 GPL 项目里，你可以使用 MIT 代码，但反过来不行，对吧？因为它们受到的约束更多，需要匹配。事实上，我曾经把 libvlc 的核心，也就是 VLC 的引擎，从 GPL 改成了 LGPL。这样做有两个原因。第一个是，人们可以把 VLC 引擎 libvlc 用到第三方应用里。所以你手机或平板上很多播放视频的应用，实际上里面都有 VLC 引擎，而它又会调用 FFmpeg。这也是我创办的其中一家公司的一种业务来源：做这类应用的咨询和集成，把 VLC 集成到第三方解决方案里，比如 game engine 里面之类。如果是 GPL，你就不能这么做，因为那意味着你需要把所有东西都 open source。而很多商业公司并不想这样。

是的。

FFmpeg 也是完全一样的。一样。LGPL 强制你把你对这个组件、这个 library 所做的修改回馈出来，这也是它叫 Library GPL 的原因。所以你可以把 FFmpeg 以 LGPL 的方式用到任何类型的应用里，甚至是非 open source 的应用，但你需要回馈你对 FFmpeg 所做的修改。libvlc 也是一样。

这取决于公司。但如果一家公司的 business model 要求 source、应用必须是 closed source，那么是的，它会受限制。所以这也是为什么我当时改成 LGPL。第二个原因更隐晦一些：App Store，也就是 Apple 的 iOS App Store 的条款，让 GPL 应用上架变得非常复杂，而 LGPL 应用相对容易一些。所以 VLC 在 Windows、Mac 和 Linux 上是 GPL，核心是 LGPL，但在 iOS 上，iPhone 版和 Apple TV 版使用的是另一种 license，叫 MPL。是的，我去改了 license，这是一段很长的故事。

是的。有一点非常重要：open source 项目在美国 copyright law 里被称为 joint work，在 civil law 里叫 collective works 或 collaborative works。也就是说，大家围绕同一个目标一起工作，最后形成一个软件，也就是一个 release。但 copyright 由所有个人保留。有些 open source 项目不是这样，它们强制做 copyright assignment，但我们不这么做。我们是 community。所以每个人基本上都对自己修改的部分拥有 copyright。即使最后你的 contribution 被删除了，这个 copyright 仍然存在，因为新的 contribution 是基于你之前的 contribution，对吧？所以如果你想正确地重新授权，就需要找到所有贡献者。那时候我必须联系 350 多个人。有时候，只有一个 email 地址，所以你需要真的追踪到人。我甚至真的去过一些地方，去找我在网上找到的人，到他们工作的地方说，你当时用这个 license 授权了，现在是否愿意从 GPL 改成 LGPL？大多数时候，他们甚至不太在意。他们只是想帮助 VLC。但这也让我遇到过非常复杂的情况。我到了一个人的工作地点，他是工厂工人。我说，我需要你签这个，因为真正写代码的是他的儿子，而他的儿子已经去世了，对吧？所以我必须解释这些 open source 的含义，说明我不是一家公司，不是想抢走那个孩子写的 2 行或 5 行代码；那些代码有用，而且整个 community 都同意这么做。他完全不知道这些事，他只是一个工厂工人。我当时也年轻得多，对吧？那是 14 年前，我几乎要哭出来。这非常困难，对吧？我们谈的是人的生活。我向他解释，然后我们还聊到了那个孩子的照片，对吧？所以以正确的方式、合规地做这件事很重要。但这确实意味着要追踪每一项贡献，因为每个 contribution 都有效。有些项目不尊重这一点，会比较强硬地重新授权。但正如我说的，那会毁掉 community 的核心，因为我们当初只是同意了这个 license，所以这很重要。

我们大多数人都是 introvert，对吧？你得更精确一点。这里有极度 introvert、极其极其 introvert，以及 introvert，对吧？就是一个由不同人构成的完整 spectrum。没关系。重要的是，你的代码好吗？你的代码优秀吗？你的技术好吗？我们在意的是优秀的代码。我们不在意你是谁。抱歉，事实就是这样，我们也没有办法核查。我们核查不了，对吧？也许你是一条狗，我不在乎，对吧？我不在乎你来自哪里。我需要看你的代码。这很重要，因为很多人不理解这一点。他们来到 community，提交一些 patch，结果被拒绝了，然后他们不喜欢。因为我只能说，抱歉，它没有达到我们的标准。有人会说，是啊，可我是意大利、德国、美国某家大公司的 engineer。我们不在乎。我们在乎的是你的代码质量，因为这定义了我们的 community。这也意味着，有很多背景非常不同的人在贡献，他们也许很 introvert，当然，但这没问题，对吧？

Linus 是很特别的人，对吧？我甚至会说，他在 Git 上做的事情，比他在 Linux kernel 上做的事情更有意思。他说话很严厉，但人们通常没有看到的是，他严厉对待的往往是 kernel 某一部分的 maintainer，对吧？所以他们认识他。他并不是对所有人都那样严厉。关键在于，他在自己房间里创造出来的东西，基本上支撑着线上每一台 server。即便是 Microsoft Cloud 也就是 Azure，我很确定 70-80% 的 server 都在跑 Linux。你们所有的 Android 手机也都在跑 Linux。他借助 open source 的力量做成的事，确实很了不起。而且是的，Linux kernel 的质量非常高。是的，这很难，但我们不能在这件事上妥协。我们不能在质量上妥协，因为到最后，你必须明白，VLC 的核心社区只有 5 个人。FFmpeg 的核心社区有 10 到 15 个人。而我们才是以后要维护你代码的人，对吧？因为时间线上有 1,000 个 contributor，最后只留下 10 个，也就是某个人来并留下来的概率只有 1%，1%。所以你会换工作、换妻子、有孩子、人生中遇到意外，你会换工作，等等，你大概率不会再回来。最可能的情况就是这样。所以将来维护你代码的是我们。它必须是可维护的。它必须是优秀的。是的，有时候这意味着你需要返工，因为它是好的，但还不够优秀。我们需要卓越，因为要由很少的人来维护对整体至关重要的东西。

这是真的。也因为比如我们做的是 low level 的东西，技术性极强。你进入这个社区后，语气会变得很像某种 subculture，对吧？所以从外部进来的人，基本上并不了解这个 subculture。FFmpeg 和 VLC 周围的大多数人，我们每年都会办 VideoLAN Dev Days，也就是 VDD。他们在线下其实非常有趣，也很喜欢这种氛围。但确实，在线上的时候，有时那种语气，你自己也意识不到听起来是什么样，不过这也还好。

但它很少会像你在 gaming 里看到的那种 insult，对吧？所以 Linus 的语气即便在 open source 社区里也有点不寻常。更像是对结果很严厉，说“不，这不行。这是垃圾。”你会看到的是这类话。

是的。

而且你还要意识到，大多数人的母语不是 English。尤其是像 FFmpeg 和 VLC 这样的 open source 项目，它们主要以 Europe 为中心。有时候来自 US 的人，或者类似背景的人，会对语气非常不满意，但很多时候也只是因为他们不知道更好的表达方式，对吧？这很难。English 是一门很难的语言，有很多细微差别、语气等等，这些你不一定掌握。所以在这类社区里，不同文化和语言也常常会带来困难。

是的，这在 Reddit 上几乎成了 meme，对吧？

是的。通常你会看到，大家会 tag 我，对吧？然后我出现，说一句“早上好”，就拿到 24k upvotes，这很好，对吧？我的 Reddit karma 很不错，至少那个账号是这样。所以这个问题首先需要回答的是：VLC 的故事是什么，对吧？因为是的，这是真的。我拒绝了数千万美元。是的，不止一次。是的，我本可以成为 multimillionaire，在某个海滩上待着。但我没有这么做，因为我认为那不道德，也不是正确的事情。对我自己来说，这一点非常重要：我是在为更大的善而工作。我为人们工作，而且我不想……这不只是我一个人的事。另一个原因是，我也不觉得自己完全有资格那样做。让我解释一下为什么。VLC 的故事非常奇怪。在 France，我们有 university，也有一种顶尖 college。这些顶尖的精英学校包括 engineering school、business school，基本上还有 law 和 medical，对吧？但它们在 university 之外。为了进入这些学校，你要花 2 年疯狂学习，学 math、physics，才能考进最好的 engineering school。其中一所学校叫 École Centrale Paris。后来它改名了，但当时叫 École Centrale Paris。因为它在市中心，World War II 后地方太小，所以必须搬迁。他们想把它搬到 France 中部一个叫 Clermont-Ferrand 的地方。校友们认为这不行，对吧？这是 Eiffel 就读过的学校，也就是建 Eiffel Tower 的那个人，对吧？所以他们说，不，不，我们是很优秀的 grande école，不能这样做。于是他们在 Paris 南部、离 Paris 很近的地方买了一块地。那是一个由校友 nonprofit 管理的 campus。明白吗？正因为如此，campus 上的一切都由学生管理。学校什么都不管，对吧？radio、TV、supermarket、library、决定谁住哪个房间，所有事情都由学生管理。

效果很好。我这辈子也从这些课外活动中学到了很多。因为你才 22 岁，却要负责管理校园，否则就没有电可用，所以你自然会在意这些事。总之，在 80 年代，他们做了一次完整实验，部署了一套 network，主要由 IBM 和 3Com 赞助，是一个 token ring network。所以 token ring 现在大概几乎没人知道了。它是一种 networking technology，没有 routers。所有人都连接在一起，真的像一个环。当你想发送消息时，你把消息发给邻居，邻居再传给下一个人，下一个人再继续传下去。就 ring 而言，Token Ring 的问题当然是非常慢，因为 network 上的每台 computer 都需要打开消息，看它是否正常，是不是发给我的？不是。然后再把它传回去，就像一个 token 在环上循环。在 80 年代，大学里做一些 Telnet、发邮件，这还可以。但到了 90 年代，video games 开始出现。而在 video games 里，如果 latency 很高，基本上就会死。所以在 1994、1995 年，Doom 和 Duke Nukem 出现前后，他们想要一个更快的 network。于是学生去找学校，说，我们想要更快的 network，我们需要用它工作，当然也玩 video games。学校基本上告诉他们，抱歉，我们帮不了你们，因为你们知道，campus 不属于我们，是你们在管理，所以你们自己想办法。你们可以去找学校的一些 partners。于是他们就走了，真的去找了 Bouygues 的 CIO。Bouygues 是一家大型法国公司，在法国做电视业务。他说，这样吧，video 的未来是 satellite。今天我们知道并不是这样，但至少在 1995 年，这是一个不错的想法，当时刚有 satellite dish。他说，与其给 1,500 名学生每人配一个 satellite dish 和一个大 decoder，不如你们架一个巨大的 dish，只用一个 decoder，然后把 video 直接发到 network 上。这需要一个非常快的 network。今天看起来很显然，但在当时，这几乎是最早做 video streaming 的尝试。所以他们做了这个项目，叫 Network 2000。当然，那是在 90 年代，所有未来感的东西都叫 2000。

于是他们做了 Network 2000 项目。它完全是 hack 出来的，45 秒后就会 crash。没关系，demo 只有 40 秒。它会 memory leak。也没关系，他们装了 64 megabytes 的 RAM，而当时一般只有 8 或 16。demo 本来应该到此为止。这就是学生们做的 Network 2000 项目。

MPEG-2，因为 satellite 当时用的是 MPEG-2 TS 做 transport，video 是 MPEG-2 video，audio 是 MPEG-2 audio。项目本来应该到这里就结束。大家都很高兴。他们有了很厉害的 ATM network，速度是 155 megabits per second。在当时，他们大概拥有欧洲最好的 network 之一，然后他们停止了这个项目。6 个月或一年后，有 2 个学生来了，说，也许其他人也会关心 local network 上的 video streaming，于是他们创建了 VideoLAN 项目。VideoLAN。其中一个人叫 Christophe Maciot，是 Kieran 和我的好朋友，他们启动了这个项目。当时甚至还不是 open source。他们花了大约 3 年时间，才让学校同意把它做成 open source。当然，因为学校想从中获得一些东西，基于学生的 IP 和 copyright，基本上想把这些 MPEG-2 decoders 商业化。

是在 local network 上 streaming。

比 YouTube 早 10 年。你当时用的是 Pentium 60 或 75。主流机器是 33 MHz 的 486 DX。

尤其是因为这是一所大学，里面有很多不同国籍的人。所以有很多人想要——最后他们有了好几个 dish，对准不同类型的 satellites。比如，很多人来自 Maghreb 或 Middle East，所以他们会去接入不同类型的 satellites。总之，这个 solution 运作得很好，他们也开始了 VideoLAN 项目。VideoLAN 项目包含几个部分，有些 solution 完全疯狂，比如如何在 unicast network 上创建 multicast。不过我们先不讲这个，太复杂了。VideoLAN 的 client 部分后来变成了 VLC。事实上，他们基本上是强行推动学校开源，因为学校并不理解这一点。2001 年仍然算很早，但学校在 2001 年初同意把它做成 open source。我是在 2003 年加入这个项目的，因为那时我进入了这所大学。所以第一点是，创建 VLC 的人不是我，因为实际上没有某一个人创建了它。

我在 2003 年加入，然后创建了名为 Videolan 的 open-source nonprofit organization，并把所有东西从大学里迁出来，把它做成一个 nonprofit project，一个可持续的项目。确实，我在 VLC 和 Videolan 上花的时间比任何人都多，这一点是肯定的。但它是前一个项目 Videolan，也就是学生项目的延续；而学生项目又是 Network 2000 项目的延续；再往前也是如此。

我可以告诉你，在 2005 年，这个项目本来应该已经死掉了。是我让它继续了下去。有一段时间，我们只有 2 个活跃开发者。我觉得这项技术很好，也很有用，而且以后还会有用。于是我把我的人生和时间都投入进去。我让它从几十万用户、几百万用户，发展到今天的规模：现在全世界可能有数十亿个 VLC 版本，几乎到处都在使用。这大概就是 VLC 的故事。围绕它还有很多很有意思的故事。来自世界各地的许多人都在参与，就像你说的，有人在叙利亚，也有人在印度偏远地区。但在这个过程中，我收到过好几次邀约，要么是把 toolbar 捆绑进去，对吧？你们应该还记得那些糟糕的 toolbar，基本上就是 spyware；要么是修改你的 web browser 或 search engine；甚至是在 VLC 里加入 advertisement。我不喜欢这些。人们不理解，这并不是因为我反对钱。我很愿意赚钱。我创办过几家 startup，其中一家我希望能发展得很好。事实是，我相信赚钱必须符合伦理。有正确的方式，也有错误的方式。偷偷塞 advertisement 或窃取 data 不是正确方式。比如，如果 Netflix 在某个时候来找我们说，我们想把 Netflix 放进 VLC，也许故事就会不一样。但他们没有。来找我们的只有一些不太正当的广告公司。如果我那么做，我会赚到很多钱。然后 3 年后，项目就没了。有人 fork 它，事情就会走向别的方向。

对我来说也是这样。很自私地说，我晚上要能上床睡觉，并且对自己做过的事感到安心。也许是我的成长环境，也许是我父母的影响，或者别的什么。但我相信有对和错。那在当时就是正确的决定。现在依然是。我想为自己所做的事感到骄傲。如果我出卖了它，我就背叛了很多其他人的工作。

并且能服务世界各地这么多人。这很重要。

我收到的最后一个报价高得离谱。他们说，是啊，但想象一下，有了这么多钱，你可以做一个新的 open source 项目，对吧？这种心理诱导很厉害，也确实很难。但对我来说，我只是觉得，不，这不是这么运作的，或者说这不是正确的事。所以我不做。再说一次，不是我不喜欢钱或怎样。只是那不对。

是的。

这里的问题是，发现问题的手段和修复问题的手段之间严重不对称，对吧？这就是最大的问题。那次风波之后，Google 做了一些改变。

他们现在也有了奖励修复 issue 的工具。所以因为那次风波，情况有所改变。这是好事，对吧？不过我们也看到过，虽然这里说的是 Google，但我们也见过其他一些大公司说，哦，你们必须修这个 bug，因为它在我们的产品里是 critical。

这是大型公司里的一个很大问题。我们现在说的是某些公司，但其实到处都一样，对吧？很多这类公司里，当我们和那个人沟通时，他只是 Microsoft Teams 某个项目里的 manager，对吧？他从来没有真正和 open source community 打过交道。他完全不知道，对吧？就是这样。但问题在于，通常这类公司里有我们所说的 OSPO，也就是 Open Source Program Office。它们本应负责和 open source vendor 或 open source community 沟通，但它们经常没有在内部正确解释这件事。这里的情况就是：我们不是你的 supplier。如果你希望我成为 supplier，我很乐意。我会给你发 contract 和 SLA。我围绕 open source project 创办过 5 家做这种事的公司。所以这没问题。

视频领域也是一样，对吧？举个很简单的例子。我们有一年多无法在 Android 上更新 VLC，因为 Android Play Store 有一个 bug。我们唯一能让人回应的方式，就是发一条很“辣”的 tweet，说我们要停止分发 VLC for Android。我们大约有 1 亿人在使用它。之后 Android 的人真的来找我们沟通了。我们和 Microsoft 也遇到过同样的问题，我们说要停止在 Windows Store 分发 VLC。可惜的是，我们太小了，解决这些问题时唯一真正有力的手段，就是在社交网络上公开指责，因为事情会滚雪球一样扩散，然后他们才会听我们说话。但这些大公司往往很难和我们沟通。比如 VLC，很可能是 Windows 上使用量排名前 10 的软件之一。但我不是 Microsoft ISV programs 的成员，我在 Microsoft 没有对接人。我相信其他任何软件，比如 Adobe、Spotify，都会有对接人。但我没有。所以提高认知是有用的。有时会很激烈，很多 drama。X 和 Twitter 很适合做这件事，而且很有效。

比如 Tim Sweeney、Carmack，还有其他一些非常高层的人，也在我们的 X 账号上提高了大家的认知，这也帮了很多忙。

Karpathy，是的。

在 VLC 里，最早期的贡献者之一叫 Félix。他负责 Mac 和 iOS 上的一切工作。他开始参与 VLC 的时候只有 16 岁。我们还有一个叫 Edward Wong 的人，以前是 Google Summer of Code 学生，后来在 VideoLAN 待了 3 年。他当时 14 岁。Google Summer of Code 和 Google Code-in 这些项目，基本上让我们有了学生和高中生，他们为 x264 和 VLC 写了大量 assembly，也为 FFmpeg 写了很多。所以每个人都可以贡献。

是的。

说实话，即便在 Google 也是这样。Google 是一个实体，但里面有很多不同的人。我们一直和许多 Google 工程师合作。即便从 YouTube 到 Chrome，再到 Chrome Media，以及 Google 的其他部分，它们也都是非常不同的实体。我们的做法是有效的。比如 Theo 那件事，确实有点走得太远了。我让大家冷静下来，也和他通了电话。我们说，好，这样有点过头了，等等。但最终，虽然像一场 rap battle，它对项目是正面的。过去 2 年，我们在 open source 上的认知度大幅提升，我指的是来自社区的真正 open source，而不是别的。这是有用的。

驱动力有很多，但有点奇怪的是，最主要的一个，是我们在 multimedia 领域做的事情是在播放视频，而视频很酷。比如，社区里有很多人最初加入，是因为他们喜欢看 anime。这也是别人问我“我该在 open source 里做什么？我该怎么开始？”时，我给的建议。我的回答总是一样：做你热爱的东西。我做 VLC，是因为我喜欢电影。我喜欢一遍又一遍看同一部电影，尽管我妻子会因此讨厌我。但这是因为它有意思，因为这是你喜欢的话题。通常来说，这是人们来到 VLC 和 FFmpeg 的第一层原因。第二层原因是，从技术上讲，因为我们追求卓越，这里是最好的学校。这是最好的编程学校。如果你在 FFmpeg 里擅长 C，如果你知道怎么写 assembly，那你很可能会成为最优秀的程序员之一。哪怕你后来做的是写 TypeScript，因为这仍然是最了不起的训练。你会不得不接受一些最资深程序员的 review，他们会看你代码的每一个部分，并告诉你为什么它还不够好。我们就像是你在编程上遇到过的最好的老师。

multimedia 里还有一点很有意思：你只有 16 milliseconds 来显示一帧。它不像 game engine，你基本上可以放慢一点，等一帧。所以你必须做得好，没有别的选择，否则视频就播不出来。而且因为 codecs 的机制，如果你漏掉一帧，就会破坏视频的观感。所以你必须做得好。你必须做到完美，才能得到正确的结果。但它也不只是数学意义上的纯编程。很多人不理解，在 open source multimedia community 里要正确编程，你需要理解计算机是如何工作的。写 assembly 的时候，你需要理解 CPU pipelining；你需要理解 SIMD 如何工作，ALU 如何工作；你需要理解 I/O 如何工作。我认为今天很多工程师和 software engineers 缺少的，正是对我们所说的 computer architecture 的理解。说真的，有些讨论会是：我们应该用这个 assembly call，还是那个？然后有人会说，不行，在这种 CPU 上它会是 3 cycles，而另一个会怎样。它会对输出产生很大影响。

所以，一开始你来，是因为这个主题有意思；然后你留下来，是因为它追求卓越；最后，你会为它感到非常自豪，因为它在每个人的终端上。很多人会说，哦，我在某某咨询公司工作，做一个给 PG&E 下载发票的 portal。哇，很好。很多工作都是这样的。你不会拿这件事去告诉你奶奶。但如果你去见奶奶，说我做的东西让你能在 laptop 上播放视频，她能理解。这很重要。因为你在做 VLC、FFmpeg、x264。它最终会到达数亿人手里，你产生了影响。所以你可以为自己感到自豪。我认为，除了它能让简历很好看之外，这些都是人们贡献的原因。

是的。Linus 用 2 周做出了 Git。是啊，很厉害。

但对我来说，这不只是 software 里的事。我相信会有 individual 改变世界。而且就像你说的，要有好的 vision。我想做这件事。它有用。它会有用。不管是建火车、汽车、火箭，还是别的什么，我相信那些相信自己并且有 vision 的人，能够对人类产生巨大影响。

是的。

而当你开始做物理计算时，那就是一场噩梦，对吧。

是的。

如果你看一下，会发现有非常多 libraries，对吧？

而且还有很多。最近我们可能会聊到的 David 项目，是 Videolan 最新的项目之一，它无处不在。最近我们还宣布了 libspatialaudio。我们有 CheckISM，这是一个很夸张但很棒的项目。所以 x264 也是这些 VideoLAN 项目之一。在我看来，比如说，x264 是有史以来设计得最出色的 encoder。这也帮助了 FFmpeg 的采用。很多人和大型公司开始使用 FFmpeg，是因为他们想使用 x264；x264 提升了 FFmpeg 的流行度。同时 VLC 也因为能播放很多由 FFmpeg 生成的文件而变得流行。所以很多项目是相互交织、共同工作的。

给你一个概念：当我为 Windows 编译 VLC 时，我大概要编译 1600 万行代码。其中 100 万行在 VLC repository 里，而 FFmpeg 总共大概是 200 万行左右。这意味着很多 dependencies 都在外部。而且如果你单看 FFmpeg 本身，FFmpeg 也在集成 third-party libraries，比如 x264、libopus，以及许多其他库。它们彼此都互相依赖。

VLC 1.0 就是在那个时期发布的，2009、2010 年左右。也就是那时它真正爆发了。

实际上，那些 codec packs 基本上就是 VLC 里的 FFmpeg，再加上我们用于各种 codec 类型的其他 modules。

我们来谈谈这位很厉害的乌克兰人 Kostya。当时他住在德国，而且很喜欢 Sweden。这个人非常聪明，社区里很多人都很聪明，而他属于接近天才的那种。他能够 reverse engineer 极其复杂的 codec。他确实做到了。我们也和 Kieran 做一些工程工作，但显然不在这个层级。他 reverse-engineer 的是 binary blob，有 20 megabytes？

而且他是为了好玩才做的。GoToMeeting 曾经是 VLC 的一个大问题，因为很长一段时间里，这大概是头号 feature request。我挂了一个 bounty。后来有一天他说，好的，JB，我来做。两个月之内他就做出来了，然后还解释了他是怎么做的。他说得很轻松，比如“我看这段 code 像是我以前在 WMV 里见过的 DCT”之类的。他就这样完成了。最有意思的是，他写的 code 里有大量笑话。里面有很多关于 JB，也就是我的名字、Kempf，还有 Kostya 的笑话。Kudi 写得很漂亮。

在这个社区里，最让人佩服的一些人，就是做 reverse engineering 的，以及那些写 assembly 的人。这两类人都很出色。比如 x264 之所以后来非常强，很大程度上是因为一个叫 Loren Merritt 的人，他好像来自 University of Washington。

他让一切都变得很好、很快，写了大量 assembly。可以说那是一个黄金时代，很多事情都在那时完成了。

这可能很容易。

我记得通常会有 GoToMeeting 4、5、2、3、4，好像是 2、3、4。对。

这点很关键。因为 GoToMeeting 现在已经不是很多人知道的东西了。大家知道 Zoom、Teams 等等。但我们快进 10 年、15 年来看，这就是一个 Windows 32 bits 的 GoToMeeting.exe。你会说，可我在 Android 上，我在 iPad 上，我在别的地方。那你要怎么做？我可能在 RISC-V、arm 上。这些都被挡住了，但未来我们还需要支持大量文件。这就是为什么这类工作对人类特别有用。

Kieran 太谦虚了，其实 Kieran 也做过一些 reverse engineering。

你看，这已经很离谱了。然后你再去看 GoToMeeting，那就是……

想象一下复杂度再高两个数量级。一个人独自在德国某处做这件事。而且很长一段时间里，你都在一个 black box 里工作，因为 decoder 有太多步骤，从 entropy decoding、intra prediction、motion prediction、IDCT 等等，在很长时间里你什么都看不到。所以你完全是在 memory 里 debug。

而且你是在几十 MB、几百万条指令的 binaries 上做这些，对吧？

在 CPU 层面暂停程序。

有时候你还得在 VM 里，这样才能暂停 VM。

我 2003 年进 École Centrale Paris 的时候，Jon Lesh-Johansson 基本上破解了 DVD specification，并向我们展示他如何破解 Apple 的 MP4 FairPlay DRM。他当时就在自己的 laptop 上做这件事。我那时很年轻，21 岁，真的很震撼，因为他基本上是在某种 VM 里调试 Windows。

很长一段时间我都是：我需要这个 codec，我需要那个 codec。

RealAudio、RealVideo，对吧？那在当时非常重要。

而且他是那种特别好的人。比如我现在在做的 startup 叫 Kyber。我认识 Yuri，是因为每年在 Denver 的 Mile High Video conference 都会见到他。他给了我很多很好的想法和建议。他真的是很棒的人。

点进去就能看到所有 tests。Test back。All tests successful。

你能看到 PowerPC、RISC、ARM。

还能看到 Visual Studio、不同版本的 GNOME、OpenSUSE。

对我来说，我们的一些头痛问题来自某些很难支持的 OS。你看 VLC，得益于 FATE 和 FFmpeg，最新版 VLC 可以运行在 Windows XP 上，而且现在仍然能跑，也能运行在 Windows 11 上。我们支持从 macOS 10.7 到最新的 macOS，不管现在是多少，26。我们从 iOS 9 开始支持 iOS，现在其实已经到 iOS 26 了。我们支持很多类型的 Linux、BSD、Solaris。最新版甚至还能跑在 OS/2 上。全世界可能只有 10 个 OS/2 用户，其中一个还在维护 VLC。然后你就会意识到，VLC 周围这个很小的团队，使用 FFmpeg codecs 和其他组件，支持的 OS 比 Microsoft、Google 或 Apple 还多，而它们拥有几乎无限的能力和资源。比如最糟糕的是 iOS。为了在 iOS 9 上构建，我们需要非常巧妙地混合多个版本的 Apple Xcode IDE 和 SDK，把几个版本拼成一种 Frankenstein 版本，这样才能继续支持 iOS 9。Apple 的 compiler 已经完全不支持它了，但我们还要让 ARM32 在 iOS 9 上运行。你在 FATE 上也看到过，它仍然支持 iOS 9。所以我的头痛主要来自支持这么多 OS。这很重要，因为我们收到很多人的反馈，说谢谢，我还有一台 iPad 2 用来看电影，它还停在 iOS 9，但还能用。这也关系到一个影响：不要在硬件明明还能正常工作时强迫人们购买新硬件。只要正确优化，它就能工作得很好。这也把我们带回刚才说的 assembly。它也是在对抗一种趋势：你被不断要求买新东西，但其实本可以通过更多优化来延长使用寿命，而这已经成了一门失落的技艺。

这是必要的。

对吧？比如有一个我们需要谈到的项目，叫 David。David 是一个 decoder，用于 Alliance for Open Media 制定的格式，也就是一个叫 AV1 的 video decoder。

当这个格式推出时，很多人都说，尤其甚至包括 Alliance for Open Media 的人，也就是 Google、Netflix、Amazon、Mozilla，他们说，这个格式太复杂了，decoding 必须用 hardware 来做。然后我和另外几个人加入进来，主要是 Ronald、Henrik 和 Martin。我们说，必须有一个极其优秀的 software decoder，因为 hardware 普及需要时间。所以我们写了这个项目，它的规模非常夸张。我们说的不是 30,000 行 C，而是 240,000 行手写 assembly。

给你一个概念，Kieran 可以纠正我，但我认为 FFmpeg 为所有 codec 写了 100,000 行 assembly。是所有 codec。而仅这一个就有 240,000 行。当然，这是一个 VideoLAN project，并且已经做到了最大程度的优化，因为我们启动这个项目时的口号是“every cycle matters”，对吧？每一个 cycle 都很重要，因为 dav1d 被用于 VLC，也被用于一些软件 AV1 playback stack。我们说的可能是 30 亿台设备，它们会不停地 decode video，因为比如说，Netflix 现在 30% 的视频都是 AV1。YouTube 可能有 50%，对吧？而且你通常没有 hardware decoder，因为拥有 hardware decoder 的设备并不多。通过 dav1d，我们发现只用一两个 core 就能正确 decode 720p。所以这确实很不可思议，对吧？

不可思议的是，这些 tweet 讲的是事实，但人们会很激动。他们不高兴，对吧？

他们会说，你们不能优化 compiler。auto-vectorization 的问题是你们的错。你们不懂。我们已经试过很多年了。结束了，对吧？

是的。

他们告诉我们的两件事是：是啊，但现代 compiler 有 auto-vectorization，对吧？因为我们做的 SIMD 就是 vectorization。但这根本不是一个量级，对吧？完全不是。不是慢 5%、10% 那种，而是慢好几倍。

从哲学层面看，重要的是要意识到，hardware 速度飞速提升的时代已经过去了，对吧？我们处在 Moore's Law 的末期，在 AI、memory 等方面都有限制。你需要往 stack 更底层走，做更多优化，才能从现有资源里榨出更多能力。因为我们对算力、CPU power、GPU power 的需求正在爆炸式增长，而 hardware 的速度并没有同样爆炸式增长，对吧？所以人们会增加更多 core，对吧？但这基本上意味着，到某个时候你可能会有 250 个 core，对吧？而我们做的是利用机器的每一寸能力。

我们在 dav1d 里做的另一件有点疯狂的事是，我们不使用 operating system 的 function calling convention。

这非常复杂，但基本上，通常当你在代码里从一个 function 跳到另一个 function 时，会有一种方式来保存 register，也就是 CPU 的 state，然后进入另一个 function。这是标准做法。

是的。在所有这些里面，为了更快，我们甚至不遵守 operating system 的 calling convention，因为我们知道调用会来自我们的 binary 内部，所以我们可以共享 data，而不用按通用方式保存所有 register，因为那会导致在 L1 和 L2 CPU 上加载和保存 register，而我们这样可以更快。所以这就是为什么我说理解 CPU architecture、computer architecture 是关键。这也是为什么它是 handwritten 的。我不知道还有谁，我从没听说过除 dav1d 以外还有哪个项目会这么做。这就是 Kieran 所说的 art，对吧？它是一门 art。

因为你可以从每一美元投入中获得更多算力，或者说更多性能。有时候问题会受限于硬件。一个很好的类比是你在 LLM 的 quantization 中看到的情况。人们会说，我要用 FP8、FP4，或者像 Microsoft Phi 那样用 1.5 这种很激进的做法，因为你受内存限制，受能运行的机器限制，因为到某个阶段我们是在做 real time。我相信这也会发生在 AI inference 上：到某个时候你需要更快，但你不可能总是拿到更强、更有力的硬件。所以你需要能够分析代码，看看 mission critical 的部分在哪里，哪些东西会被不停调用。比如 David 就是一个很好的例子，它每天会运行数十亿小时。在那里这么做是有意义的。把它放在 FFmpeg CLI 的 glue 上是不合理的，在那个地方做底层优化才合理。

当你在某个维度上受到极强约束时，我们也正到达一个阶段：我们已经做了很多很好的事情，但硬件限制又回来了。因为成本在上升，因为我们需要更多算力。所以你会受限于 CPU、RAM 或 networking，你需要优化。这就是价值所在，尤其是因为 AI 会帮助完成 business 层面的编程。而你无法用 vibe code 完成的核心事情，就是针对硬件做优化，让它尽可能快。

没有足够的数据可以用来训练。这是最大的问题。我的职业生涯其实是从给 Itanium 写一些 assembly 开始的。Itanium 是一种已经消亡的处理器类型，是很久以前 Intel 和 HP 在想做 64 位时推出的。后来他们输了，AMD 做成了这件事，AMD64 后来变成了 x64。但 Itanium 非常有意思，因为这类处理器有大量算力用来做浮点运算、FMA，这和我们现在做 LLM 所需要的东西很类似。你可以在每一行里打包 3 个可加载的操作。也就是说，它基本上每秒可以输出 60 亿次操作，但 bus、memory bus 只允许 15 亿次。所以 CPU 快了 4 倍。于是你必须做很多复杂的事情，把数据打包到内存里，复用 register，以及处理这类语义；没有语言能做到这一点。我有那本 Itanium programming book，因为 Intel 当年写了很好的书，但这正是 Kieran 说的：如果你不知道自己要做什么，那本书根本读不下去。里面全是术语等等。但这些经验非常好，因为它们面向真实问题，而且你可以自己动手做。

这很棒。课程里有一部分用到了一个叫 x86inc 的 framework，是 Loren Rüthen 在做 x264 时写的。它允许你做更多这类事情，形成一种不必太关心不同 calling convention 的方式。很久以前，我们有很多学生用它给 x264 提交代码。所以这真的可行。我认为有必要理解 assembly language，哪怕你不常写，也要理解计算机内部发生了什么。这会让你成为更好的程序员。我可以保证，因为做这些事会让你理解计算机内部的一些 memory architecture。理解 register、L1、L2、L3、RAM、SSD、disk 等等，这些都非常重要，因为它会给你良好的编程素养，让你成为更好的程序员。

我和 Kieran 的看法很不一样。

我写过很多 Rust，我遇到的两个主要话题是把 Rust modules 加进 VLC。VLC 之所以流行，其中一个原因，也是它主要的 architecture decision 之一，是 VLC 有一个非常小的 core，以及大量 modules。你可以用 C、C++、Objective-C，以及任何基本上能和 C interoperable 的东西来写 modules。所以我们做过一些 Rust modules。我在这方面有经验，也写过其中一些。另外，我的新 startup 叫 Kyber，是一个 open-source project，主要用 Rust 写。Rust 非常擅长的一点是，它是一个更好的 C++，关心 memory，并且允许你处理 memory ownership，这是目前其他东西还做不到的。不过，当你从零开始一个新项目，并且所有东西都用 Rust 写时，它很好；但当你要和现有部分交互时，它就很不好。Rust 社区里有一部分人认为他们需要重写一切，然后一切都会因为 Rust 变得更好。答案是否定的。以我这么多年做 engineer、manager、startup CTO 等等的经验来看，几乎总是：不要重写。

原因是这样的，这一点很重要。写代码比读代码容易一个数量级。你在 LLM 上也能看到这一点，它们可以写代码，但分析代码要困难得多。所以当你接手一段非常复杂的代码时，你并不理解它。因为理解别人写的代码要花多得多的力气，因为你没有当时的源头和过程。我经常拿一些语言开玩笑，主要是 Perl，比如它的语法很复杂。设想我在编程时处于最高智力效率，写出了有史以来最好的代码。6 个月后我也未必能理解自己写的东西。因为读代码更难。所以很多时候你接手时，并不了解其中所有经验、业务逻辑，以及当初这么做的原因，这些可能也没有文档。于是你会说，那我重写吧。但问题是，不，你不该这么做。就像 Kieran 说的，我要用 Rust 重写 core utils。然后当然，你很快能做到 80%，再到 90% 会多花一点时间，最后剩下的部分就很难了。另一方面，对于新项目来说，Rust 很好。所有和解析文件、网络相关的东西，因为 memory checker、borrow checker，确实很好，没有别的语言能比。换个角度回答我们的问题，假设我拿 David 或 x264 这样一段软件，它有大量 runtime 是 assembly 写的。我把 C 部分用 Rust 重写，所以更安全，是的。但接下来你进入 assembly，而你可以跳到内存中的任何地方，因为我们写的是手写 assembly。所以即使用 Rust 出于安全原因重写 C 部分，只要写了手写 assembly，所有安全性都会被打破，因为我们可以跳到任何地方。因此在我看来，我们需要做一种安全的 assembly。也就是在 compile time 检查 assembly，类似我们在 David 和 x86world 与 Videolan 做的 check assembly 项目，在 compile time 开始对 assembly 做 instrumentation，检查它不会跳到内存中的任意位置。否则你也许用 Rust 重写了一部分 C，但如果你想保持同样的 performance，就会有 inline assembly，于是整个 security model 都被破坏了。这大概就是我对 Rust 的看法。

在社区里，我想提两个人，他们是 assembly 方面的高手。这两个人实际上都在北欧工作和生活，一个在瑞典，一个在芬兰。Henrik Gramner 对 Intel x86 assembly 的了解非常深，以至于我们向 Intel 问问题时，他们会说，你们为什么来问 Intel？你们有 Henrik。Henrik 更懂。他知道几乎所有 CPU generation 上几乎所有 SIMD instruction 的 cycle。比如，这是 P4，这是 Nehalem，这是 Core 2，等等。这个人可能是世界上最懂 assembly 的人，而且他也是你见过的最友善的人之一，非常低调。他来了你都看不出来，但他非常厉害。另一个叫 Martin，Martin Storrsjo，他主要在 ARM 上做类似的事情，也就是 Neon，以及 iPhone、Android 等。他会在手机上写 assembly，用那种很难用的 virtual keyboard 编辑，同时看着自己的孩子在 playground 里玩。这就是 wizard level。所以这两个人就是——

是的。在 open source project 里，有时大家会有分歧。

好处是，因为 license 的存在，你基本上可以自己做一个。这很正常，而且一直在发生。比如当年 GCC 2 和 EGCS，后来 EGCS 变成了 GCC 3。还有 khtml、WebKit、Blink 这一系列。这是一个正常的过程。而且比如我今天想在 VLC 里做一个新 feature，我会 fork，自己做，然后再 merge 回社区。所以 FFmpeg 的 open source community 当时出现了一次分裂，变成了 libav1 和 FFmpeg。几年之后，社区又合并回来，大家继续往前走。这种 drama 在 open source community 里很正常，但 fork 甚至是重要的，因为它会改变一个社区的 status quo。这里不具体谈 FFmpeg 和 libav1，但 GCC 的 fork 让 GCC 变好了很多，因为有些人想从根本上改变 architecture，让它更快。当然，这里面总是有人和人的问题等等。但最终你会发现，今天的 FFmpeg 比 fork 之前更好。现在我们又都回到一起了。Keanu 可以证明，我在社区里花了很多时间。说实话，这些事情往往没有被解释得很清楚，因为很多原因并不公开。但我认为这是正常的，也是好的。

对我来说，fork 当时确实像是一场激烈的争端，但 libav 的大部分开发成果后来都合并回了 FFmpeg，对吧？所以事实上，FFmpeg 围绕 libav 获得了一个更大的功能超集。最终我们是为用户工作的，这给了用户更多功能，也让很多曾经讨论过的问题有了结果。比如关于 review 以及代码如何 push 的争论，现在在 FFmpeg 里已经完全稳定下来，基本遵循社区里大多数人认可的方式。事实上，所有曾经活跃在 libav 的人都回到了 FFmpeg，因为分歧已经被解决了。最终，FFmpeg 比以前更强了。大家当然喜欢看戏，但——

是的，但这不只是 fork 的问题。你提到的，其实是当今 open source 里最具挑战、也最有意思的问题之一：maintainer burnout。而 AI 在这方面是个问题。Daniel Steinberg 是 cURL 的 maintainer，可能也是世界上最出色的 open source 推广者之一。顺便说一下，他和我一样是 European Open Source Academy 的成员，所以能和他在同一个社区里，我很荣幸。他反对他所谓的 AI slop，因为它会带来大量虚假 report、糟糕 report、糟糕 patch。于是很多 maintainer 在维护软件时负担变得很重。这比 fork 更加消耗 open source developer 的心力。比如 XZ 事件，就是因为只有一个人在维护它，而他基本上被两个攻击者不停“轰炸”——在夜里各种奇怪的时间不断问他问题，试图拖住他。到某个时刻他受不了了，说，好吧，我做不了这个，然后把 commit access 给了攻击者。所以 open source community 里的 burnout 确实存在，但主要是维护工作的负担。

比如现在，我作为 maintainer 维护着大量 multimedia 和非 multimedia library，因为原来的 maintainer 已经受够了。有些在 Videolan 里，有些在 Videolan 外。因为有时你需要很厚的脸皮。你会不断收到类似“这个不工作，那个不工作”的反馈。它未必真的是攻击，但你会把它当成个人层面的事情去感受。这也是为什么资源问题，或者 Google 那次风波会成为问题。他们没有意识到，最终你看到的其实就是那张图：一切都在上面，而底下只有一个随机的 open source project 在支撑整个互联网。你知道我说的是哪张图。

而 FFmpeg 或 VLC，其实已经不算最糟糕的 open source project 了，因为它们有一个 10 到 15 名 core developer 的社区。XZ 安装范围更广，却只有一个人，对吧？就是一个人。

对，LibXML。之前有 Bixtop，现在已经没人维护 XML 了，而它几乎是唯一能在各处 parse XML 的 library。

还有一个人负责维护所有人的 time zone，他好像住在 Nebraska 还是 South Dakota 中部。open source maintainer 的心理健康，是大公司不关心，或者看不见的东西。它们只会说，好吧，我就是提交一个 open source report 之类的。

举个例子，我在 Videolan 收到过死亡威胁。

大概是 2009、2010 年。Apple 正在从 PowerPC 转向 Core Duo，那可能是 2006 年的事。到 2009 或 2010 年，我决定不再为 PowerPC 做新版 VLC。当时 VLC 接近 1.0 release，我们只有 4 个人。我们只能说，不，这不可能继续。所以我收到了一封死亡威胁信，里面还夹着一些粉末。你记得那时有一些 anthrax 威胁，对吧？原因就是我决定不再维护 PowerPC port。当然那不是 anthrax，当然只是某种粉末之类的。但我收到的信大意是：你这个垃圾，你该死，PowerPC 永远之类的。那是 2009 或 2010 年。我还年轻，当时只觉得，为什么？我做了什么？

我母亲吓坏了。我们不得不去找警察。现在我会说，我还挺庆幸这件事发生在那个时候。它在很大程度上塑造了我。我现在可以承受很多针对我的仇恨，我没问题。

我在 Reddit 上看到一个关于我的 meme，其中有一点我还挺喜欢的，虽然这个 meme 本身我有很多理由不喜欢。有人说，哦，JB 在 Reddit 上，而我确实在，对吧？然后我说了句 hello。接着很多人说，哦，谢谢你做了 VLC。我就截图，然后分享到 Signal、IRC。是的，我们在不同的——

当然。是的。

当然。

用得挺好。

老实说，和 Slack 相比，最大的问题是它没有 threads。这点很烦。也没有用 emoji 做 reaction。有时候其实会很方便。

是，V3 有，但没人用。而且你不能编辑自己的消息。除此之外，对我做的事情来说，它完全够用。

所以我才说这是给老年人用的。

我们用那种冒号之类的东西来做 emoji。对，就是那样。括号，对吧？

我们刚才在说死亡威胁，不过也说到有人感谢你。有时候有人给我发消息说，哦，谢谢你做了 VLC。我总是会回复，因为我想确认这样一件事：你应该感谢 open community。

是的，这很重要。就像我们刚才说的，我们做 tech，我们做的是对普通人来说非常复杂的事情。我们希望自己在 tech 上追求的 excellence 能对所有人有用。这就是我们工作的原因，对吧？这就是我每天早上起床的原因：我希望人们使用我们的东西，因为它能让每个人的生活更轻松。

我们是 engineers。我们喜欢造东西，对吧？我很小的时候就知道自己想成为 engineer。我想做汽车，对吧？也许某一天我会回去做汽车。但本质上，我们想做又酷又有用的东西，而且它们需要有挑战，因为你希望自己的大脑被调动起来。

你第一次写程序是什么时候？Kieran？

我好像也是先写 BASIC，然后是 Turbo Pascal，那时大概是小学快毕业的时候。但我第一次真正做比较严肃的 programming，主要是在第一年，你们叫 middle school 吧，11 岁的时候？我在意大利住了一年，在佛罗伦萨，那一年很棒。数学老师让我们用一种叫 Logo 的 programming language，当中有一只 turtle，会在屏幕上画东西，你可以让它左转右转。到最后，我们用它做了很复杂的 programming，因为当然可以做很多东西。这件事改变了我，我知道自己想用计算机做事情，想写程序。

是的。

很好。还有另一个 sample，是 Planet Earth 的 Kila sample。我特别喜欢这个，你马上就会明白原因。画面里有大量鸟在飞，对吧？而且越往后鸟越多。到最后，几乎像是有几百万只鸟。这大概是最难 encode 的内容之一。你在 YouTube 上看，就会发现 YouTube 的 encoding 实际上有多糟。这个 sample 非常适合用来做优化，在 constant bitrate 下做到完美质量。Laurent 也做了很多优化，尤其是针对 anime。很长一段时间里，anime 的 encoding 都很差，因为会有大量 banding。你能看到那些问题，也能看到很多其他问题。所以 x264 是……直到今天，它仍然是任何新 encoder 的参照对象，AV1、AV2、VVC、HEVC，所有人都会拿它和 x264 比。

x264 也是 open source project 的另一个例子。它最初是 Laurent Eymard 在 l'École Centrale Paris 时发起的，VLC 也诞生在那里。之后出现了一代人，比如 Laurent、Jason、Mons，还有很多人——

Henrik。

还有 Anton。我们现在在 FFmpeg 上使用的 assembly 体系，包括 David 等，也是在这里诞生的。所以 x264 是一个很了不起的项目，参与者真的来自世界各地，而且我想他们大多数人从来没见过彼此。

我看过很多 anime，尤其是在那个时期。当时很多 anime 内容并没有商业发行，对吧？那是在 Crunchyroll 之前。所以通常的情况是，喜欢 anime 的人会从日本拿到一些 DVD，然后 rip 出来，因为没有商业渠道。有些人就是我们说的 fansubbers，基本上是自己翻译并制作 subtitles。那时候下载完全是非法的，但那也是唯一办法。所有这些都是手工做的，也很符合 open source community 的文化，因为他们需要工具来 encode，来做 fan subbing。字幕领域最了不起的 open source project 之一叫 AEGsub，它是一个 subtitle 工具，主要是为 anime，以及南亚和日本语言做的。

对，它的制作方式不是……很长一段时间以来，它基本上是在屏幕上制作的。你会有很多颜色上的 gradients，因为用数字方式很容易做出来，但在现实拍摄里很复杂。字幕也很复杂，因为你常常需要有日文，然后还需要 diacritics，也就是我们说的 ruby，也就是给 kanji 标注的 hiragana 和 katakana。当然，你会有官方字幕，但你还需要英文字幕或法文字幕，因为你想学习，对吧？字幕里有很多非常复杂的东西，我们也见过各种很夸张的 subtitle samples。所以这是文化中很重要的一部分，同时也是因为当时没有官方供给，没有别的办法。

说实话，从 MPEG-2 video 以来，所有这些 codecs 的核心概念都是一样的：inverse transform、intra prediction、motion compensation，都是这些。不过每一代都会在相同质量下带来 25% 到 50% 的压缩提升。所以先有 MPEG-2，然后是 DivX 时代，再到 H.264，这是一个很大的变化。H.264 的提升非常明显。之后又有更多东西，比如 HEVC；同一时期还有 VP9。VP9 在压缩质量上有点类似 HEVC，但它是 royalty-free 的，因为 multimedia 领域有大量 patents，而 H.264 之后的 licensing 变得失控了，每年可能要花数亿美元，所以这不合理。因此 Google 做了 VP9，Alliance for Open Media 做了一个新的 codec，叫 AV1。你可以理解为，在同样的 visual quality 下，AV1 相比 H.264 可以节省大约 40% 到 60% 的 bandwidth。

对，在给定 bitrate 下。也就是说，你可以固定 bitrate，提高质量；或者固定质量，降低 bitrate。但现在从 SD 到 HD，从 HD 到 4K，再从 4K 到 4K HDR、HDR，画面规模会扩大 2 倍、3 倍、4 倍。所以你必须有更好的压缩，才能让它保持在可管理的范围内。

这更复杂，因为 encoder 需要搜索更多可能性，对吧？比如，有一件事比较容易理解：要预测一个 block，一个色块到另一个色块，你有方向，对吧？可以向左、向右、向下、向上，然后还有其他象限，我称为 northeast、northwest 等等，对吧？但这就是 8 个方向。然后你还可以做更多方向，可以做 16、69 或 128 个，对吧？每增加一次，你的 encoder 都要花更多时间去判断：这些 block 正好是这个；以及你能引入哪些工具，而 encoder 需要检查哪些工具能让压缩效果更好。所以我猜 AV1 encoding 在 CPU cycle 上比 H.264 高 2 个数量级，对吧？数量级。

但还有一个事实是，你只 encode 一次，却有数亿用户，对吧？比如 YouTube 就是很好的例子。YouTube 几乎所有内容都用 H.264 encode，但热门视频会被重新 encode 成 AV1，因为 encode 的成本当然更高，但你 encode 一次，就把它发送给几百万人，对吧？所以这是 server 端的 encoding 时间、复杂度和 CPU 使用量，以及 client 端之间的权衡。因为最终，如果你把一个视频分发给几十万人，而它的大小只有另一个的一半，那就更好。对你的 battery 更好，对你的 modem 更好，等等。

这就是我们说的 intra-only codecs，对吧？我快速解释一下什么是 IPB frames。

I-frames，通常也叫 keyframes，是完整 frames。它就像一张 image，是一个 JPEG，对吧？你可以从这里开始，能看到所有内容，对吧？然后下一张 image 可以是 P-frame，也就是 predicted frame。你会取 previous image 的某些部分，比如说我需要 block 5、7 和 42，然后替换它，之后只提供额外信息，对吧？但这意味着，为了 decode 这个 P-frame，你需要访问 previous I-frame，对吧？当然还有更复杂的，也就是 B-frames，即 B-predicted frames，它们可以依赖不同类型的 frames，有些在过去，有些在未来。所以 ProRes 是 intra-only codec。给能看到的人看，这张图很好，对吧？I-frames 是完整 frames。P-frame 基本上只依赖 I-frame，而 B-frames 可以依赖前面的内容。

几秒钟，也就是说。

你甚至可以有一种方式，我们在 Kyber 上大量使用，叫 intra-refresh，基本上就是没有 iframe。

但你永远没有一个 iframe。这就是我们用的 intra-refresh，对吧？但对我来说，刚开始时最让我震惊的是 B-frames。B-frames 意味着 B-predicted frames 可以依赖未来才会出现的 frames。这意味着为了 decode 这个 B-frame，你需要等待下一个它依赖的 frame。先 decode 那个 frame，然后才能 decode 这个 B-frame，对吧？所以你 decode frame 的顺序，也就是 decoding order，并不等于 display order，对吧？这意味着 encoder 必须非常聪明，决定说，我要依赖未来的东西。所以这很让人震撼。

是的。夸张的是，很多人的工作就是优化这些参数，对吧？你在 YouTube、Netflix、Meta 等公司看到的很多人，并不是在写 codecs。他们只是在为手里的 file、手里的 format 找合适的 parameters，对吧？因为电影、来自手机的 user-generated content、screen recording，或者你要拿去 video edit 的东西，你想要的都不一样。有成千上万人的工作就是优化这些。

其实这很有意思，因为 Google Video，也就是他们收购 YouTube 之前做的东西，实际上用的是 VLC plugin，这样你就可以通过 ActiveX plugin 在 web browser 里运行 VLC，所以它能在 Internet Explorer 里工作，你实际上是在 browser 里运行 VLC。这很有趣，因为今天我们反过来了：我们有 VLC WebAssembly，把整个 VLC 和 FFmpeg 编译出来用于 decode，在 JavaScript virtual machine 里通过 WebAssembly 运行 VLC。

是的，没错。

这件事当时很意外。因为 WikiLeaks 某个时候提到了一些文件，其中有几份和 Blu-ray、VLC 有关，但最有意思的是 CIA Vault 7。如果我理解得没错，CIA 有一个定制版 VLC，里面有一个特定的 plugin。对，就是这样。当时我们还不得不为这件事写了一份新闻稿。

那是一个定向广告，意思是说你要观看某个特定文件，就需要用这个定制版 VLC。它用的是正常的 VLC binaries，只是他们加了一个 DLL。我记得是 psapi.dll，它基本上会读取你的 document 文件夹，把内容加密，然后发送出去。老实说，这个做法很聪明。因为当你在看电影时，你会看 2 个小时，而且不会碰电脑。有时候风扇转起来也很正常，因为是 HD 内容，CPU 占用升高，你会觉得这是 VLC 在运行，很正常。但问题是，你看不到的部分是，实际上这是 CIA 使用的一个被改造过的 VLC。我们也遇到过完全相同的问题：中国 hacker 针对印度用户，结果 VLC 在印度被禁，直到我不得不在印度法院和印度政府打官司，才让 VLC 解禁。他们并没有真正使用 VLC。他们只是拿了一个 DLL，因为我们正确签名了这个 DLL，他们就用这个 DLL 做了另一个程序。所以你看到有 vlc.exe，它会调用 libvlc，但调用的是一个假的版本，然后他们用这个来进行攻击。对于这类 hack，我们其实没有太多办法阻止。

是的。因为这说明他们并不是从我们的网站下载的。

不会。

完全不会。我们有一个持续了 10 多年的大问题：德国有一个假的 VLC 版本，已经被举报了 12 年，而 Google 基本上选择不处理。他们知道里面有什么，但那个 binary 太大，他们的病毒分析器没法分析。所以如果你在德国，你可能会进入一个网站，下载一个带有定制 installer 的假 VLC。它在德国很流行，因为他们的网站是德语的，而且 Google 会把它排在 Videolan 前面。最奇怪的是，它在你的机器上 3 周内什么都不做。因为他们就是这样规避检测的。3 周后，一个同时安装的小程序会作为 service 被唤醒，然后开始下载 spyware 和 adware。Google 知道这件事，但他们决定不采取行动。那些人在德国一度使用 Dark SEO 来做这件事。这种影响很糟糕，因为它下载的东西之一，实际上会替换你机器里的广告。

他们会说有一个 VLC 的安全版本。你会收到一封邮件，说，嘿，VLC 有一个安全更新版本，请马上更新，因为它可能会 hack 你的电脑。你点进去，是一个看起来还不错的网站，然后你下载了它。它是一个新的 VLC 版本。

你不知道一个月后自己已经被 hack 了。你完全不知道自己已经成了 botnet 的一部分。

VLC 是一个 core，加上大约 500 个 plugins。其中一个是 FFmpeg，但我们还支持很多其他格式。我们支持新的 protocols，支持新的 filters，支持一些奇怪的 architectures。在这个版本的 VLC 里，有些 modules 会调用你的 drivers，主要是 hardware decoders，会调用 Intel、NVIDIA、AMD driver，也都会调用 FFmpeg。这里可能有安全问题。shader 里可能有安全问题，VLC 里可能有安全问题，FFmpeg 里也可能有安全问题，结果就是程序 crash。问题在于，你像运行其他程序一样运行 VLC，比如像 Adobe 一样。它在你的机器上运行，并且能访问你所有 documents。所以我们的想法是，一定要做 sandbox，这样我们可以防范我们自己。因为 VLC process 里运行的一些 code 甚至不是我们写的，可能是 open source 的其他项目，被我们集成到 VLC 里；也可能是你的 GPU driver，或者是其他厂商提供的东西。所以当我们 crash 时，我们希望不要让别人借此做坏事。常见的入侵方式之一，就是让一个程序 crash，这在 web browser 上很常见，也经常发生在 PDF 文件上，在 multimedia 上少一些，但也可能发生。当程序 crash 时，攻击者会在用户机器上启动某些东西，可能是 ransomware，也可能是 botnet。所以 desktop application 的安全很重要。在 mobile 上情况不太一样，因为大多数 mobile applications 都运行在自己的 sandbox 里。但对 VLC 来说，我们可以把它放进一个 sandbox，问题是我们需要访问太多东西，基本上就会拥有所有 permissions。如果你有一个 sandbox，却到处开洞，那就失去了意义。所以我们正在尝试、也确实在做的，是把 VLC 拆分成多个 processes。一个负责 decoding，一个负责 demuxing，一个负责 filters，它们各自运行在自己的 sandbox 里。这样 VLC 的一部分 crash，就像 Chrome 某个 tab crash 一样；它会 crash，但不会让整个程序都 crash。这就是我们想做的。困难在于，这个 sandbox 需要承受每秒 gigabits 级别的 memory copies。它不是一个 5 megabytes 或 10 megabytes 的网站。我们讨论的是每秒数百 megabits 的数据。所以这很有挑战性。这也是我们正在研究的方向，目标是做出安全的 multimedia player。

VLC 里最好的功能叫 puzzle filter，对吧？你点击 puzzle filter，它就会把你的视频变成拼图，对吧？然后你可以点击并移动这些拼图块，对吧？

当你在看法国电影时，这个功能非常有用，对吧？你觉得无聊，因为里面总是那种很长的情节，或者 love triangle，对吧？我们已经看过太多次了，对吧？但你又必须看，因为有人，比如你妻子让你看，或者你男朋友让你看。所以你就在看，对吧？这时你可以点击并移动拼图块。它其实完全没用，对吧？谁会在意这个？最早做这个功能的是法国南部一所高中的数学老师，他想用它教学生 Bézier curves，这当然是每个人都应该了解的东西，对吧？很有用。但因为代码很干净，所以它进了 VLC。这个功能在 2010 年被 merge。5 年后，我收到一封邮件，说：你好 JB，我在 VLC 上遇到一个问题，这个 puzzle 太简单了。我当时就想：什么？原来 puzzle 在 UI 里最大只能设成 16 by 16，对吧？也就是只有 256 块。他说，不好意思，但我喜欢一边看电影一边玩拼图，这太简单了，对吧？所以有一个我提交的 commit，你可以在线查到，就是 JB 把尺寸改成了 256 by 256。我的意思是，很多功能只被少数人使用，对吧？VLC 有一种方式可以在 command line 里看电影，不需要任何 UI，对吧？

ASCII art。它有用吗？非常有用。想象一下你在 debugging，调试一个 multicast network，对吧？你有成千上万个节点，非常复杂的 networking stack，对吧？你可以 SSH 到所有 routers 上，在没有 UI 的情况下运行 VLC。然后你就能看到画面是不是黑的，对吧？或者是不是全绿，对吧？这样你就能判断。人们没有意识到 VLC 里有很多东西其实很有用，而且确实有用户，因为一旦你有几亿用户，就会有人使用每一个功能。

当然，当然。

可以，但和我们前面讲过的所有东西相比，它没有看起来那么复杂。尤其是因为最复杂的部分并不是 streaming services 意义上的 streaming，而是过去为了真正通过 satellites 进行 broadcast 所做的事情。因为在大多数现代 broadcasting services 里，你可以 pause，然后继续播放。但当你在发送 live streaming 时，不管是 broadcast，还是 streaming services 里的 live，这就难得多，因为你需要实时 encode。你上 satellite 时，link 的大小是固定的，对吧？你不能哪怕一秒钟里突然 burst bandwidth，对吧？因为在你的总文件里没有这种空间。不过这里确实有不同类型的挑战，也很有意思，但我认为它们没有我们在 90 年代末和 2000 年代初看到的那些围绕 satellite broadcast 和 streaming 的问题那么复杂。

在 streaming 世界里，你会遇到所谓 adaptive streaming，因为难点——而且这其实不太是 video 问题，更多是 CDN 问题——在于可能有太多人同时观看同一个内容，造成 network congestion，对吧？所以你的 player 很难足够快地下载内容来播放。于是本地的 player 会读取一个较低 resolution 的版本。确实有一些很聪明的 algorithms 来做这件事，但老实说，大多数都相当基础。

是的。你开始下载一个 segment，也就是我们说的 segment，然后计时，对吧？如果下载这个 segment 花费的时间超过 segment 时长的 50%，你就往下降一档，对吧？难点更多在于什么时候提高 bandwidth、提高 quality，但这并不算很复杂。encoding 时，你会 encode 7 个 resolutions，对吧？然后给出 bitrate。难点在于让你的 encoder 给出相同的 bitrate，但现在这不像过去那么严格了。

这是一个即时反馈机制：如果你听到一个 glitch，你会立刻意识到。

但当你把这些组合起来，比如一个 event，像体育赛事，它可能会经过 satellite 或其他地方，然后到一个中心位置进行 encoding，接着你需要实时 encode 这些不同 resolution，你没有时间做 QA，你需要把它推送到 CDNs，可能还要加 DRM 或 protection，还要覆盖大量不同 devices，那确实很复杂。而且你还要面对 web browser，或者各种用于电视的不同 devices；相比之下，以前你有一个定义好的 set-top box 或 cable box，你知道它是什么，也能 end-to-end 控制。所以这是一个挑战。但我认为，只要你接受 10 到 20 秒的 latency，networking 部分并不算很难。

当然。如果从过去的情况说起，你以前会用 FFmpeg 来 encode 文件，对吧？后来我们用 FFmpeg 和 VLC 在 streaming services 里做 encode，对吧？然后你就需要把延迟一层层压低。问题是，我们到底能压到哪里？这个问题很重要，因为有很多 use case 都要求速度非常快。尤其是存在 feedback interaction 的时候，对吧？你不只是听某个东西，而是在实际控制它。相比我们迄今做过的事情，最大的区别就在于：我需要视频来对正在 live 发生的事情提供反馈，不管是无人机飞行、远程控制 humanoid robots、控制 rover，还是在 cloud gaming 里玩 video game。因为我上一份工作做的就是这个，我曾是一家 cloud gaming startup 的 CTO。这个话题很有意思，因为它会把网络推到极限。你关心的不是我们在视频里、在讨论 x264 时关心的那种质量，而是 latency，因为当你在控制一辆车时，1 millisecond 都有意义。你也见过、用过 Waymo，对吧？当 Waymo 失效时，哪怕只有 1% 的时间，也会有人在远程接管控制。我们正在构建的正是这类东西：一个用于机器 end-to-end control 的 SDK platform。

是的。而我们和其他人的做法有些不同：我们只用一个 socket、一个 connection，也就是基于 UDP 的 QUIC protocol。它很有意思，因为它是为 low latency 设计的。它没有我们所说的 TCP head-of-line problem 和 HTTP head-of-line problem。它默认加密，但在同一条连接上，我们会发送多个 streams，也就是多个 tracks。我们发送 audio、video，也发送 commands，对吧？mouse、keyboard、gamepad 等等。而且我们在这样做的同时还要保持 coherence，也就是 synchronization。因为很多人没有意识到，所有时钟其实都会 drift。当你控制一个机器人时，它可能有 2 个摄像头、5 个摄像头、10 个摄像头，还有大量 sensors、GPS 等等。如果你想正确训练你的 robotic AI model，就需要这些数据都保持同步，并且是当前的。我们所做的事情，很多都来自我们在 VLC、broadcast、real time 以及 Kieran 很熟悉的 MPEG-TS 中学到的经验：我们会把 clock drifting 计算进去。所以当我录制一个 Khyber stream，也就是一个机器人时，我可以确信它在 playback 时会以可预测的方式运行。因此当你要录制并训练你的 AI model 时，必须确保每次基于数据重新训练时，数据都保持 coherent。而时钟确实会 drift。现有方案用一个摄像头还能工作；一旦你有 5 个或 7 个，就复杂多了。

没错。而且如果我要进行控制，比如我对机器人做了某个操作，我需要确信它确实是在那个精确的时间发生的。所以我们在 server 端，也就是机器人端，有一种 re-timestamping 机制，会把 clock drift 计算进去。这是 Kiber 用来控制机器人的 use case 之一。我还想到 remote drones、远程场景，不管是 defense 还是 non-defense，还有 remote cars、remote submarines。在工业场景或 remote surgery 里，有很多地方专家无法到达机器所在的位置，要么太危险，要么成本太高。所以你允许人们让机器在现场替你工作。Kiber 的目标是让距离消失，因为这本质上要么是 skills 的投射，要么是 power 的投射。想象一下，我们都见过 Meta、Reba 以及其他公司的东西，对吧？你需要把内容 stream 到那里，因为你不会在那上面运行任何东西。所以你需要 GPU power，不管是在 cloud 上还是在 phone 上，然后把它 stream 出去。所有这些 use case 对视频的要求不是极端 low latency，而是 real-time latency。这意味着我们需要调整 encoders，让 encoders 在 4 milliseconds 内 encode 一帧。Kiran 和他的公司也能做到这种 latency 以下，因为你必须把 local latency 优化到极致，也就是 decoder、encoder 等等。因为这些时间会叠加到你的 networking time 上。而且这不只是 low latency 的问题，也是 reliability 的问题。我们会做一些聪明的事情，比如 forward error correction。forward error correction 的意思是多传一点数据，几个百分点。通过 overtransmit，你就允许丢失一些 packets，因为所有这些在 internet network 上都很困难，尤其是当你要跨很远的距离操作时。如果你检查所有 packets 是否都已送达，就会增加大量 latency。如果你不想要 latency，我们的做法就是多传一些数据，这样当有东西损坏时，可以在 client side 重构。几天或几周前，我们在 CES 期间围绕 Las Vegas 做 demo：我们有一辆完全 3D printed 的 rover。它很简单，就是一辆小车，带一个 telescopic arm，而且它实际上是从 France 控制的。视频来自一个 webcam 和一个非常小的 server，也就是一块小 PCB 在运行，并把数据发给地球另一端的人。所以 use case 非常多。你也可以想象让 AI 去控制许多 drones 等等。从技术上说，我们需要在 video 上做得非常好，在 networking 上也要做得非常好。我们需要关心 networking、encoding time、decoding time 里的每一个 millisecond。同时，你还必须在非常 low level 的层面进行集成。

我的目标是 4 milliseconds 的 glass-to-glass latency。

很简单。你有一台 computer 在运行一个 program，可能是一个 video game。它正在运行，对吧？也可以把它理解成机器人这个例子。然后你通过网络做一个 replicate。你希望，如果拿一台 1000 Hz camera 拍一张照片，它到达另一端的时间是 4 milliseconds。4 milliseconds 意味着 240 Hz，对吧？

到目前为止，我们实现了从 Windows 到 Windows，或者从 Windows 到 Mac 的 7 milliseconds。如果你看 timing，大部分时间里，NVIDIA hardware encoder 内部大约是 3.5 milliseconds，Intel decoder 大约是 2 milliseconds。所以 encoder 加 decoder 已经是 6 milliseconds 了。为了继续降下去，我们要么需要其他类型的 codecs，要么需要更快、更好的 encoder。但 4 milliseconds 会是圣杯。

过去可以用定制硬件、SDI、专业硬件来做到，但我希望它能通过互联网工作。我希望它能适用于任何 robot，比如里面只有一个小型 Jetson Nano 或 N150 的 robot。因为未来会有数以百万计的 robot 或 drone，它们可能是轮式 robot、飞行 robot，或者水下 robot。说到底，就是你控制的一台机器。为此，你要么需要 teleoperate（远程操控）它们，要么在一切都完全 autonomous（自主）之后，你也需要 tele-observe（远程观察）它们。你需要检查正在发生什么。在我看来，未来所有这些远程汽车都会由一个 AI model 来 tele-observe，它只会判断：一切正常。如果不正常，就提示：这里有问题。然后再由 operator（操作员）接手。这关系到 safety（安全）。当你的 humanoid（人形机器人）在照顾你的奶奶或我的奶奶时，我希望确保一切顺利，不会出现 robot 变得危险的可怕场景。或者当我开车时，我希望车该停的时候就停；如果需要，就有人接管处理。所以 real-time（实时）相关的 case 和 scenario 非常多。Kiber 的目标，就是让机器的 real-time control（实时控制）不再受距离影响。

对我来说，这个挑战非常大。我会说，在 video（视频）方面我还算可以，但 networking（网络）方面我还有太多要学。比如 congestion protocol（拥塞协议）、real-time bitrate adaptation（实时码率自适应）。但这也挺有意思。所以我创建了这个项目，当然也在美国完成了融资。但它是 open source（开源）的，这一点很重要。我们前面还没说过：Kyber 上的一切都是 open source。

采用 dual license（双许可证），commercial 和 AGPL。你还记得你刚才关于 license 的说法吧？基本上，如果你想在自己的产品中使用 Kyber，就必须让整个产品 open source。如果你想使用这项技术但不 open source，就支付 commercial license 费用。所以小团队、hobbyist（业余爱好者）以及非常小的开发者都可以用这项技术，构建一些 open source 又有意思的东西。如果你是大公司，就会获得 support、所有 IP、修改权等等。所以这很不错。而且我自己也在做 robot，我很喜欢这件事。我们有一台 rover（漫游车）是 3D printed（3D 打印）的。我们正在完成一个 demo，是一个真正的 wing，类似 drone wing，也完全是 3D printed。我们还在尝试做一艘 3D printed sailboat（帆船），也会做一些 humanoid。当然，它们不会是特别好的 robot，这不是我们的本职工作，但我们是为了让所有人都能做 robot。很酷。

AV1 是 Alliance for Open Media 做的 codec，这个联盟里有 Google、Netflix、Amazon、Apple、Videolan 等，我们想做一个 royalty-free（免版税）且质量很好的 codec。现在它正在部署。但实际上这个 codec 在 2018 年就已经完成了，只是一个 codec 要在广泛场景中被使用需要很多年。AV2 是这个 codec 的下一代，性能提升 30%。也就是说，如果保持相同 quality（质量），相比 AV1 可以减少 30% 的 bandwidth（带宽）。

我们会做 David 2，我把它叫作 DeVID，因为 de 在法语里是“二”。而且你要知道，David 其实是一个 recursive acronym（递归首字母缩略词）。它的意思是 D，David is an AV1 decoder。

对。所以 David2 会用 2 来拼写，是 D-A-V-2-D。抱歉，我也不知道该怎么读。我们还在 CES 上做过一个 demo，展示 VLC 运行 AV2 的首个 demo。

当然。specification 就是一份文档，用来说明这个 codec 应该如何工作。

这就是 AV2，就像 H.264 一样。然后你有 encoder（编码器）。目前的 encoder 叫 AVM，未来可能会有其他 encoder，可能有一个叫 SVT-AV2，这些都是 encoder。就像 H.264 有面向 H.264 的 encoder 一样。也像 x265 是 H.265 codec 的 encoder。AV1 的 decoder（解码器）是 David，AV2 的 decoder 是 David2，H.264 的 decoder 是 FFmpeg 里的 FFH.264，HEVC 的 decoder 是 FFmpeg 里的 FFHEVC。MPEG 世界在 H.264、H.265 之后还有下一代 codec，叫 H.266，也被称为 VVC。

我们经常遇到的问题是：为什么会有两个名字？因为大多数时候，这是 ISO 世界和 ITU 共同完成的工作。ITU 是 International Telecommunication Union（国际电信联盟）。

理论上，H.264 是 MPEG-4 Part 10，H.264。

这就是完整名称。

HEVC 则是 MPEG-H.265 HEVC。

还有 H.266，也叫 VVC。

每一代提升 30%，这是最好的概括。

正在听我们说话的专业人士可能会想打我们，因为他们会说，不是，是 35%、25%、50% 等等。但总体上，你需要知道 HEVC 比 H.264 好 30%。H.265 比 H.265 好 30%——这里面有太多 case 和 scenario。比如在某些场景，尤其是 screen recording（屏幕录制），收益会非常大，因为你正好有适合那个场景的工具。所以对某个特定 video，新一代可能带来 70% 或 80% 的收益。以前 codec 的数量多得多，但现在用于 transmission（传输）的两条主要 codec 路线，一条是 H.264、H.265、H.266，另一条是 AV1、AV2。

是的，还有 patent（专利）的 royalty（版税）。这也是为什么会出现 AV 版本 codec：它们尽可能做到 royalty-free，也就是尽可能不需要为 patent 付费。你需要知道一点，我们前面还没谈到：multimedia 是所谓的 patent minefield（专利雷区）。专利最多的两个领域，一个是所有与 3G、4G、5G、RF 相关的东西，另一个就是 multimedia。因为它非常数学化，可以获得很大的收益等等。所以 Google、Meta 和 Netflix 想要一种 royalty-free 的方案。也有人说他们在外部有相关 patent，但那些是 fringe patent（边缘专利）。所以总体上，说它基本上 patent-free 是成立的。

通常 MPEG 会制定一种 format，对吧？然后所有人都会过来说，我有这个 format 的这些 patents，于是他们通常会组成一个联盟。这个联盟叫 MPEG-LA，也就是 MPEG Licensing Association。你把所有 patents 放进去，然后要求所有使用这个 format 的人付费。

设想我在做一件事：我不用正方形的 blocks，而是用 rectangles，对吧？

是的。

是的。

最大的问题不是这个。因为在 H.264 时代，patents 还可以说是相对正常的。但里面的钱太多了，所以到了 HEVC，specification 里被塞进了大量东西，其中很多在 99.9% 的情况下都没用，只是为了让某个人可以在上面加一个 patent。于是 HEVC licensing 变成了 MPEG-LA，加上另一个 patent pool，叫 HEVC Advance，另外我记得 Nokia 还在 patent pool 之外。

所以几乎没法 license。几个月前，HP 好像决定在他们的 Windows laptops 里移除 HEVC 支持，因为这些 patents 的成本在上升。事情发展到某个程度，还有没有上限的 patents。对 YouTube 或 Netflix 来说，每年 patent licensing 可能是数亿美元。于是他们说，既然每年要花 $100 million，那我还不如创建自己的 codec。然后他们就这么做了。这就是为什么会有 Open Media Alliance，也就是 Alliance for Open Media，我们也是其中一员。它创建了 AV1，也在创建 AV2。我们也创建 audio codecs。主要区别就在这里。而且因为你需要绕开 patents，或者做一些没有被 patent 的东西，所以很多地方都会不同。30 年前 MPEG-2 里做的那些基础东西当然已经过了 patent 期。但比如说，golden frame、S-frame、B-frame，或者不同类型的——

所以你需要双重创造力：一方面是提高效率的创造力，另一方面是确保不侵犯现有 patents 的创造力。比如 VVC 拥有 HEVC 的所有 patents，再加上新的 patents。而 AV2 则尽量做到 royalty-free。

我们不考虑。VLC 在法国的原因之一，就是法国不承认 software patents。所以这些 patents 大多在法国是非法的。因为我曾经算过，如果我要为 VLC 支付所有 licensing fee，每个用户要付超过 €200，换成美元也差不多。但这些 patents 在欧洲大多无效，因为它们基本上属于 mathematical patents 或 idea patents，在欧洲不被承认。

你可能还没有看到的是，欧洲出现了新一代 entrepreneurs，尤其是在法国。UK 很早就做到了，因为它更偏 Anglophone，更接近 Anglo-Saxon 的商业方式和对 business 的看法。但尤其是法国发生的变化。当然，有时凡事都被称为 French tech，确实有点过度。不过今天，大多数进入市场的人都想创建 startups。15 年前不是这样。那时大家都想去大公司工作，因为比如在法国，20 年前、15 年前，如果你失败了，把公司做没了——这对 startup 来说很正常——你就不被允许再创建新公司。那时有很强的 stigma。现在这种 stigma 已经消失了。法国在 AI 等领域发生了很多事情。当然，overregulations 是存在的，我知道，我自己就是 entrepreneur，但它也有一些好的方面。

他们试过。我们确实遇到过问题。

不，你不会去想这些。这也没问题，对吧？

Videolan 没有 office。

当然。但我没有 platform。一切都在 client side。

以什么理由？我没有分享任何东西。content 不经过我的东西。

是的，这没错。

你要意识到，比如在法国或欧洲大部分地区，有一个好处是：回应 court order 不会让你破产。它不像美国，那里真的可能让你破产。法律系统的运作方式是这样的：我每周都会收到 lawyers' letters，对吧？我可以告诉你，Videolan 每年的 lawyer fees 不到 $10,000。所以这并不真的吓人。

有。两个机构。

不行。而且我当时远没有这么礼貌。

对。

如果我们不得不破坏自己的 software，那我们会把它关掉。这一点很明确。

任何进入 VLC 的 code，都必须在我们的控制之下。至于我们编译 VLC 的方式，你可能会觉得我完全是偏执。比如，我们在离线机器上编译，第一步是先编译 compiler。我们在从未连接过 internet 的环境里离线完成所有事情。我们的签名方式有双重签名，尤其是因为，举例来说，我们见过、也相信有一个非西方世界的政府机构试图把一个 fake binary 推进我们自己的服务器。这让我们很警惕。而 VideoLAN 是 open source。你怎么杀死它？比如我搬走，对吧？我搬到 Malta，搬到 Cayman Islands 之类的地方，改掉 domain name，然后重新开始。VLC 是一个工具。它是一个帮助人们做事的工具。我们不是 platform。至于专利，我很抱歉，但大多数专利，你本来就不应该能给数学和矩阵申请专利。这是不对的。

不会，从来不会。我们从不这么做，因为 VLC 完全离线，不和任何服务器通信。所以我们根本不知道你拿这个 software 做什么。

不，他们不能这么做。而且他们也会尝试说，嘿，我想知道某个人是否看过那类视频。答案就是：不知道。

不行，因为我们唯一的 infrastructure 是下载 infrastructure。VLC 里没有 telemetry，对吧？

我们唯一能做的，也确实发生过的，是我们曾经遇到一个情况：美国某地的警方说，我们有一起谋杀案，这个文件损坏了，或者在那个版本的 VLC 里播放不了。你们能帮忙吗？我们从来不会接触视频本身。这就像普通 support 一样。

是的。我还记得 Afghan war 期间，我收到过一封来自军方某人的 email。我不记得他的军衔了。内容大概是：最新版 VLC 有个大问题，因为它不能正确播放我们某个 RTSP server 上的文件，而那里有所有电影。他说 VLC 对地面部队的士气非常重要。因为到了晚上，我想可能会很无聊，所以他们有一批视频或电影可以在那里看。当然，是我做了一次 update，破坏了某些 RTSP support。于是我给了他们一个专门的版本，因为这很重要。而且因为 VLC 完全 open source，我认为它被允许安装在 US Army laptops 上。我猜美国军方有人实际看过它，然后说，好，这没问题。我们记录处理流程的方式也没问题。所以我们和 authorities 合作的唯一方式，就是帮他们做 support。

我们看不到人们如何使用它。人们使用 VLC，这一点很强。

6 个，8 个。所有法律事务都只有我一个人处理。凡是 legal 的事情都只有我。

我以前对此压力很大。

但问题是，我们是在为所有人、为更大的公共利益做我们能做的事情。我们做的工作，是把一些极其复杂的 technology 变得让每个人都容易使用。我们是一个工具，而每个工具都会被用来做好事，也会被用来做坏事。你不能责怪工具，我认为这一点非常重要。以前我压力很大，现在不会了。

我有一种思考方式，就是总去想最坏情况是什么。总是 worst-case scenario。最后的答案是，如果我像 chess player 那样思考，最终我会死吗？是还是不是？我会一直这样想。这也是我做 startup 的方式。我在这里是为了做出好的东西。最坏情况是什么？公司破产。生活就是这样。公司会生，也会死。没关系。所以我的道德判断总是：最后我会死吗？我在伤害某个人吗？如果答案是否，那就算了。比如，有些律师会不高兴。那他们能怎样？拿走 VideoLAN 的所有钱？哇，他们能拿到 50,000 美元。真厉害，对吧？他们拿这能做什么？source code 已经在那里了，它是不可阻止的。也因为我们做的事情是好的，而且是为所有人做的。这很美。

你觉得 1,000 年后我们还会有 C compilers 吗？

他们懂一些我们不懂的视频知识。每次我和 Dave Rice，或者 British Film Archive 的人交流，都会学到新东西。而我已经做 video 做了 20 年。尤其是在 colorimetry 和颜色方面，他们懂得特别多。

而当你进入 film scanner 这个 rabbit hole 的时候，对吧？你把那些东西拿来转成 digital，这本身就是一个很大的话题，光这个话题就可以再录 5 个小时播客。

但人们没有意识到，我们今天正在失去大量 film。来自 30 年代、40 年代、50 年代的很多东西，当时被认为没有价值。

哦，哇。

FFmpeg 会。VLC 也许会。

5 年、10 年很容易。问题在那之后，对吧？问题是，我们会不会走向一种叫 holograms 的东西？

会。

是的。

当然。我的意思是，今天已经有一些新的 codecs，比如用于我们所说的 point cloud，或者 volumetric videos 的 codecs。现在有大量关于所谓 RGBD 的研究，对吧？也就是用于 depth 的 codecs，这对 robotics 和 3D 内容很有用。还有用于压缩 3D elements 的 codecs 的回归。

例如在 VLC 上，我们也已经有 VR 和 XR 版本的 VLC。还有在 Kyber 上，对吧？我们提到 Kyber。在 Kyber 上，我们也在做 XR content 的 streaming，用于那些算力不够的 glasses，或者 Apple Vision、Quest 里面。所以我们已经在做 3D、XR、interactive、low latency 的 streaming。还有一种叫 volumetric video、point cloud videos 的东西。所以它不会停下来。是的，在某个时刻，它们会在 VLC 和 FFmpeg 里面管理 3D data，对吧？这是显然的。

社区里不是每个人都看到了这一点，但像 Kieran 和我，我们是 entrepreneurs，我们知道它会往哪里走。我们看得到。

要回答这个问题，我们需要先回答 multimedia 的定义是什么。

Multimedia 是面向人类感官的多路 stream 的数字表示。我们会做到这一点。想象一下，现在有一种方式，不再使用 mic，而是使用气味传感器和气味扩散器。它会进入 FFmpeg。

是的，当然。你的 demuxer 会有一种新的 track type，基本上就是气味。还有嗅觉、触觉。它就像 audio 一样。

是的，当然。

比如在 VLC 里，我们已经有一个 haptic plugin。它主要用于我们所说的 4D cinemas。你知道，就是那些装在 hydraulic——我不知道这个词怎么说。

对，所有东西都在动，就像主题公园里的那种。然后会有一个同步的 data feed，本质上是在传输这些信息。

有很多 standard。

所以当然，我们有一个 plugin，不在 VLC 的普通版本里，它基本上负责传输这些类型的 movement，也就是物理 movement，也就是 haptic movement。它是人类感官的一部分，所以它会被纳入进来。

不，要从相反的方向看。我们不是 contributors，我们是 maintainers。也就是说，我们为所有人维护。比如每年大约有 150 人为 VLC 贡献，可能有 300 人为 FFmpeg 贡献。我们这个小团队的目标，是把所有 contributions 合进来。所以如果 usage 更多，就会有更多 contributions，而这些人会去做正确的 modules、新 formats 等等。我们关心的是 architecture。VLC 的 architecture，FFmpeg 的 architecture。现在我们在 VLC 做 spatial audio。不久前我们做过 demo。architecture 需要一些 changes，我们做了第一个 spatial audio module。等要加第二个时就会容易，第三个也会容易。我们的目标，对 ODOZ 或 AptX 也是一样。我们需要在 architecture 上工作，让 modules 可以被添加进来，以增加未来的 capabilities。所以是的，我们会继续做，我们是 multimedia frameworks。这不只是 audio 和 video，而是一切有 timing、并且表示某种你可以感知的东西。如果是 brainwaves，那就会是 brainwaves。

按经验来看，事情总是一样的。开始时，这是一个新话题。会出现大概 5 种不同 standards，因为每个人都开始做。然后 hype 降下来。每次 hype 降下来后，人们就会开始说，好吧，你知道吗，我们需要做一个 standard。通常是 2 到 3 家公司，不是 leader，而是 2 到 3 个 followers，一起做一个 standard。然后我们实现这个 standard，曲线也就到末端了。它开始变得更成熟。

比如 3D audio。

6、7 年前，一切都围绕 3D。Android 上有 Cardboard。你有两种 audio formats，现在都死了。现在它又带着真实 use cases 回来了，而且我们会从过去 standard 的错误中吸取教训。所以到处都会是这样。

是的，我没有。

它曾经是一家很了不起的公司，做了大量很好的事情，有很优秀的 engineers。他们定义了 sound 是什么。现在基本上变成了 lawyers 和 licensing。

不，只是他们不像过去那样创新了，等等。有点像，抱歉这么说，像 HP。

不是还有一次 FFmpeg 跑在 Mars 上的 rover 里吗？

我们经常看到有人在奇怪的地方使用 VLC 的 tweets。很多做 Formula One 的人，在所有 paddocks 里都用 VLC 播放 live feed。我们见过 European Space Agency，也见过 SpaceX 用 VLC 监控 launches，这会让你很开心。

对。对我来说，最难忘的经历之一，是去 CERN 的 LHC，因为他们用 VLC 监控环上的所有 captures。那个环有 27 公里。所以他们有一些 analog cameras，并且用一些 capture cards 把 analog 转到 VLC，这样 VLC 就可以在他们的 multicast network 上 stream，让整个 CERN 都能访问。我在 2010 年和 Laurent 一起去参观了那里，我们大概一小时就修好了他们的问题。因为只是一些 parameters，当时可能文档写得不太好。然后他说，好，剩下一整天你想做什么？于是我们参观了所有东西，包括 antimatter、colliders 等等。那是我物理背景里最难忘的一天之一。

是的，这对我很重要。

不，因为 regrets 是对你 mind 的一种 tax。要从 mistakes 中学习，但不要 regret，因为你已经做了。除非你有 time machine 可以回到过去，否则不要 regret。它只会消耗你的 brain。要从 mistake 中学习，当然。但不要 regret。

你是在拿我和 Johnny Depp 比吗？因为那会是你的第一次。

非常感谢。