Video Tool Router
タスクを完全に満たす最も安価なツールを選択します。このマシンでは、トランスコードの品質はソースに制限されており、差別化要因ではありません（すべてのツールでVMAF 98.4〜99.8）。したがって、単純なトランスコードでは「品質が高いから」という理由でツールを選ばないでください。DaVinci Resolveを選択するのは、タスクが修正的または創造的（グレーディング、トーンマッピング、ノイズ除去、手ブレ補正、アップスケール、マルチクリップ仕上げ）である場合のみです。これこそが、Resolveが適切なツールとなる唯一の領域です。ResolveはFFmpegの約15倍の時間とより重いセットアップを要し、グレーディング/ノイズ除去/手ブレ補正/アップスケールにおける優位性は業界標準の期待値であり、以下のベンチマークで測定されたものではありません（そのベンチマークは単純なトランスコードのみを対象としています）。
決定木（最初に一致するルールを適用）
-
ピクセル変更なし — カット/トリミング/結合/連結/コンテナ変更/オーディオ抽出 -> FFmpeg ストリームコピー（
-c copy）。約1.2秒、ロスレス。ピクセルを変更する必要がない場合、常に最速の編集方法です。ただし、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 vs veryslowの12.6 MB）。そのため、veryslowはmediumの約6倍の時間をかける価値はほとんどありません。 -
トーキングヘッドやチュートリアル音声の無音/デッドエア除去 -> 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 mux。 注意：Blender 5.1のレンダー
image_settings.file_format列挙型には、FFMPEG/ビデオオプションがありません。image_settings.file_format='FFMPEG'やスクリプト化されたVSEビデオエクスポートを試みないでください。このビルドでは動作しません。画像フレームをレンダリングし、ffmpegでmuxしてください。 -
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/モーショングラフィックス -> フレーム -> mux
# アニメーションをPNGフレームにレンダリング（5.1では file_format='FFMPEG' を設定しないでください）
blender -b scene.blend -o "//frames/f_####" -F PNG -a
# フレームをH.264にmux（-framerate をシーンのfpsに合わせる）
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ビット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、unknown）の場合 -> すでにSDR：通常のトランスコードコマンドを使用します。
# 2. HLG/PQ -> SDR BT.709 トーンマッピング + H.264 を1パスで（出力に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は720pの15秒に約5分かかりました。すべてのツールが同じデコードコストを支払います。差別化要因はデコード後に何が起こるかだけです。 - ピクセル変更が必要ない場合（かつHEVC出力が許容される場合）は、ストリームコピー（約1.2秒）を優先してください。 再エンコードが必要で速度が重要な場合は、FFmpeg
ultrafast/veryfast（約7秒）を使用してください。 - DaVinci ResolveはFFmpegより約15倍遅く、出力をカラーマネージします（ファイルサイズが大きく、出力は意図的にソースと異なります）。グレーディング/トーンマッピング/ノイズ除去/手ブレ補正/アップスケール/創造的仕上げにのみ価値があります。
- auto-editorは長いHEVCクリップで30分以上かかることがあり、何も削除しない可能性があります。実際に間があるトーキングヘッド/チュートリアル音声でのみ実行してください。
経験的根拠（ルーティングを信頼し、小数点第2位は信頼しない）
タスク：秒数10-25をトリミング（15秒）し、HEVC->H.264 720pにトランスコード。公平なCPUタイミングのためにシリアル実行。未加工のソースに対するVMAF。映像：iPhone HEVC 720p30（9クリップセットからの代表的な1クリップ）。数値は単一実行（n=1）、繰り返しなし — 大きな差（ルーティング）は確実ですが、小さな差（例：MoviePy vs 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 mux |
| DaVinci Resolve（API、デフォルトH264） | 109s | 48.2 MB | 98.40* | 約15倍遅い、カラーマネージド；修正/創造的のみ |
| auto-editor（フル81秒クリップ） | 2021s (~34分) | — | — | 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が適切なツールです（ここでは測定されていない業界標準の期待値） — それ以外ではありません。