影片工具路由器 (Video Tool Router)
選擇最能滿足任務需求的最便宜工具。在此機器上，轉碼品質受原始素材限制，且無顯著差異（所有工具的 VMAF 分數均在 98.4-99.8 之間），因此切勿僅因「品質較高」而為普通的轉碼任務選擇某個工具。僅在任務涉及校正或創作（如調色、色調映射、降噪、穩定、超解析度、多片段後期加工）時，才選擇 DaVinci Resolve — 這才是它發揮真正價值的唯一領域。使用它的成本是 FFmpeg 的約 15 倍（時間 + 更繁瑣的設定），而且它在調色、降噪、穩定、超分上的優勢是業界標準，並非下方基準測試所能涵蓋的（該測試僅涵蓋普通轉碼）。
決策樹（匹配第一個適用的規則）
-
無像素變化 — 剪裁 / 修剪 / 拼接 / 連接 / 封裝格式轉換 / 提取音訊 -> FFmpeg 串流複製 (
-c copy)。約 1.2 秒，無損。最快的真正編輯操作 — 當像素無需改變時，始終優先使用。但有兩個注意事項：(a) 剪裁是關鍵幀精確，而非幀精確 — 起始點會對齊到最近的關鍵幀；若需要精確的幀邊界，則需重新編碼。(b) 輸出保留原始編碼格式 (HEVC) — 如果你需要 H.264 交付檔，此規則不適用；請轉至規則 2。 -
轉碼 / 縮放 / 壓縮（像素發生變化，無需校正）-> FFmpeg libx264。 預設參數
-preset medium -crf 20。當速度重要時使用veryfast/ultrafast— 品質差異極小（ultrafast 的 VMAF 仍為 99.66）。僅在儲存空間或頻寬受限時才考慮veryslow— 其計算時間是 ultrafast 的 40 倍，僅換來 +0.12 VMAF（肉眼不可見），但檔案大小幾乎減半。即便如此，medium已能實現幾乎全部的壓縮效果（13.3 MB 對比 veryslow 的 12.6 MB），因此veryslow很少值得花費約 6 倍於 medium 的時間。 -
靜音 / 無聲片段移除（針對講話或教學音訊）-> auto-editor。 警告：在 HEVC 素材上非常慢（軟體解碼），且僅當音訊中確實存在空白間隙時才有幫助。對於連續音訊的素材（如騎行、道路、音樂片段）完全無用 — 它會耗時約 30 分鐘以上，最終剪掉 0 秒。
-
程式化組裝 — 透過 Python 進行腳本化剪輯 + 文字/疊加/轉場 -> MoviePy 2.x。 預計速度約為 FFmpeg 加上 Python 開銷。當合成邏輯用程式碼實作比用冗長的 ffmpeg
filter_complex更容易時使用此選項。 -
調色 / HLG->SDR 色調映射 / 降噪 / 穩定 / 超解析度 (SuperScale) / 多片段創意後期加工 -> DaVinci Resolve (透過 Python API)。 這是唯一「在 Resolve 中處理」是正確選擇的領域。時間約為 FFmpeg 的 15 倍，且輸出經色彩管理（非透明傳遞）。其在此領域的品質優勢是業界標準，下方基準測試未涵蓋。設定請參閱其專屬章節。
-
3D 標題 / 動態圖形 -> Blender 無頭模式 -> PNG 幀序列 -> ffmpeg 封裝。 注意：Blender 5.1 的渲染
image_settings.file_format枚舉中沒有FFMPEG/影片選項。請勿嘗試image_settings.file_format='FFMPEG'或腳本化 VSE 影片匯出 — 此版本無法使用。請渲染圖像幀，然後使用 ffmpeg 封裝。 -
AI / 文字導向編輯（根據轉錄稿編輯、移除填充詞、"讓它更短"）-> Descript MCP。
精確命令（可直接複製貼上）
1. 串流複製（無需重新編碼）
# 修剪：-t 為持續時間（秒，無歧義）。剪裁為關鍵幀精確，輸出保留 HEVC。
ffmpeg -ss 10 -i in.mov -t 15 -c copy out.mov
# 連接（list.txt 內容：file 'clip1.mov'）
ffmpeg -f concat -safe 0 -i list.txt -c copy out.mov
# 封裝格式轉換 / 提取音訊（無重新編碼）
ffmpeg -i in.mov -c copy out.mp4
ffmpeg -i in.mov -vn -c:a copy out.m4a
（使用 -t <秒> 指定持續時間。避免在 -c copy 時使用 -ss ... -to ...：-to 的參考點在與輸入端搜尋搭配時可能產生歧義，導致長度錯誤。若需要精確的幀邊界，請移除 -c copy 並重新編碼 — 這將重新引入 HEVC 解碼的成本。）
2. 轉碼 HEVC -> H.264
# 預設平衡
ffmpeg -i in.mov -c:v libx264 -preset medium -crf 20 -c:a aac -b:a 192k out.mp4
# 速度優先（品質差異極小）
ffmpeg -i in.mov -c:v libx264 -preset veryfast -crf 20 -c:a aac -b:a 192k out.mp4
# 轉碼同時縮放至 720p
ffmpeg -i in.mov -vf scale=-2:720 -c:v libx264 -preset medium -crf 20 -c:a aac out.mp4
3. 靜音移除
auto-editor in.mp4 --edit audio:threshold=4% -o out.mp4
# 若不確定音訊是否有空白間隙，可先預覽：
auto-editor in.mp4 --edit audio:threshold=4% --preview
4. MoviePy 2.x（已更名的 API：subclipped / with_position / with_duration）
from moviepy import VideoFileClip, TextClip, CompositeVideoClip
clip = VideoFileClip("in.mov").subclipped(10, 25)
# 注意：MoviePy 2.x 的 TextClip 需要字型檔案路徑，而非字型系列名稱（如 "Arial"）。
txt = (TextClip(text="Hello", font=r"C:\Windows\Fonts\arial.ttf", font_size=48, color="white")
.with_duration(5).with_position("center"))
final = CompositeVideoClip([clip, txt])
final.write_videofile("out.mp4", codec="libx264", preset="medium",
ffmpeg_params=["-crf", "20"])
6. Blender 3D/動態圖形 -> 幀序列 -> 封裝
# 渲染動畫為 PNG 幀序列（不要在 5.1 版本設定 file_format='FFMPEG'）
blender -b scene.blend -o "//frames/f_####" -F PNG -a
# 將幀序列封裝為 H.264（-framerate 需與場景影格率匹配）
ffmpeg -framerate 30 -i frames/f_%04d.png -c:v libx264 -preset medium -crf 20 -pix_fmt yuv420p out.mp4
HLG 保護機制（在任何 SDR H.264 導出前執行此檢查）
某些 iPhone 素材為 10-bit HLG。若未經色調映射，直接使用 libx264 導出為 SDR 會導致色彩灰濛 / 顏色流失。
# 1. 探測傳輸特性
ffprobe -v error -select_streams v:0 -show_entries stream=color_transfer -of default=nk=1:nw=1 in.mov
- 輸出為
arib-std-b67(HLG) 或smpte2084(PQ) -> 素材為 HDR：在編碼前/同時進行色調映射。 - 其他值 (
bt709, 未知) -> 已是 SDR：使用正常轉碼命令。
# 2. HLG/PQ -> SDR BT.709 色調映射 + H.264 一次完成（並標記輸出為 bt709）
ffmpeg -i in.mov -vf \
"zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p" \
-c:v libx264 -preset medium -crf 20 -color_primaries bt709 -color_trc bt709 -colorspace bt709 \
-c:a aac -b:a 192k out_sdr.mp4
npl=100 是用於線性化的標稱峰值亮度；若亮部高光出現裁切，可提高此值。替代方案：讓 DaVinci Resolve 的色彩管理進行 Rec.2020-HLG -> Rec.709 轉換（若你無論如何都要進行調色，請路由至 Resolve — 它比 ffmpeg 的 tonemap 更精確）。
DaVinci Resolve Python API 設定（校正/創作路徑）
以下已內建注意事項：必須在 Python 3.11 上執行（py -3.11）— 預設的 3.14 無法初始化 fusionscript.dll。RESOLVE_SCRIPT_API / RESOLVE_SCRIPT_LIB 是持久化的環境變數。Resolve 必須正在執行（或使用 -nogui 啟動）。使用一個臨時的專案，明確設定格式和編碼器，然後渲染並輪詢。
# 使用以下命令執行： py -3.11 resolve_render.py
import os, sys, time
sys.path.append(os.path.join(os.environ["RESOLVE_SCRIPT_API"], "Modules")) # 必需的標頭
import DaVinciResolveScript as dvr
resolve = dvr.scriptapp("Resolve") # Resolve 必須正在執行（或先啟動 -nogui）
pm = resolve.GetProjectManager()
proj_name = "temp_render_" + str(int(time.time())) # 保留此名稱以便清理時匹配
proj = pm.CreateProject(proj_name)
pool = proj.GetMediaPool()
items = resolve.GetMediaStorage().AddItemListToMediaPool([r"C:\in\clip.mov"])
tl = pool.CreateTimelineFromClips("temp_timeline", items) # 同時設為當前時間軸
# ---- 在此應用證明值得使用 Resolve 的精細處理 ----
# (調色 / HLG->SDR 的專案色彩管理 / SuperScale 超解析度 / 降噪 / 穩定)
proj.SetCurrentRenderFormatAndCodec("mp4", "H264") # 明確指定格式 + 編碼器
proj.SetRenderSettings({
"TargetDir": r"C:\out",
"CustomName": "out",
"SelectAllFrames": True,
})
pid = proj.AddRenderJob()
proj.StartRendering(pid)
while proj.IsRenderingInProgress(): # 渲染 + 等待循環
time.sleep(1)
print("render:", proj.GetRenderJobStatus(pid))
# 清理：在刪除臨時專案前，先關閉當前專案
pm.CloseProject(proj)
pm.DeleteProject(proj_name) # 匹配我們上面產生的名稱
環境變數（供參考 / 重新持久化）：
RESOLVE_SCRIPT_API = C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting
RESOLVE_SCRIPT_LIB = C:\Program Files\Blackmagic Design\DaVinci Resolve\fusionscript.dll
在此機器上的實際效能
- HEVC 軟體解碼是真正的瓶頸。 對 iPhone 素材的任何轉碼，無論使用何種工具都很慢；
veryslow處理 15 秒的 720p 片段耗時約 5 分鐘。每個工具都需支付相同的解碼成本 — 唯一的區別在於解碼後的操作。 - 盡可能優先使用串流複製（約 1.2 秒），當無需像素變化（且 HEVC 輸出可接受）時。若必須重新編碼且速度重要，請使用 FFmpeg 的
ultrafast/veryfast（約 7 秒）。 - DaVinci Resolve 的速度約比 FFmpeg 慢 15 倍，且輸出經過色彩管理（檔案更大，輸出與原始素材有意不同）。僅在需要調色/色調映射/降噪/穩定/超解析度/創意後期加工時值得使用。
- auto-editor 在長 HEVC 片段上可能耗時超過 30 分鐘，且可能什麼都沒剪掉 — 僅在真正有停頓的對口型/教學音訊上執行。
經驗基礎（相信路由決策，而非小數點後第二位）
任務：修剪第 10-25 秒（15 秒），然後轉碼 HEVC->H.264 720p，序列執行以獲得公平的 CPU 計時，VMAF 對比未修改的原始素材。素材：iPhone HEVC 720p30（來自 9 個片段集合的一個代表性片段）。數字為單次執行（n=1），無重複 — 較大的差距（路由決策）是可靠的；較小的差距（例如 MoviePy 與 ffmpeg medium）在單次運行的噪音範圍內。
| 工具 / 設定 | 時間 | 大小 | VMAF | 結論 |
|---|---|---|---|---|
FFmpeg 串流複製 (-c copy, 保留 HEVC) | 1.2s | 11.0 MB | 無損 | 最快；僅適用於剪裁/拼接/封裝轉換，無像素變化，輸出保留 HEVC |
| FFmpeg libx264 ultrafast crf20 | 7.4s | 22.3 MB | 99.66 | 最快的真正轉碼；品質已達原始素材的上限 |
| FFmpeg libx264 medium crf20 | 47.9s | 13.3 MB | 99.71 | 預設平衡；幾乎捕獲了所有大小優勢 |
| FFmpeg libx264 veryslow crf20 | 297s (~5 min) | 12.6 MB | 99.78 | +0.12 VMAF（肉眼不可見），比 medium 小約 0.7 MB — 僅在大小受限時有用 |
| MoviePy (x264 medium crf20) | 53.5s | 13.4 MB | 99.44* | 約等於 ffmpeg 速度 + Python 開銷（差距在噪音範圍內）；用於腳本化合成 |
| Blender VSE 影片匯出 | 失敗 | — | — | 5.1 版本無影片枚舉；需渲染幀序列 + ffmpeg 封裝 |
| DaVinci Resolve (API, 預設 H264) | 109s | 48.2 MB | 98.40* | 約慢 15 倍，色彩管理；僅用於校正/創作 |
| auto-editor (完整 81s 片段) | 2021s (~34 min) | — | — | 剪掉 0 秒：音訊連續 — 工具選錯 |
* MoviePy 和 Resolve 的 VMAF 是在匹配的無修剪傳遞中重新測量的，因此它們與修剪後的 ffmpeg 行的比較並非完全對等。Resolve 的 48.2 MB 和 98.40 來自不同的傳遞（無修剪的重新測量產生 15.24 MB）：Resolve 讀取的分數低於未修改的原始素材，因為它經過色彩管理，並非透明傳遞，且其較大的檔案是品質優先的預設位元率產物。CQ/大小匹配的 Resolve 渲染會改變這兩項比較 — 3.75 倍的大小是預設值依賴性的，而非固有的。
路由決策所基於的要點： (1) 普通轉碼品質無差異 — 不要追求它。(2) FFmpeg 預設的掃描是一個速度與位元率效率的權衡，而非品質的權衡。(3) 「最精細」僅在校正/創作工作中才有意義；在那個領域，DaVinci Resolve 是正確的工具（業界標準期望，此處未測量）— 其他情況則不然。