# 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
```bash
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 驗證指令（可重現）
```bash
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）。**