用愛發電,卻扛下全球 90% 影片處理的 FFmpeg
| | | 13 | |
有寫程式或手工處理過影片,應該都知道 FFmpeg 這個萬用的影片格式轉換與編輯工具,這兩天大飛有部 Youtube 影片在講 VideoLAN 開源社群,看完對這個開源專案有了更深認識,心中滿是尊敬!
整理了一些你可能不知道的 FFmpeg、影片解碼器與 VLC 播放器的小知識:

(VLC 圖示是可愛的橘白交通錐,大家應該都看過吧)
FFmpeg 是全球最大的 CPU 消耗者之一
FFmpeg 參與了超過 90% 的線上和離線影片處理流程,YouTube 影片轉碼、Netflix 串流媒體傳送、Chrome 影片解碼,甚至智慧電視的媒體播放,都少不了它。
FFmepg 是全球最全能的多媒體處理庫,囊括所有你想得到的影片處理功能:編解碼、多工 (Multiplexing)/解多工、濾鏡、媒體串流.. 等等。既是指令列工具,也是可供軟體呼叫的程式庫。FFmpeg 追求開源免費、人人平等,普通人的家庭錄影、科技巨頭的伺服器,用的是同一套 FFmpeg 程式碼,把原本價值百萬美元的專業多媒體設備能力,變成了人人可用的免費工具,催生了當代人人能在社群平台發影片當網紅的盛世。
影片編解碼器是什麼?
一般人容易把影片「容器」和「編解碼器」混為一談,MP4、MOV、MKV、AVI 是容器,負責把影片軌、音訊軌和字幕軌打包在一起;而 H.264 (AVC)、H.265 (HEVC)、AV1、VP9 是編解碼器,負責影片像素的資料壓縮和解壓縮。我們常說的 MP4 檔案,99% 是 H.264 影片 + AAC 音訊打包在 MP4 容器裡。
未經壓縮的 1080P 30 幀影片,每秒資料量高達 1.5Gbps (註:以 HD-SDI 1.48 Gbps 估算),故我們需要用編解碼器縮小資料量,在人眼幾乎看不出畫質損失的前題下把資料壓縮 100 到 1000 倍。壓縮的核心原理是消除冗餘(Redundency),包括空間冗餘 (同一畫面裡重複的像素)、時間冗餘 (比如連續幀裡不變的內容),再配合人眼感知。人眼對亮度敏感、對色彩敏感度低,故影片可將把色彩解析度降低,只保留高解析度的亮度資訊,靠這一步就能讓檔案體積減半。而解碼的挑戰在於 45% 的檔案無法用 GPU 硬體解碼,必須依賴軟體解碼,這需要極致程式碼優化,這也是 FFmpeg 的核心價值所在。
在幾十億裝置上跑的 FFmpeg 開發團隊不到 15 人
FFmpeg 開發團隊只有 10 到 15 人,全是無給職的志願者,白天上班、晚上貢獻程式碼,其開發社群有一個鐵律:只看程式碼品質,不看身份背景。不管貢獻者是頂尖軟體公司的工程師或 16 歲高中生,對程式碼審核標準都相同,對簡潔度、可維護性有極其嚴苛的要求。這與 Linux 核心管理哲學相近,因為 FFmpeg 程式會在全球幾十億台裝置上運行,一行程式有錯或效率不佳,影響難以估計。
FFmpeg 專案有 10 萬行純手寫組合語言
這是 FFmpeg 碾壓所有商用多媒體程式庫的致勝關鍵,惟有用組合語言純手工打造,才能做到每個 CPU 運算週期輜銖必較,榨乾每一絲效能。C 編譯器雖然也能提供自動優化,但和組合語言的最佳效能相差 10 到 62 倍,這是 FFmpeg 堅持效能關鍵邏輯一律手寫組合語言的理由。
FFmpeg 靠逆向工程所向無敵
全球有無數冷門、廢棄或無文件無原始碼的編解碼器,如早期的 GoToMeeting 會議編解碼器、Windows Media、RealMedia 的私有格式等,它們沒有官方文件也沒有程式碼,FFmpeg 社群的逆向工程師能僅憑二進位檔案還原出完整的編解碼邏輯。其中的傳奇是烏克蘭開發者康斯坦丁·希什科夫 (Kostya Shishkov),他逆向幾十 MB 的二進位機器指令和樣本檔案,只花了兩個月便寫出精確到位元 (Bit-Exact) 的解碼器,做到和官方解碼器完全一致的效果。(註:Bit-Exact 指所有解碼器必須輸出完全一致的像素資料,此為影片歸檔和專業處理的基本要求,早期 MPEG-2 編解碼器因沒有落實精確到位元的標準,導致大量影片無法相容)
FFmpeg / VLC 播放器為使用者省下專利授權費
多媒體領域處處是專利,像 MPEG 專利池擁有 H.264、H.265、H.266 等核心專利,企業要使用這些編解碼器,每年要支付數億美元授權費。谷歌、Netflix 推動 AV1 就是要擺脫專利綁架,讓影片技術回歸開源共享。
依據 VideoLAN 總裁 Jean-Baptiste Kempf 的說法,若 VLC 必須支付所有相關的專利授權費,那麼每一位使用者的成本將超過 200 歐元 (參考來源 if I had to pay all the licensing fee for VLC, I needed to pay more than two hundred euros per user.)。這主要歸功於 VideoLAN 設立在法國 ,法國以及歐洲法律傾向將這些視為純數學或概念專利,因此索要高額授權費專利在歐洲大多是無效且不合法的,這使得 VLC 能夠合法避開這些天價授權費,持續在全球免費為使用者提供服務。
順帶一提,隨著技術更新,AV1、AV2 逐漸成為新一代編解碼器的主流。AV1 由開放媒體聯盟 (AOMedia) 開發,谷歌、Netflix、亞馬遜、蘋果、VideoLAN 共同參與,是免專利費的開源編解碼器,比 H.264 的壓縮效率高 50%,比 H.265 高 30%,且沒有昂貴的專利授權費。而 AV2 作為下一代標準,將再提升 30% 的壓縮效率。延伸閱讀:看懂 YouTube 影音編碼規格
用愛發電開發者的困擾
像 FFmpeg / VLC 這類全球重度依賴的開源專案,核心維護者只有寥寥數人,他們拿著微薄的捐贈、甚至零收入,卻要面對大企業的需求、安全研究員的漏洞報告,以及用戶的批評,長期處於高壓的狀態,極容易陷入倦怠。例如 FFmpeg 就曾遇到谷歌用 AI 批量生成安全漏洞報告,不提前溝通就公告,將修復壓力全都丟給志願者;微軟 Teams 曾經在 FFmpeg 漏洞追蹤裡標註最高優先級,卻只願意支付幾千美元的一次性費用,完全無視志願者的付出。大型營利企業把開源專案當成免費供應商,卻不願為支撐自己業務的程式碼支付合理報酬;AI 生成的漏洞報告,本質是對開源開發者的 DoS 攻擊,有些冷門遊戲編解碼器的漏洞根本並不影響一般使用者,卻被標為高風險漏洞製造恐慌(資安研究員也要衝業績?)。但情況已有些改善,Google 開始提交修補、設立漏洞修復獎勵,對 FFmpeg 的捐贈也大幅增加,但是依然遠不足以涵蓋一個全職開發者的成本。這也是開源世界的殘酷現實,支撐全世界轉動的程式碼,完全由一群沒有保障的志願者守護。
後記
整理完文章,同為想用程式碼改變世界的開發者 (雖然沒做出個毛,但確實有這個心),為 VideoLAN 開發者的熱血與付出感動,獻上我的 RESPECT 及微薄捐獻,哈~
Comments
# by Vinci
FFmpeg 就曾遇到谷歌用 AI 批量生成安全漏洞報告,不提前溝通就公告,將修復壓力全都丟給志願者; 微軟 Teams 曾經在 FFmpeg 漏洞追蹤裡標註最高優先級,卻只願意支付幾千美元的一次性費用,完全無視志願者的付出。 出淤泥而不染的情操 ❤️👍🏻💯
# by Gj
多謝黑暗大 下面好像還要加幾個字? 「他逆向幾十 MB 的二進位機器指令和樣本檔案,只花了兩個寫出精確到位元 (Bit-Exact) 的解碼器」
# by Jeffrey
to Gj, Yes! 謝謝提醒,已修正。
# by yoyo
竟然是用組合語言,開源的開發者技術能力真的強大!
# by Semmy
這與 Linux 核心管理哲學相近... Linux 核心組 有向 Linux 基金會支薪的, 而 Linux 基金會則是有向 微軟、Google、Intel、IBM、Red Hat 等巨頭收$的... 所以是否在闇臭VLC和FFMPEG收錢???
# by Sieg
了不起! 我也有在用ffmpeg, 真的好用.
# by Johnny
文中有一些地方恐怕不精確, 建議修改: 1. VLC 確實是由法國非營利組織 VideoLAN 開發、維護的產品。不過 FFmpeg 並不「隸屬」於 VideoLAN; 事實上是 VLC 在開發上高度依賴並使用 FFmpeg 的解碼函式庫 (libavcodec)。 2. 「每個使用者需支付 200 歐元」這句話稍顯誇張, 因為以最普及的 H.264 (AVC) 為例, 每台硬體裝置或軟體拷貝的專利授權費大約只有 0.20 美元, 即便是較新、較貴的 HEVC (H.265) 或 VVC (H.266), 其單一裝置的授權費也大約在 0.20 至 0.40 美元之間。即使把 VLC 所能支援的幾百種影音格式專利通通加總, 其單一使用者的理論專利成本頂多也只有幾美元。如果每人要 200 歐元 (約合新台幣 7,000 元), 那全球賣出的每台 iPhone、安卓手機和筆電, 光是為了能播影片, 光付授權費就破產了。
# by Jeffrey
to Senmmy, "...對簡潔度、可維護性有極其嚴苛的要求。這與 Linux 核心管理哲學相近..." 感覺這段不該被超譯吧 :D
# by Jeffrey
to Johnny,感謝指正! 內文已修正。看了 Kempf 的原話,200 歐元是 VLC 平均要為每位使用者付出的授權費用,並非使用者要付給專利所有人,原寫法有誤。另 VideoLAN 生態系的說法易生混淆,也已移除。再次感謝~
# by Dsin
一秒, 1080P x 30FPS x 32bit色深 大概250MB , 聲音應該不會比影像高,一秒1.5GB資料量似乎有誤?
# by Dsin
一秒, 1080P x 30FPS x 32bit色深 大概250MB , 聲音應該不會比影像高,一秒1.5GB資料量似乎有誤?
# by Chiaying
推,有 GUI 介面也可 command line,很好用,感謝開發團隊。
# by Jeffrey
to Dsin, 應為 1.5Gbps 才對,跟以 HD-SDI 1.48Gbps 為基準的估算相近。謝謝指正。