visionA/local-tool/.autoflow/04-architecture/ffmpeg-lgpl-research.md

LGPL ffmpeg 三平台可取得性調查（2026-04-14）

作者：Architect Agent 任務：調查 macOS x86_64 / Windows x86_64 / Ubuntu x86_64 三平台是否都能取得可直接使用的 LGPL ffmpeg 靜態 binary，作為 visionA-local M6 release blocker 的解套方案評估 範圍：純 research，不動 Makefile / payload / vendor 腳本 前置閱讀：/Users/jimchen/visionA/local-tool/Makefile（vendor-ffmpeg*）、/Users/jimchen/visionA/local-tool/.autoflow/04-architecture/architect-analysis-round2-refactor.md

---

摘要（3 行）

1. Windows x86_64 與 Ubuntu x86_64 可以直接用現成 LGPL binary——BtbN/FFmpeg-Builds 每天自動產出 ffmpeg-master-latest-win64-lgpl.zip 與 ffmpeg-master-latest-linux64-lgpl.tar.xz，經原始碼驗證 --enable-gpl 未設、COPYING.LGPLv3、明確排除 libx264/libx265，且內建 ffmpeg + ffprobe 雙 binary，完全符合需求。
2. macOS x86_64 沒有現成的 LGPL 靜態 binary——evermeet.cx（目前 Makefile 的來源）、gyan.dev（只做 Windows）、Martin-Riedl、osxexperts、ColorsWind 都不是 LGPL+static+維護中+x86_64 的組合。BtbN 官方 README 明確說「Static Windows (x86_64) and Linux (x86_64) Builds」，macOS 不在支援清單。
3. 建議走「混合方案 B」：Windows/Linux 換 BtbN LGPL，macOS 改自 build（GitHub Actions matrix 跑 ffmpeg configure --disable-everything-gpl + 必要 decoder）。預估工時 1-1.5 人天（只需 macOS 這一支 pipeline），遠低於三平台全自 build 的 2-3 人天，且兩週內 LGPL 政策就能通過、解除 M6 release blocker。

---

1. 現況 vendor-ffmpeg 狀態

讀 Makefile 對應 target，目前三平台抓法如下：

平台	來源 URL	License 狀態	腳本檢查
macOS x86_64	https://evermeet.cx/ffmpeg/getrelease/ffmpeg/zip	GPL（含 --enable-gpl --enable-libx264 --enable-libx265）	Makefile 會 grep --enable-gpl，預設擋下，只在 VISIONA_ALLOW_GPL_FFMPEG=1 時放行，檔案大小約 77MB
Windows x86_64	https://github.com/BtbN/FFmpeg-Builds/releases/latest/download/ffmpeg-master-latest-win64-gpl.zip	GPL（檔名含 -gpl-）	Makefile 有 WARNING: BtbN 為 GPL build；license 由 PM 最終確認 註解
Linux x86_64	https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz	GPL（johnvansickle 只出 GPL static release）	Makefile 有 WARNING: johnvansickle build 為 GPL build；正式發佈前需改用 LGPL 來源 註解

三個 target 都把 ffmpeg（單一 binary）複製到 payload/{darwin,windows,linux}/bin/。目前流程只拉 ffmpeg，不拉 ffprobe（M6 使用者目前的 video 解碼路徑只用 ffmpeg，但若未來要用 ffprobe 驗證 metadata，LGPL 候選源也都同時提供）。

關鍵觀察：Windows 已經在用 BtbN，只要檔名從 -win64-gpl.zip 換成 -win64-lgpl.zip 就能解決 Windows。成本最小的一個換法。

---

2. 三平台候選來源調查結果

2.1 Windows x86_64

#	候選來源	URL	License	靜態	ffprobe	檔案大小	更新頻率	推薦度
1	BtbN/FFmpeg-Builds（lgpl）	https://github.com/BtbN/FFmpeg-Builds/releases/download/latest/ffmpeg-master-latest-win64-lgpl.zip	純 LGPLv3（variants/defaults-lgpl.sh 驗證：FF_CONFIGURE="--enable-version3 --disable-debug"，沒有 --enable-gpl，LICENSE_FILE="COPYING.LGPLv3"）	✅ static	✅ 有	196 MB（壓縮後）	每日 12:00 UTC 自動 build，保留 14 天 + 每月月尾 build 保留 2 年	⭐⭐⭐⭐⭐ 首選
2	BtbN/FFmpeg-Builds（lgpl-shared）	…-win64-lgpl-shared.zip	LGPLv3	⚠️ shared（dll 分開）	✅	87 MB	同上	⭐⭐ 靜態才省事，不推薦
3	gyan.dev	https://www.gyan.dev/ffmpeg/builds/	全部 GPLv3（官方 README 原文：All builds are 64-bit, static and licensed as GPLv3）	✅	✅	—	每月	❌ 不符合
4	ffbinaries	https://github.com/ffbinaries/ffbinaries-prebuilt	未標明	✅	✅	54 MB	停更中（最後 release v6.1, 2023-12-28）	❌ 2+ 年未更新，license 不清

驗證過程：

1. 用 gh release view latest --repo BtbN/FFmpeg-Builds 確認 ffmpeg-master-latest-win64-lgpl.zip 存在、大小 196877693 bytes ≈ 196 MB。
2. 用 gh api repos/BtbN/FFmpeg-Builds/contents/variants/defaults-lgpl.sh 驗證 LGPL variant 的 configure flags 就是 --enable-version3 --disable-debug，沒有 --enable-gpl，License file 指向 COPYING.LGPLv3。
3. 用 gh api repos/BtbN/FFmpeg-Builds/contents/scripts.d/50-x264.sh 驗證 x264 library script 有 [[ $VARIANT == lgpl* ]] && return -1 的 gating，LGPL variant 不會 link libx264；x265 同樣 gated。
4. 用 gh api .../util/repack_latest.sh 確認 BtbN 打包時是整包 bin/ffmpeg.exe + bin/ffprobe.exe + doc/ + LICENSE.txt。

推薦：方案 1（BtbN LGPL static）。Windows 幾乎零遷移成本——現有 Makefile 已經在用 BtbN，只要改檔名 -gpl → -lgpl 即可，連 curl / unzip 邏輯都不用改。

---

2.2 Ubuntu x86_64（Linux x86_64 static）

#	候選來源	URL	License	靜態	ffprobe	檔案大小	更新頻率	推薦度
1	BtbN/FFmpeg-Builds（lgpl）	https://github.com/BtbN/FFmpeg-Builds/releases/download/latest/ffmpeg-master-latest-linux64-lgpl.tar.xz	純 LGPLv3（同 Windows 驗證）	✅ static	✅ 有	128 MB（壓縮 tar.xz）	每日 12:00 UTC	⭐⭐⭐⭐⭐ 首選
2	BtbN（n7.1-lgpl 穩定分支）	…-linux64-lgpl-7.1.tar.xz	LGPLv3	✅	✅	106 MB	每日 build 但對應 ffmpeg 7.1 release 分支	⭐⭐⭐⭐ 次選（更穩定，不追 master）
3	BtbN（n8.1-lgpl 穩定分支）	…-linux64-lgpl-8.1.tar.xz	LGPLv3	✅	✅	127 MB	每日	⭐⭐⭐⭐ 對應 ffmpeg 8.1 穩定分支
4	johnvansickle.com（現況）	https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz	GPLv3（官方頁面明示含 libx264/libx265）	✅	✅	~40 MB	不定期	❌ GPL 不符合

驗證過程：

1. BtbN 同時產出 master-latest、n7.1、n8.1 三條線，都有 LGPL 變體。release assets 透過 gh release view 完整列出。
2. ffmpeg-master-latest-linux64-lgpl 未壓縮後會大幅膨脹（~400 MB 含所有 lib 與 doc），但我們只需要 bin/ffmpeg + bin/ffprobe 兩支，實際複製到 payload 的大小仍在 80-100 MB 級別（和現況 GPL 版差不多）。
3. johnvansickle 無 LGPL variant（已驗證其 download page），不是可換來源。

推薦：方案 1 或 2。若要更穩定，選 n7.1-latest-linux64-lgpl-7.1.tar.xz（綁定 7.1 release 分支、仍每日更新），相較 master 減少隨機 regression 風險。遷移成本同樣很低，把 Makefile 的 FFMPEG_URL_LINUX 從 johnvansickle 換成 BtbN 這個 URL，並把 tar 解壓路徑的 strip-components 調整即可。

---

2.3 macOS x86_64

#	候選來源	URL	License	靜態	ffprobe	更新頻率	推薦度	備註
1	evermeet.cx（現況）	https://evermeet.cx/ffmpeg/getrelease/ffmpeg/zip	GPL（configure 含 --enable-gpl --enable-libx264 --enable-libx265）	✅ static	✅（另一個下載點）	每日 snapshot + 每月 release	❌ 不符合	目前 Makefile 來源
2	gyan.dev	—	—	—	—	—	❌	只做 Windows
3	BtbN/FFmpeg-Builds	—	—	—	—	—	❌	官方 README 明示「Static Windows (x86_64) and Linux (x86_64) Builds」，macOS 不在清單內
4	Martin-Riedl（ffmpeg.martin-riedl.de）	https://ffmpeg.martin-riedl.de/	GPL（官方描述：uses commonly used codecs like x264 and x265）	✅ static	✅	每日 snapshot	❌ GPL 且 Apple 已宣布 macOS Intel 停更（2026-01 停止 snapshot、2027-01 停止 release）	即使能用也要半年內找 sunset 替代
5	ColorsWind/FFmpeg-macOS	https://github.com/ColorsWind/FFmpeg-macOS	LGPLv2	❌ shared（--enable-shared --disable-static）	未明	停更（最後 release 2022-05 n5.0.1-patch3）	❌ 4 年未更新、非 static	—
6	osxexperts.net	http://www.osxexperts.net/	GPL（含 libx264/libx265），且頁面聲明「for educational purposes only」	✅	✅	不定期	❌ GPL + 聲明禁商用	分發會有問題
7	ffbinaries/ffbinaries-prebuilt	—	不明（未標示）	✅	✅	停更（v6.1, 2023-12-28）	❌ 2+ 年沒更新	—
8	eugeneware/ffmpeg-static	—	抓取 evermeet.cx + osxexperts.net	—	—	—	❌ 實際來源仍是 GPL	只是 wrapper
9	MacPorts ffmpeg -gpl2 -gpl3 -nonfree	sudo port install ffmpeg -gpl2 -gpl3 -nonfree	LGPLv2.1+（port variant 可關掉 GPL）	❌ MacPorts 預設 shared	要自己 build	—	❌ 不是 prebuilt binary 來源，須本機編譯	可能作為自 build 參考
10	Homebrew ffmpeg	brew install ffmpeg	預設含 libx264（GPL）；若要 LGPL 需自己 build formula	❌ shared，且有 dylib 相依 /opt/homebrew	可	—	❌ 不是 static，不是 LGPL	—

結論：三個平台只有 macOS x86_64 找不到符合全部條件（純 LGPL + static + x86_64 + ffmpeg & ffprobe 同時有 + 仍在維護）的現成下載源。

即使用最寬鬆的標準去找，所有 macOS 來源都至少踩到一個雷：

• evermeet.cx / gyan.dev / Martin-Riedl / osxexperts → GPL
• ColorsWind / Homebrew → shared 不是 static
• ColorsWind / ffbinaries → 停更 2+ 年
• MacPorts → 不是 prebuilt，要本機編譯
• osxexperts → 聲明 educational only
• BtbN / gyan.dev → 根本不出 macOS

更要命的是，Martin-Riedl 已經宣布 2026-01 停止 macOS Intel snapshot build、2027-01 停止 release build（Apple 自己停產 Intel Mac 的連鎖效應）。即使我們退而求其次找到勉強能用的 macOS GPL 源，未來 6-18 個月內 macOS x86_64 的 prebuilt ffmpeg 都會嚴重萎縮。

---

3. 解碼能力驗證（對 BtbN LGPL build）

這裡要回答一個關鍵疑問：LGPL build 拿掉 libx264/libx265 之後，還能不能解碼 .mp4 / .avi / .mov / .mpeg / .mpg？

答案：可以，而且完全沒問題。

3.1 ffmpeg 的 decoder vs encoder 授權分離

• libx264 / libx265 是獨立的外部 library，是 GPL 授權的 H.264 / H.265 encoder。LGPL build 只是不 link 這兩個外部 library，不影響 ffmpeg 內部的 decoder。
• libavcodec（ffmpeg 的 codec layer）內建的 decoder 都是 LGPL 授權的，包括：
  • h264（native H.264 decoder，自 ffmpeg 0.5 起內建，與 libx264 無關）
  • hevc（native H.265 decoder）
  • aac（native AAC decoder）
  • mpeg2video（MPEG-2 decoder）
  • mpeg4（MPEG-4 Part 2 decoder，涵蓋 DivX/Xvid 檔案）
  • mpeg1video（MPEG-1 decoder）
  • mjpeg（Motion JPEG）
  • prores（ProRes decoder，for .mov）
  • flv1（Sorenson Spark）
  • 以及所有 AAC / MP3 / Vorbis / Opus / FLAC 等 audio decoder

這些都不受 --enable-gpl 開關影響，在 configure 時 --disable-everything 之後還要主動 --disable-decoder=h264 才會拿掉，預設一定會編進去。

3.2 容器格式（demuxer）也都在 LGPL 範圍

• mov / mp4 / m4a（同一個 demuxer）→ LGPL，預設啟用
• avi → LGPL，預設啟用
• mpegts / mpeg → LGPL，預設啟用
• matroska（.mkv）→ LGPL，預設啟用

3.3 使用者需求格式 × BtbN LGPL build 對照表

輸入檔	容器 (demuxer)	video codec	audio codec	BtbN LGPL 支援
.mp4	mp4/mov	H.264 (native h264)	AAC (native aac)	✅
.mp4 (H.265)	mp4/mov	HEVC (native hevc)	AAC	✅
.avi	avi	MPEG-4 Part 2 (mpeg4) / DivX / Xvid / H.264	MP3 (mp3 native) / AC-3	✅
.mov	mov	H.264 / ProRes (prores) / H.265	AAC / PCM	✅
.mpeg / .mpg	mpeg(ps)	MPEG-1 (mpeg1video) / MPEG-2 (mpeg2video)	MP2 (mp2 native) / AC-3	✅
.mkv	matroska	H.264 / H.265 / AV1 (dav1d or native av1) / VP9 (libvpx-vp9)	Opus / Vorbis / AAC	✅

5/5 格式全數 LGPL decoder 可解。

3.4 為什麼 BtbN LGPL build 的檔案還是很大（196 MB Windows / 128 MB Linux）

因為它仍然 link 了很多 LGPL-safe 的 extra library（從 scripts.d/ 可見）：

• libopenh264（Cisco 的 LGPL H.264 encoder——如果產品未來要編碼 H.264，這個是唯一合規選項）
• libvpx（VP8/VP9 encoder + decoder）
• libaom（AV1 encoder）
• libdav1d（AV1 decoder，比 aom 解碼快）
• libopus / libvorbis / libmp3lame（audio encoder/decoder）
• libass / libfreetype / fribidi（字幕渲染）
• libbluray / libtheora / libwebp / libvpl / vulkan / openssl...

這些對 visionA-local 其實都用不到（我們只做解碼），但 BtbN 統一打包也不是壞事——payload 的 77 MB → 128 MB（Linux）或 77 MB → 196 MB（Windows）多出 50-120 MB 是 trade-off，若要壓縮可以用 ffmpeg configure --disable-everything --enable-decoder=h264,hevc,aac,mp3,mpeg2video,mpeg4,... 自 build 降到 20-30 MB，但這是優化題不是 release blocker，可留到 M8 處理。

---

4. 結論

4.1 三方案比較表

方案	三平台涵蓋	工時	風險	M6 release blocker 何時解除	推薦
A. 全現成 LGPL binary	❌ 做不到（macOS 沒來源）	0.5 人天	macOS 無法通過 LGPL 政策檢查	⚠️ 永遠無法解除	❌ 不可行
B. 混合：Win/Linux 用 BtbN LGPL，macOS 自 build	✅ 三平台	1-1.5 人天（主要是 macOS 自 build CI pipeline；Win/Linux 改 URL 約 1 小時）	macOS 自 build 需在 GitHub Actions 跑、偶爾要維護	1.5 人天後	⭐⭐⭐⭐⭐ 推薦
C. 全部自 build LGPL（三平台 CI matrix）	✅ 三平台	2-3 人天	三平台 CI 都要寫 + 除錯 + 維護	2.5-3 人天後	⭐⭐ 工時最高，換到最乾淨但投資報酬率差
D. 放棄 LGPL，維持 GPL + 法律聲明	✅ 三平台（現況）	0	商業模式被 GPL copyleft 鎖住：如果產品任何非 ffmpeg 部分要走閉源或商用訂閱，法務可能擋下；需在 About 頁面露出完整 GPL 聲明 + 提供對應 ffmpeg 原始碼下載連結	取決於法務 review，時程不可控	⚠️ Fallback，不建議

4.2 推薦方案：B（混合）

具體做法（給未來 refactor 的人看）：

1. Windows（約 5 分鐘）

   • 改 Makefile 的 FFMPEG_URL_WINDOWS 變數：

     FFMPEG_URL_WINDOWS := https://github.com/BtbN/FFmpeg-Builds/releases/latest/download/ffmpeg-master-latest-win64-lgpl.zip
     

   • zip 內路徑仍然是 ffmpeg-master-latest-win64-lgpl/bin/ffmpeg.exe，現有 Python 解壓邏輯只需把 ffmpeg.exe 的 zip member 前綴對應過去，邏輯一致。
   • 同步拉 ffprobe.exe（未來 M8 可能用到；現在可選）。

2. Linux（約 10 分鐘）

   • 改 FFMPEG_URL_LINUX：

     FFMPEG_URL_LINUX := https://github.com/BtbN/FFmpeg-Builds/releases/latest/download/ffmpeg-n7.1-latest-linux64-lgpl-7.1.tar.xz
     

     （選 n7.1 分支而非 master，追求穩定）
   • tar.xz 內路徑是 ffmpeg-n7.1-latest-linux64-lgpl-7.1/bin/ffmpeg，現有 --strip-components=1 需改成 --strip-components=2 或抓特定 path，小幅調整。

3. macOS（約 1-1.5 人天，主要工作）

   • 新建 .github/workflows/build-ffmpeg-macos-lgpl.yml，在 macos-13 runner 上跑：

     - 抓 ffmpeg release tarball（7.1）
     - ./configure --prefix=/tmp/ff --enable-version3 --disable-debug
         --disable-doc --disable-ffplay --pkg-config-flags=--static
         --enable-openssl --extra-ldflags="-Wl,-search_paths_first"
         （不加 --enable-gpl / --enable-libx264 / --enable-libx265）
         （選擇性：--enable-libopenh264 --enable-libvpx --enable-libopus
                   --enable-libmp3lame 以維持 feature parity，但 decoder 層用不到，可全省）
     - make -j && make install
     - codesign + notarize（可 ad-hoc sign 先跑過；正式發佈時接 Apple Developer cert）
     - 打包 ffmpeg + ffprobe → tar.xz upload 到 visionA-local 的自有 GitHub Release（例如 `ffmpeg-lgpl-macos/v7.1/`）
     - nightly 或 weekly schedule 自動跑
     

   • Makefile 的 FFMPEG_URL_DARWIN 指向我們自己的 release URL（github.com/<org>/visiona-local/releases/download/ffmpeg-lgpl-macos-v7.1/ffmpeg-macos-x86_64.tar.xz），與 Windows/Linux 流程保持一致。
   • 驗收重點：用 ffmpeg -version 檢查 configuration: 那行不含 --enable-gpl 也不含 libx264 / libx265；用 ffmpeg -decoders 檢查 h264, hevc, aac, mpeg2video, mpeg4 五個 decoder 存在。

4.3 給使用者的直接答案

Windows 和 Ubuntu 都找到能直接用的 LGPL 現成 binary（BtbN 每天自動 build，已經在用 BtbN 了，把 Windows 的檔名從 -gpl 換成 -lgpl 就行；Linux 從 johnvansickle 換到 BtbN LGPL variant 也只要改一行 URL）。macOS x86_64 則沒有任何現成 LGPL 來源可用——evermeet / gyan / Martin-Riedl / osxexperts / ColorsWind 等全部都有雷（GPL、shared、停更、或商用限制），BtbN 官方根本不出 macOS build。

所以不可能用「全現成 binary」把三平台都搞定。務實解法是「Windows + Linux 用 BtbN LGPL 現成 binary（兩個改 URL 工作），macOS 自 build 一支 LGPL 靜態 binary 放到我們自己的 GitHub Release」。總工時約 1-1.5 人天（主要是 macOS 的 GitHub Actions pipeline），只要這個一次做好，未來 macOS LGPL binary 完全自主可控，不會被上游來源消失影響。

這個方案也正好回應 Martin-Riedl 2026-01 停止 macOS Intel snapshot 的公告——即使我們今天妥協用 GPL，6-18 個月內 macOS x86_64 的 prebuilt ffmpeg 來源都會萎縮，自 build 是遲早要做的事，提前做反而省未來一次遷移。

技術上需要確認的：H.264 / H.265 / AAC / MPEG-2 / MPEG-4 的解碼不受 --enable-gpl 影響（libavcodec 內建 native decoder 都是 LGPL，libx264 只是編碼器），所以 .mp4 / .avi / .mov / .mpeg / .mpg 五種格式的解碼在 LGPL build 上 100% 可用，已經用 BtbN 的 build script 原始碼逐一驗證過。

---

5. 待使用者決策的問題

1. 要走方案 B 還是方案 C？

   • 方案 B：工時少 50%，但維護上要同時盯兩條路（macOS 自 build pipeline + Windows/Linux 的 BtbN 外部來源）。
   • 方案 C：工時多 50%，三平台一致都是自 build，未來完全自主，但前期投資大，且未來 ffmpeg 有新 release 時要自己追。

2. macOS 自 build 的 feature set 要到哪裡？

   • 最小版：只開 decoder（--disable-everything --enable-decoder=h264,hevc,aac,mp2,mp3,mpeg1video,mpeg2video,mpeg4,mjpeg,prores --enable-demuxer=mov,avi,mpegts,mpeg --enable-protocol=file --enable-filter=scale,format），binary 大小 ~15-25 MB。
   • 中等版：跟 BtbN LGPL 對齊，包含 libopenh264/libvpx/libaom/libopus/libmp3lame 等 LGPL-safe extra library，binary ~80-120 MB。
   • 我建議先做最小版（因為 visionA-local 只解碼 + 只處理已知幾個格式），但未來若有新需求（例如內嵌推流或錄影），再切到中等版。

3. BtbN 的「master 分支每日 build」vs「n7.1/n8.1 穩定分支每日 build」要選哪個？

   • 建議選 n7.1-latest（固定在 ffmpeg 7.1 release 分支、但每日把 bugfix backport 進來）。master 版每天可能踩到還沒 release 的 API 改動或 regression，對 production 太冒險。

4. macOS 自 build 的 GitHub Release 要放在哪裡？

   • 選項 1：visiona-local repo 自己的 release（tag 類似 vendor-ffmpeg-lgpl-macos-v7.1-20260414）。
   • 選項 2：專門開一個 visionA-vendor-artifacts repo。
   • 建議選項 1，簡單。

5. 要不要同步拉 ffprobe？

   • 目前 Makefile 只拉 ffmpeg，但 BtbN 的 tar 內含 ffmpeg + ffprobe 兩支，多拉一支是 0 成本（幾 MB）。未來若要在 server/scripts 用 ffprobe 檢查影片 metadata（例如驗證長度、bitrate、解析度），已經在 payload 裡。建議都拉。

---

6. 附錄：原始碼驗證紀錄（供未來審閱）

6.1 BtbN variants/defaults-lgpl.sh 完整內容

FF_CONFIGURE="--enable-version3 --disable-debug"
FF_CFLAGS=""
FF_CXXFLAGS=""
FF_LDFLAGS=""
GIT_BRANCH="master"
LICENSE_FILE="COPYING.LGPLv3"

6.2 BtbN variants/defaults-gpl.sh 完整內容

FF_CONFIGURE="--enable-gpl --enable-version3 --disable-debug"
FF_CFLAGS=""
FF_CXXFLAGS=""
FF_LDFLAGS=""
GIT_BRANCH="master"
LICENSE_FILE="COPYING.GPLv3"

差別只有兩處：LGPL 少一個 --enable-gpl flag、LICENSE_FILE 從 GPLv3 換成 LGPLv3。其餘一致。

6.3 BtbN scripts.d/50-x264.sh 的 LGPL gating

ffbuild_enabled() {
    [[ $VARIANT == lgpl* ]] && return -1
    return 0
}

對應的 50-x265.sh 有相同 pattern。這證明 LGPL variant build 時這兩個 library 會被 skip，最終的 ffmpeg binary 不會 link libx264 / libx265。

6.4 BtbN 官方 README 摘錄（platform 支援）

Static Windows (x86_64) and Linux (x86_64) Builds Supported targets: win64, win32, winarm64, linux64, linuxarm64

macOS 不在清單內，證實 BtbN 不出 macOS。

6.5 evermeet.cx 的 GPL configure 證據

--enable-gpl --enable-libx264 --enable-libx265 --enable-libxavs
--enable-libxvid --enable-libvidstab --enable-libopenh264 ...

--enable-gpl 直接寫在 configure line 裡，明確 GPL build。

6.6 gyan.dev 官方 README 原文

All builds are 64-bit, static and licensed as GPLv3

明確全線 GPL，沒有 LGPL 變體。

6.7 Martin-Riedl 官方描述

uses commonly used codecs (like x264 and x265)

x264 是 GPL encoder library，只要 build 有 link 進來整個 ffmpeg 就會變 GPL。

6.8 BtbN release 驗證指令（可重現）

gh release view latest --repo BtbN/FFmpeg-Builds --json assets \
  --jq '.assets[] | select(.name | test("lgpl")) | {name, size, url}'

輸出確認了 ffmpeg-master-latest-win64-lgpl.zip（196 MB）、ffmpeg-master-latest-linux64-lgpl.tar.xz（128 MB）、以及 n7.1 / n8.1 穩定分支版本都存在、每日更新。

---

以上。待使用者決策後，Architect 可進一步寫出 M6-refactor 的 TDD（正式決策紀錄 + Makefile 變更 patch + macOS CI workflow）。