ビデオ処理・編集

FFmpegベースのビデオ編集、処理自動化、および最新のコンテンツ作成ワークフロー向けエクスポート最適化の専門家です。

使用する場合

✅ 使用対象:

• 自動化されたビデオ編集パイプライン（スクリプト→ビデオ）
• クリップのカット、トリミング、結合
• トランジション、エフェクト、オーバーレイの追加
• オーディオミキシングとノーマライゼーション
• サブタイトル・キャプション処理
• プラットフォーム向けのエクスポート最適化
• バッチビデオ処理
• カラーグレーディングと補正

❌ 使用非対象:

• リアルタイムビデオ編集UI（DaVinci Resolve/Premiereを使用）
• 3Dコンポジティング（After Effects/Blenderを使用）
• モーショングラフィックスアニメーション（After Effectsを使用）
• 基本的な画面録画（OBSを使用）

---

テクノロジー選択

ビデオ編集ツール

ツール	速度	機能	ユースケース
FFmpeg	非常に高速	CLI自動化	プロダクションパイプライン
MoviePy	中程度	Python API	プログラマティック編集
PyAV	高速	低レベルコントロール	カスタム処理
DaVinci Resolve	遅い	フル機能NLE	手動編集

判断フロー:

自動化が必要? → FFmpeg
Python APIが必要? → MoviePy
フレームレベルのコントロール? → PyAV
手動編集が必要? → DaVinci Resolve

---

一般的なアンチパターン

アンチパターン1: キーフレーム対応カットを使用しない

初心者の考え: 「任意のタイムスタンプでビデオをカットするだけ」

問題: アーティファクト、黒フレーム、再生の問題が発生します。

間違ったアプローチ:

# ❌ 任意のタイムスタンプでカット（キーフレーム非対応）
ffmpeg -i input.mp4 -ss 00:01:23.456 -to 00:02:45.678 -c copy output.mp4

# 結果: 黒フレーム、アーティファクト、同期の問題

なぜ間違っているのか:

• ビデオコーデックは2～10秒ごとにキーフレーム（Iフレーム）を使用
• キーフレーム以外でのカットは再エンコーディングが必要
• -c copy（ストリームコピー）をキーフレーム対応なしで使用すると再生が破損
• GOP（Group of Pictures）構造はキーフレームに依存

正しいアプローチ1: 正確なカット用に再エンコード

# ✅ フレーム精度のカット用に再エンコード
ffmpeg -i input.mp4 -ss 00:01:23.456 -to 00:02:45.678 \
  -c:v libx264 -crf 18 -preset medium \
  -c:a aac -b:a 192k \
  output.mp4

# フレーム精度ですが、遅い（再エンコーディング）

正しいアプローチ2: キーフレーム対応ストリームコピー

# ✅ キーフレーム対応で高速カット
# ステップ1: カット地点近くのキーフレームを検索
ffprobe -select_streams v -show_frames -show_entries frame=pkt_pts_time,key_frame \
  -of csv input.mp4 | grep ",1$" | awk -F',' '{print $2}'

# ステップ2: 最寄りのキーフレームでカット（高速、再エンコーディングなし）
ffmpeg -i input.mp4 -ss 00:01:22.000 -to 00:02:46.000 -c copy output.mp4

# 高速、品質低下なし、ただしフレーム精度ではない

正しいアプローチ3: 両方の利点をえるための2パス処理

# ✅ 高速シーク＋正確なカット
ffmpeg -ss 00:01:20.000 -i input.mp4 \
  -ss 00:00:03.456 -to 00:01:25.678 \
  -c:v libx264 -crf 18 -preset medium \
  -c:a aac -b:a 192k \
  output.mp4

# -ss BEFORE -i: キーフレームへの高速シーク（デコードなし）
# -ss AFTER -i: 正確なトリム（必要な部分のみをデコード）

パフォーマンス比較:

方法	時間（1時間ビデオ）	精度	品質
ストリームコピー（任意）	2秒	❌ 破損	❌ アーティファクト
ストリームコピー（キーフレーム）	2秒	±2秒	✅ 完璧
再エンコード（シンプル）	15分	✅ フレーム	⚠️ 品質低下
2パス（最適）	3分	✅ フレーム	✅ 完璧

タイムラインコンテキスト:

• 2010年: FFmpegはカット用に完全再エンコーディングが必要
• 2015年: -c copyでストリームコピーが追加
• 2020年: 2パスカットがベストプラクティスになった
• 2024年: ハードウェアアクセラレーション（NVENC）で再エンコーディングが実行可能に

---

アンチパターン2: 不要な再エンコーディング

初心者の考え: 「すべての編集を1つのFFmpegコマンドで適用」

問題: 複数の再エンコーディングにより累積的な品質低下が生じます。

間違ったアプローチ:

# ❌ 各操作で再エンコード（品質劣化）
# 操作1: トリミング
ffmpeg -i input.mp4 -ss 00:01:00 -to 00:05:00 \
  -c:v libx264 -crf 23 temp1.mp4

# 操作2: オーディオ追加
ffmpeg -i temp1.mp4 -i audio.mp3 -c:v libx264 -crf 23 \
  -map 0:v -map 1:a temp2.mp4

# 操作3: サブタイトル追加
ffmpeg -i temp2.mp4 -vf subtitles=subs.srt \
  -c:v libx264 -crf 23 output.mp4

# 結果: 3倍の再エンコーディング = 大幅な品質低下

なぜ間違っているのか:

• 各再エンコーディングはロッシー（高CRFでも）
• 累積的な品質低下（ジェネレーションロス）
• 3倍のエンコーディング時間
• ディスクI/Oの無駄

正しいアプローチ1: 単一コマンドで操作をチェーン

# ✅ すべての操作を含む単一パスエンコーディング
ffmpeg -ss 00:01:00 -i input.mp4 -i audio.mp3 \
  -to 00:04:00 \
  -vf "subtitles=subs.srt" \
  -map 0:v -map 1:a \
  -c:v libx264 -crf 18 -preset medium \
  -c:a aac -b:a 192k \
  output.mp4

# 単一の再エンコーディング、すべての操作を一度に適用

正しいアプローチ2: 可能な場合はストリームコピーを使用

# ✅ ストリームコピーでロッシーレス操作
# トリミング（ストリームコピー）
ffmpeg -i input.mp4 -ss 00:01:00 -to 00:05:00 -c copy temp.mp4

# オーディオ追加（ビデオはストリームコピー、オーディオはエンコード）
ffmpeg -i temp.mp4 -i audio.mp3 \
  -map 0:v -map 1:a \
  -c:v copy -c:a aac -b:a 192k \
  temp2.mp4

# サブタイトルバーン（ビデオは再エンコード必須）
ffmpeg -i temp2.mp4 -vf subtitles=subs.srt \
  -c:v libx264 -crf 18 -preset medium \
  -c:a copy \
  output.mp4

# ビデオ再エンコーディングは1回のみ（サブタイトル用）

品質比較:

方法	エンコーディングパス	品質（VMAF）	時間
3倍再エンコード（CRF 23）	3	82/100	45分
単一パス（CRF 23）	1	91/100	15分
ストリームコピー＋1エンコード	1	95/100	18分
すべてストリームコピー	0	100/100	30秒

---

アンチパターン3: カラースペース変換を無視

初心者の考え: 「ビデオを結合するだけ」

問題: 色シフト、明るさの不一致、再生の破損が生じます。

間違ったアプローチ:

# ❌ 異なるカラースペースのビデオを結合
# clip1.mp4: BT.709 (HD), yuv420p
# clip2.mp4: BT.601 (SD), yuvj420p (フルレンジ)
# clip3.mp4: BT.2020 (HDR), yuv420p10le

# 結合リスト作成
echo "file 'clip1.mp4'" > list.txt
echo "file 'clip2.mp4'" >> list.txt
echo "file 'clip3.mp4'" >> list.txt

# カラー正規化なしで結合
ffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4

# 結果: クリップ間の色シフト、壊れたHDRメタデータ

なぜ間違っているのか:

• 異なるカラースペース（BT.601 vs BT.709 vs BT.2020）
• 異なるピクセルフォーマット（yuv420p vs yuvj420p）
• 異なるカラーレンジ（リミテッド vs フル）
• メタデータの競合

正しいアプローチ:

# ✅ 結合前にカラースペースを正規化

# ステップ1: 各クリップのカラースペースを分析
ffprobe -v error -select_streams v:0 \
  -show_entries stream=color_space,color_transfer,color_primaries,pix_fmt \
  -of default=noprint_wrappers=1 clip1.mp4

# ステップ2: すべてのクリップを共通カラースペースに正規化
# 対象: BT.709 (HD), yuv420p, リミテッドレンジ

# clip1を正規化（すでにBT.709）
ffmpeg -i clip1.mp4 -c copy clip1_normalized.mp4

# clip2を正規化（BT.601 SD → BT.709 HD）
ffmpeg -i clip2.mp4 \
  -vf "scale=in_range=full:out_range=limited,colorspace=bt709:iall=bt601:fast=1" \
  -color_primaries bt709 \
  -color_trc bt709 \
  -colorspace bt709 \
  -c:v libx264 -crf 18 -preset medium \
  -c:a copy \
  clip2_normalized.mp4

# clip3を正規化（BT.2020 HDR → BT.709 SDR）
ffmpeg -i clip3.mp4 \
  -vf "zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=limited,format=yuv420p" \
  -color_primaries bt709 \
  -color_trc bt709 \
  -colorspace bt709 \
  -c:v libx264 -crf 18 -preset medium \
  -c:a copy \
  clip3_normalized.mp4

# ステップ3: 正規化されたクリップを結合
echo "file 'clip1_normalized.mp4'" > list.txt
echo "file 'clip2_normalized.mp4'" >> list.txt
echo "file 'clip3_normalized.mp4'" >> list.txt

ffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4

カラースペースガイド:

標準	カラースペース	トランスファー	プライマリ	ユースケース
BT.601	SD	bt470bg	bt470bg	古いSD コンテンツ
BT.709	HD	bt709	bt709	最新のHD/FHD
BT.2020	UHD/HDR	smpte2084	bt2020	4K HDR
sRGB	Web	iec61966-2-1	bt709	ウェブ配信

---

アンチパターン4: 不十分なオーディオ同期

初心者の考え: 「ビデオとオーディオは別物、重ねるだけ」

問題: リップシンク問題、オーディオドリフト、再生が破損します。

間違ったアプローチ:

# ❌ 同期を考慮せずオーディオを置き換え
ffmpeg -i video.mp4 -i audio.mp3 \
  -map 0:v -map 1:a \
  -c:v copy -c:a copy \
  output.mp4

# 問題:
# - オーディオの長さ ≠ ビデオの長さ
# - オーディオのストレッチ/圧縮なし
# - 時間経過による遅延
# - 元のオーディオ同期を無視

なぜ間違っているのか:

• オーディオとビデオの長さが異なる
• タイムベース同期がない
• ドリフト補正なし
• 元のオーディオ同期を無視

正しいアプローチ1: ビデオの長さに合わせてオーディオをストレッチ/圧縮

# ✅ ビデオの長さに合わせてオーディオを調整

# 長さを取得
VIDEO_DUR=$(ffprobe -v error -show_entries format=duration \
  -of default=noprint_wrappers=1:nokey=1 video.mp4)
AUDIO_DUR=$(ffprobe -v error -show_entries format=duration \
  -of default=noprint_wrappers=1:nokey=1 audio.mp3)

# スピード比を計算
RATIO=$(echo "$VIDEO_DUR / $AUDIO_DUR" | bc -l)

# オーディオをビデオに合わせて拡張（ピッチ補正付き）
ffmpeg -i video.mp4 -i audio.mp3 \
  -filter_complex "[1:a]atempo=${RATIO}[a]" \
  -map 0:v -map "[a]" \
  -c:v copy -c:a aac -b:a 192k \
  output.mp4

正しいアプローチ2: 正確なオフセットとトリム

# ✅ オフセットとトリムでオーディオを同期

# オーディオが0.5秒遅れている場合、ビデオと一致するようにトリム
ffmpeg -i video.mp4 -itsoffset 0.5 -i audio.mp3 \
  -map 0:v -map 1:a \
  -shortest \
  -c:v copy -c:a aac -b:a 192k \
  output.mp4

# -itsoffset: オーディオを0.5秒遅延
# -shortest: 最短ストリームにトリム

正しいアプローチ3: 複数のオーディオトラックを正確なタイミングでミックス

# ✅ ダイアログ、音楽、効果音を正確なタイミングでミックス

ffmpeg -i video.mp4 -i dialogue.wav -i music.mp3 -i sfx.wav \
  -filter_complex "
    [1:a]adelay=0|0[dlg];
    [2:a]volume=0.3,adelay=500|500[mus];
    [3:a]adelay=1200|1200[sfx];
    [dlg][mus][sfx]amix=inputs=3:duration=first[a]
  " \
  -map 0:v -map "[a]" \
  -c:v copy -c:a aac -b:a 256k \
  output.mp4

# adelay: ミリ秒単位の正確なタイミング
# amix: 複数のオーディオストリームをミックス
# volume: レベルを正規化

オーディオ同期チェックリスト:

□ ビデオとオーディオの長さが一致することを確認
□ オーディオ超過を防ぐため-shortestを使用
□ 正確なタイミングオフセット用にadelayを適用
□ スピード調整にatempoを使用（ピッチ維持）
□ オーディオビットレートを適切に設定（128k-256k）
□ 開始、中間、終了時点でリップシンクをテスト

---

アンチパターン5: プラットフォーム向け間違ったコーデック/ビットレート

初心者の考え: 「すべてに同じエクスポート設定を使用」

問題: 帯域幅の無駄、品質低下、アップロード拒否、互換性の問題が生じます。

間違ったアプローチ:

# ❌ すべてを4K 50 Mbpsでエクスポート
ffmpeg -i input.mp4 \
  -c:v libx264 -b:v 50M -s 3840x2160 \
  -c:a aac -b:a 320k \
  output.mp4

# Instagramストーリー: 2 GBファイル、拒否（最大100 MB）
# YouTube: 10 Mbpsで十分で見分けがつかない
# Twitter: ビットレート制限を超える

なぜ間違っているのか:

• プラットフォーム固有のサイズ/ビットレート制限
• 過度なエンコーディングは帯域幅を無駄
• プラットフォーム向けの解像度が不適切
• 互換性のないコーデック

正しいアプローチ: プラットフォーム最適化エクスポート

YouTube（推奨設定）:

# ✅ YouTube 1080p アップロード
ffmpeg -i input.mp4 \
  -c:v libx264 -preset slow -crf 18 \
  -s 1920x1080 -r 30 \
  -pix_fmt yuv420p \
  -color_primaries bt709 -color_trc bt709 -colorspace bt709 \
  -movflags +faststart \
  -c:a aac -b:a 192k -ar 48000 \
  youtube_1080p.mp4

# YouTube 4K アップロード
ffmpeg -i input.mp4 \
  -c:v libx264 -preset slow -crf 18 \
  -s 3840x2160 -r 60 \
  -pix_fmt yuv420p \
  -movflags +faststart \
  -c:a aac -b:a 256k -ar 48000 \
  youtube_4k.mp4

Instagram（ストーリー、リール、フィード）:

# ✅ Instagramストーリー（9:16、最大100 MB、15秒）
ffmpeg -i input.mp4 \
  -c:v libx264 -preset medium -crf 23 \
  -s 1080x1920 -r 30 -t 15 \
  -pix_fmt yuv420p \
  -movflags +faststart \
  -c:a aac -b:a 128k \
  instagram_story.mp4

# ✅ Instagramリール（9:16、最大90秒）
ffmpeg -i input.mp4 \
  -c:v libx264 -preset medium -crf 23 \
  -s 1080x1920 -r 30 -t 90 \
  -pix_fmt yuv420p \
  -movflags +faststart \
  -c:a aac -b:a 128k \
  instagram_reel.mp4

# ✅ Instagramフィード（1:1 または 4:5）
ffmpeg -i input.mp4 \
  -c:v libx264 -preset medium -crf 23 \
  -s 1080x1080 -r 30 \
  -pix_fmt yuv420p \
  -movflags +faststart \
  -c:a aac -b:a 128k \
  instagram_feed.mp4

Twitter/X:

# ✅ Twitter動画（最大512 MB、2:20）
ffmpeg -i input.mp4 \
  -c:v libx264 -preset medium -crf 23 \
  -s 1280x720 -r 30 -t 140 \
  -maxrate 5000k -bufsize 10000k \
  -pix_fmt yuv420p \
  -movflags +faststart \
  -c:a aac -b:a 128k \
  twitter.mp4

TikTok:

# ✅ TikTok（9:16、最大287 MB、10分）
ffmpeg -i input.mp4 \
  -c:v libx264 -preset medium -crf 23 \
  -s 1080x1920 -r 30 -t 600 \
  -pix_fmt yuv420p \
  -movflags +faststart \
  -c:a aac -b:a 128k \
  tiktok.mp4

ウェブ（HTML5 ビデオ）:

# ✅ ウェブ最適化（高速読み込み、幅広い互換性）
ffmpeg -i input.mp4 \
  -c:v libx264 -preset medium -crf 23 \
  -s 1920x1080 -r 30 \
  -pix_fmt yuv420p \
  -profile:v baseline -level 3.0 \
  -movflags +faststart \
  -c:a aac -b:a 128k -ar 48000 \
  web.mp4

プラットフォーム仕様表:

プラットフォーム	最大サイズ	最大長	解像度	FPS	ビットレート	コーデック
YouTube	無制限	無制限	8K	60	自動	H.264/VP9
Instagramストーリー	100 MB	15秒	1080x1920	30	約5 Mbps	H.264
Instagramリール	1 GB	90秒	1080x1920	30	約8 Mbps	H.264
Twitter	512 MB	2:20	1920x1080	60	5 Mbps	H.264
TikTok	287 MB	10分	1080x1920	30	約4 Mbps	H.264
LinkedIn	5 GB	10分	1920x1080	30	5 Mbps	H.264
ウェブ	可変	可変	1920x1080	30	2-5 Mbps	H.264

エクスポート最適化チェックリスト:

□ ウェブ用に-movflags +faststartを使用（プログレッシブダウンロード）
□ 広い互換性のため-pix_fmt yuv420pを使用
□ ほとんどのプラットフォームに-r 30を設定（可変フレームレート回避）
□ 最終エクスポート用に-preset slowを使用（より良い品質）
□ ドラフト用に-preset ultrafastを使用
□ ストリーミング用に-maxrateと-bufsizeを適用
□ 一括エクスポート前にターゲットプラットフォームで再生テスト

---

制作チェックリスト

□ カットをキーフレームに合わせる（または2パスシーク）
□ 操作を単一FFmpegコマンドでチェーン
□ 結合前にカラースペースを正規化
□ オーディオ/ビデオ同期を検証（複数地点でテスト）
□ プラットフォーム固有のエクスポートプリセットを使用
□ ウェブ配信用に-movflags +faststartを適用
□ 適切なカラーメタデータを設定（HDD用BT.709）
□ ターゲットプラットフォームで出力ファイルをテスト
□ ロッシーレス中間ファイルを保持（ProRes、FFV1）
□ バッチジョブ用にハードウェアアクセラレーションを使用（NVENC、VideoToolbox）

---

使用場面 vs 使用非対象

シナリオ	適切か
自動化ビデオパイプライン（スクリプト → ビデオ）	✅ はい - FFmpeg自動化
100個のビデオをバッチ処理	✅ はい - 並列FFmpegジョブ
クリップをプログラマティックにトリム/カット	✅ はい - 正確なカット
ビデオにサブタイトルを追加	✅ はい - バーンまたはソフトサブ
フッテージのカラーグレーディング	⚠️ 限定的 - 基本のみ
マルチカメラ編集	❌ いいえ - DaVinci Resolveを使用
モーショングラフィックス	❌ いいえ - After Effectsを使用
リアルタイムプレビュー編集	❌ いいえ - Premiere/Resolveを使用

---

参考資料

• /references/ffmpeg-guide.md - FFmpegコマンドリファレンス完全版
• /references/timeline-editing.md - タイムラインコンセプト、マルチトラック編集
• /references/export-optimization.md - プラットフォーム固有のエクスポート設定

スクリプト

• scripts/video_editor.py - カット、トリム、結合、トランジション、エフェクト
• scripts/batch_processor.py - 並列バッチビデオ処理

---

このスキルが対象とするもの: ビデオ編集 | FFmpeg | タイムライン編集 | トランジション | エクスポート最適化 | オーディオミキシング | カラーグレーディング | 自動化ビデオ制作