fqmpegで動画圧縮・エンコード：全コーデック完全ガイド

fqmpeg の C1 クラスタは、圧縮・エンコード周りの全ワークフローをカバーする 7 つの動詞で構成されている。普段使いの H.264 を扱う compress、現代的なコーデック向けの encode-h265 / encode-av1 / encode-vp9、編集中間ファイル用の encode-prores と encode-dnxhd、そしてファイルサイズを直接コントロールしたいときの bitrate。すべて実装ファイルに沿ったデフォルト値を持ち、--dry-run で実際の FFmpeg コマンドを表示し、不正な値は FFmpeg を起動する前に弾く。

この記事では各コマンドが何をするか、どんな FFmpeg フラグを生成するか、デフォルト値、出力ファイル名規則を 1 つずつ追っていく。最後の「実用ユースケース」では、これらの動詞を組み合わせた配信パイプラインの実例を扱う。すべての挙動は fqmpeg 3.0.1 の src/commands/ ソースで検証している。

この記事を読むとわかること

• 7 つの動詞をどう使い分けるか（用途別の選び方）
• 各コマンドのデフォルト値・引数範囲・出力ファイル名
• --dry-run で生成される FFmpeg コマンドの実値
• 圧縮 + 他クラスタを組み合わせた 4 つのユースケース

コーデック選び：どの動詞を使うか

コーデック選びは、まず「配信先」、次に「品質」、最後に「CPU 時間」で考える。一覧で頭に入れておくとよい。

AV1・H.265・H.264 の使い分けや、エンコード速度・ハードウェア対応・ライセンスの背景は AV1 vs H.265 vs H.264 比較 と 動画圧縮ガイド でも扱っている。

実用上、押さえるべき分岐は 2 つだ。

1. 配信用コーデック vs 編集用コーデック: 配信用（H.264 / H.265 / AV1 / VP9）は圧縮効率が高く、ファイルが小さい代わりにシーク・デコードが重い。編集用（ProRes / DNxHR）はその逆で、ファイルは 5–10 倍大きいがフレーム単位のシークが軽く、再エンコードを繰り返しても劣化が小さい。「最強のコーデック」を選ぶのではなく、「次の工程に最適なコーデック」を選ぶのが正解
2. CRF vs bitrate: 配信用 4 つのデフォルトはすべて CRF（一定品質）モードだ。難しいシーンに自動で多くのビットを割り振ってくれるので、平均的に小さく綺麗になる。bitrate を使うのは、Discord の 25 MB 上限や CMS のサイズ制限といった「ハードな予算」がある場合だけにとどめる

配信用コーデック：H.264 / H.265 / AV1 / VP9

compress — H.264 / x264（デフォルト配信）

普段使いの動詞だ。H.264 は過去 10 年に作られたほぼすべてのデバイスで再生できる。2012 年の iPhone でも、ファームウェアが古いスマート TV でも問題なく流れる。

• ソース: src/commands/compress.js
• FFmpeg エンコーダ: libx264
• 音声: AAC に再エンコード（.mp4 コンテナの定石）
• コンテナフラグ: -movflags +faststart（moov アトムをファイル先頭に移動し、ストリーミング再生時に末尾のバッファ待ちが起きないようにする）

オプション:

¹ 許容プリセット: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo。

デフォルト出力名: input-compressed.mp4（拡張子は入力から引き継ぐ）。

$ npx fqmpeg compress input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac -movflags +faststart input-compressed.mp4

オーバーライドの例:

# 高品質寄り、エンコードは遅め
npx fqmpeg compress input.mp4 --crf 18 --preset slow

# レビュー用の素早い下書き
npx fqmpeg compress input.mp4 --crf 28 --preset veryfast

encode-h265 — H.265 / HEVC

H.264 の libx264 と同じ x264/x265 系列だが、同じ品質でファイルサイズがおおむね 30〜50 % 小さくなる。トレードオフは 2 つ。エンコード速度が x264 比でかなり遅いことと、H.265 の特許がまだ生きているためブラウザのネイティブ再生対応が薄いこと。アーカイブ用、4K スマホ動画のバックアップ、Apple エコシステム内配信（HEVC をネイティブ再生してくれる）で使う。

• ソース: src/commands/encode-h265.js
• FFmpeg エンコーダ: libx265
• 音声: コピー（-c:a copy、元の音声ストリームをそのまま）
• コンテナ: Matroska（.mkv、HEVC をコンテナレベルで気にせず扱える）

デフォルト出力名: input-h265.mkv。

$ npx fqmpeg encode-h265 input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a copy input-h265.mkv

encode-av1 — AV1（libaom）

AV1 は Google・Netflix・Apple ら Alliance for Open Media が支える現代のロイヤリティフリーコーデックだ。同じ品質で H.265 より約 30 %、H.264 より約 50 % 小さくなる。代わりに libaom-av1 は 遅い。1080p で 10 分の素材を一般的なノート PC でエンコードすると 1 時間以上かかることもある。本番で使うなら SVT-AV1 のほうが速い。詳細は FFmpeg 8 SVT-AV1 最適設定 を参照。

• ソース: src/commands/encode-av1.js
• FFmpeg エンコーダ: libaom-av1
• 音声: コピー（-c:a copy）
• コンテナ: Matroska（.mkv）

エンコーダには -b:v 0 も自動で入る。これは libaom-av1 に「暗黙のビットレート上限を取り去って CRF 値を素直に尊重しろ」と指示する役割がある。

デフォルト出力名: input-av1.mkv。

$ npx fqmpeg encode-av1 input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v libaom-av1 -crf 30 -b:v 0 -cpu-used 6 -c:a copy input-av1.mkv

長尺をきっちり仕上げるときは --speed 4 か 5 を指定して放置するパターンが多い。デフォルトの 6 にしているのは短尺で待てる範囲のバランス点だからだ。

encode-vp9 — VP9 / WebM

VP9 は Google が AV1 以前に開発したコーデックだ。新規パイプラインでは AV1 に置き換わってきているが、まだ 2 つの場面で意味がある。(1) AV1 のハードウェアデコードが揃っていない古めのブラウザや埋め込み、(2) WebM コンテナ — <video> タグで MP4 を使えない場面でブラウザの優先候補になる。

• ソース: src/commands/encode-vp9.js
• FFmpeg エンコーダ: libvpx-vp9
• 音声: Opus に再エンコード（-c:a libopus、WebM 内 VP9 の標準ペア）
• コンテナ: WebM（.webm）

AV1 と同様、-b:v 0 を入れて CRF だけが品質を決める形にする。

デフォルト出力名: input-vp9.webm。

$ npx fqmpeg encode-vp9 input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 31 -b:v 0 -cpu-used 1 -c:a libopus input-vp9.webm

ビットレート指定エンコード

bitrate — H.264 ビットレート指定（ファイルサイズ制御用）

ハードなサイズ上限がある場合（Discord 無料枠の 25 MB、CMS のアップロード制限、SLA で決まった帯域）、CRF では制御できない。CRF はファイルサイズをまったく見ていないからだ。bitrate は動画と音声のレートを FFmpeg のビットレート記法で明示的に指定できる動詞だ。

• ソース: src/commands/bitrate.js
• FFmpeg エンコーダ: libx264（compress と同じ。違いは CRF モードかビットレートモードかだけ）
• 音声: AAC に再エンコード
• コンテナフラグ: -movflags +faststart

不正なレート値はバリデータが弾く: Error: video bitrate must be a number with optional k/K/m/M suffix (e.g. 1M, 2500k, 500000), got "..."。

デフォルト出力名はレート文字列をサフィックスに使う。2M 指定なら input-2M.mp4、2500k なら input-2500k.mp4。

$ npx fqmpeg bitrate input.mp4 2M --dry-run

  ffmpeg -i input.mp4 -c:v libx264 -b:v 2M -c:a aac -b:a 128k -movflags +faststart input-2M.mp4

特定のサイズ上限から逆算するには サイズ（bit）÷ 尺（秒）= 合計ビットレート を使う。そこから音声ビットレートを引いた値が <rate> に入れる動画ビットレートだ。レシピ 2 で実例を扱う。

編集用コーデック：ProRes と DNxHR

この 2 つは上の配信用コーデックとは性格が違う。中間コーデック であって、視聴者向け配信用ではなく、タイムライン上で編集するための形式だ。同じ視覚品質で H.264 の 5–10 倍のファイルサイズになるが、エンコーダはフレーム単位のシーク性能と、複数回再エンコードしても品質劣化が小さいことを優先している。「Premiere で H.264 を直接読み込んだらタイムラインがカクカクになる」のはこれで解決する。

encode-prores — Apple ProRes（Final Cut / Premiere / Resolve）

ProRes は Apple の中間コーデックで、Final Cut Pro と DaVinci Resolve のワークフローでは事実上の標準だ。Premiere・Avid もきちんと扱える。

• ソース: src/commands/encode-prores.js
• FFmpeg エンコーダ: prores_ks（kostya-sampler 系。互換性が最も広いバリアント）
• 音声: PCM 16-bit（-c:a pcm_s16le、編集系コーデックの定石である非圧縮）
• コンテナ: QuickTime（.mov）

プロファイル早見:

• proxy（1080p で約 45 Mbps）: 小さく速い、下書き編集専用
• lt（約 102 Mbps）: 「ライト」、オフライン編集向き
• standard（約 147 Mbps）: 放送品質
• hq（約 220 Mbps）: fqmpeg のデフォルト、典型的な仕上げ用マスター
• 4444（約 330 Mbps）: アルファチャネル付き、VFX コンポジット用

デフォルト出力名: input-prores.mov。

$ npx fqmpeg encode-prores input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v prores_ks -profile:v 3 -c:a pcm_s16le input-prores.mov

encode-dnxhd — Avid DNxHR（Avid Media Composer ワークフロー）

DNxHR は Avid の中間コーデックで、Avid エコシステムでの ProRes 相当だ。動詞名が dnxhd なのに 生成されるコーデックは DNxHR（旧 DNxHD の解像度非依存版）になっているので注意。出力ファイル名のサフィックスは dnxhr で、ここに合わせている。

• ソース: src/commands/encode-dnxhd.js
• FFmpeg エンコーダ: dnxhd（-profile:v で dnxhr_* プロファイルを指定）
• 音声: PCM 16-bit、48 kHz 必須（-c:a pcm_s16le -ar 48000）。DNxHR/MXF 仕様は 44.1 kHz を受け付けない
• コンテナ: MXF（.mxf、放送向けプロフェッショナルコンテナ）

プロファイル早見:

• lb（low bandwidth）: プロキシ・オフライン編集
• sq（standard quality）: 放送オンライン編集
• hq（high quality）: fqmpeg デフォルト、8-bit 4:2:2 仕上げマスター
• hqx（high quality extended）: 10-bit 4:2:2、グレーディング向きマスター
• 444（4:4:4）: アルファ付き、ProRes 4444 と同じ用途

デフォルト出力名: input-dnxhr.mxf。

$ npx fqmpeg encode-dnxhd input.mp4 --dry-run

  ffmpeg -i input.mp4 -c:v dnxhd -profile:v dnxhr_hq -c:a pcm_s16le -ar 48000 input-dnxhr.mxf

実用ユースケース

各レシピは複数の fqmpeg 動詞（クラスタを跨いで）を組み合わせ、現実の配信ワークフローを再現する。

レシピ 1: 1 つのマスターから複数プラットフォームへ

完成した 4K マスターから、互換性最優先の H.264（Web 埋め込み・メール・Discord）、YouTube アップロード用 AV1（アップロードサイズが小さく、YouTube 側のアダプティブ ABR ラダーで品質が保たれやすい）、自前ホストの <video> タグ用 VP9/WebM の 3 形式を出す。

# 互換性配信（H.264 .mp4）
npx fqmpeg compress master-4k.mp4 --crf 22 --preset slow

# YouTube アップロード候補（AV1 .mkv）— 遅いが価値がある
npx fqmpeg encode-av1 master-4k.mp4 --crf 28 --speed 4

# 自前ホスト Web 埋め込み（VP9 .webm）
npx fqmpeg encode-vp9 master-4k.mp4 --crf 31

同じマスターから走らせれば master-4k-compressed.mp4 master-4k-av1.mkv master-4k-vp9.webm の 3 つが並ぶ。AV1 のエンコードはバックグラウンドで走らせて、その間に他の作業を進められる。

レシピ 2: Discord の 25 MB 制限に収める

Discord 無料プランは 25 MB を超えるファイルを蹴る。90 秒のクリップを音声 128 kbps 込みで上限内に収めるパターン。

# Step 1: 尺をプローブ
npx fqmpeg duration input.mp4
# 0:01:30.000000  → 90 秒

# Step 2: 計算
# 予算: 25 MB = 200,000,000 bit = 200,000 kbit
# 音声予約: 128 kbps × 90 s = 11,520 kbit
# 動画予算: 200,000 - 11,520 = 188,480 kbit ÷ 90 s ≈ 2090 kbps
# 安全マージン込みで切り下げ → 1900k

# Step 3: エンコード
npx fqmpeg bitrate input.mp4 1900k

duration コマンドはハブ記事の Inspection セクションに含まれる動詞だ。パターンとしては「プローブ → 計算 → エンコード」の 3 段階。長尺をバッチ処理するならこの計算をシェルスクリプトでラップする。

レシピ 3: 編集 → 配信パイプライン

スマホで撮った生 4K 素材を Final Cut で編集し、YouTube 用に H.264 .mp4 で配信したい。H.264 → エディタ → 再エンコードのループは毎回劣化する。ProRes 中間ファイルを挟むとそれを防げる。

# Step 1: 生素材を編集用 ProRes に変換
npx fqmpeg encode-prores raw-phone.mp4 --profile lt
# → raw-phone-prores.mov（これを Final Cut で編集）

#（Final Cut で編集後、ProRes で final-edit.mov として書き出し）

# Step 2: 編集後の書き出しを YouTube 用 H.264 に圧縮
npx fqmpeg compress final-edit.mov --crf 20 --preset slow
# → final-edit-compressed.mp4

プロキシは --profile lt でファイルサイズを現実的に保つ。アルファ付きの 4444 素材（クロマキー撮影など）なら --profile 4444 を使う。

レシピ 4: HDR アーカイブ → SDR 配信

HDR（HLG または HDR10）の素材を、一般視聴者向け SDR で配信する。先にトーンマッピングして、H.265 でアーカイブする。

# Step 1: HDR → SDR トーンマッピング（C6 クラスタの別動詞）
npx fqmpeg hdr-to-sdr hdr-source.mp4
# → hdr-source-sdr.mp4

# Step 2: H.265 でアーカイブ用にエンコード
npx fqmpeg encode-h265 hdr-source-sdr.mp4 --crf 26 --preset slow
# → hdr-source-sdr-h265.mkv

hdr-to-sdr は C6 カラークラスタの動詞だ。トーンマッピングの数学的背景は FFmpeg HDR から SDR トーンマッピング で扱っている。

ハードウェアアクセラレーションの注意点

7 動詞すべてはデフォルトで ソフトウェアエンコーダ（libx264、libx265、libaom-av1、libvpx-vp9、prores_ks、dnxhd）を使う。NVIDIA の NVENC、Intel の QSV、macOS の VideoToolbox といったハードウェア対応のエンコーダは劇的に速いが、デフォルトに入れていないのは次の理由からだ。

1. 同じビットレートでもソフトウェアエンコーダより画質が劣る場合が多い
2. GPU + ドライバの組み合わせに依存する
3. 品質ノブが 1:1 で対応しない（NVENC は独自のプリセット・品質スケールを持つ）

NVENC や QSV を使いたい場合は、対象の動詞を --dry-run で実行して表示されたコマンドをコピーし、エンコーダ名を h264_nvenc、hevc_nvenc、h264_qsv などに置き換える。各ベンダー向けのフラグは GPU エンコーディングガイド を参照。

よくある質問

Q1: YouTube 用にどのコーデックを選ぶべきか

YouTube は受け取った動画を必ず再エンコードする。なのでアップロード時に与えるべきは「最も劣化していないソース」だ。CPU 時間が許すなら AV1（encode-av1）がベスト。YouTube は AV1 で受け取った素材のほうが H.264 より品質を維持してくれる傾向がある。AV1 が遅すぎる場合は compress で CRF 18 + --preset slow が現実的なフォールバック。ビットレート制限で絞ったファイルをアップロードするのは避けたほうがいい。YouTube 側のエンコーダで劣化が二重に乗る。

Q2: なぜ fqmpeg はデフォルトで CRF を使うのか

CRF はエンコーダが「必要なシーンに必要なだけビットを使う」モードだ。アクションシーンに多めに、静止シーンに少なめに割り振ってくれるので、同じファイルサイズで体感品質が高くなる。bitrate を使うべきなのは、CRF では考慮できない外部制約（ファイルサイズ上限、配信帯域）がある場合だけ。それが bitrate 動詞の役割だ。

Q3: ハードウェアエンコードに対応している？

していない。デフォルトはすべてソフトウェアエンコーダ。NVENC や QSV を使いたければ「ハードウェアアクセラレーションの注意点」の手順で --dry-run してから手動で差し替える。

Q4: なぜ encode-h265 のデフォルト CRF が 28 で、compress が 23 なのか

x264 と x265 は知覚品質スケールが異なるので、同じ数値でも同じ品質にはならない。ざっくりの目安として x264 の CRF 23 ≈ x265 の CRF 28。fqmpeg のデフォルトは各エンコーダ公式の「good quality」推奨値に合わせていて、エンコーダ間で数値を揃えていない。

Q5: ProRes と DNxHR は両方必要？

エディタで決まる。Final Cut・Premiere・DaVinci Resolve なら ProRes、Avid Media Composer なら DNxHR。中間コーデックとしての機能はほぼ等価で、選ぶ基準はエコシステム側だ。

Q6: bitrate で 2-pass エンコードできる？

bitrate 自体は 1-pass。2-pass にしたい場合は --dry-run で表示されたコマンドを使って手動でやる。先に ffmpeg ... -pass 1 -f null /dev/null を走らせて、同じコマンドを -pass 2 output.mp4 で本番実行する。ただしファイルサイズ上限用途なら 1-pass で実用上問題ないことが多い。30〜60 秒の追加時間に見合わないことが多い。

Q7: encode-av1 が遅すぎる。もっと速い方法は？

libaom-av1 はリファレンス実装で、正しいが遅い。本番向けには SVT-AV1 が同等品質で 5〜10 倍速い。SVT-AV1 はまだ fqmpeg の動詞にしていないが、フラグだけなら FFmpeg 8 SVT-AV1 最適設定 を見れば実装できる。

Q8: フォルダごと一括処理できる？

できる。fqmpeg はシェルフレンドリーだ。bash の for ループが定石。

for f in *.mp4; do npx fqmpeg compress "$f" --crf 22; done

ネストしたディレクトリなら find -exec の同等構文。各 fqmpeg 呼び出しは FFmpeg と同じ exit code で終了するので、&& で連鎖したり xargs -P で並列実行したりもできる。マニフェスト管理・リトライ・S3 アップロードまで含めるなら FFmpeg + Python バッチ自動化 で Python 側のアプローチを扱っている。

まとめ

C1 の 7 動詞は、現実の圧縮・エンコード判断をきれいにカバーする。

• compress: 「とりあえず圧縮したい」H.264 デフォルト
• encode-h265 / encode-av1 / encode-vp9: コーデック別の配信
• encode-prores / encode-dnxhd: 編集中間コーデック
• bitrate: ファイルサイズ上限がある場合

すべての動詞が --dry-run で裏側の FFmpeg コマンドを表示する。コピーして構文を学んでもいいし、CI に貼り付けてもいいし、NVENC に差し替えるなどの改造もしやすい。fqmpeg 全体の俯瞰に戻るには fqmpeg 完全ガイド ハブを参照。