# FFmpeg：網際網路影片背後的驚人技術

> FFmpeg 如何支撐網際網路上的影片編碼、轉碼與播放，以及這套開源工具背後的工程哲學。

- 原標題：#496 – FFmpeg: The Incredible Technology Behind Video on the Internet
- 期數：第 496 期
- 釋出日期：2026-05-06
- 嘉賓 / 主題：FFmpeg 與影片技術
- 網頁版：https://lex.qiaomu.ai/tw/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 和檔案社群的工作流。他們面對的約束比大多數工程團隊都嚴苛：無損、可驗證、單位元翻轉要能區域性恢復、一千年後還得有人能讀。他們是怎麼在這些約束下做取捨的，比任何架構課都實用。