FFmpeg で動画をエンコードする際、どのコーデックを選ぶべきか迷ったことはありませんか？H.264、H.265、AV1、VP9、ProRes、DNxHR など、コーデックの選択肢は年々増えています。

「ファイルサイズを小さくしたい」「編集しやすい中間フォーマットが欲しい」「Web 配信に最適化したい」など、用途によって最適なコーデックは大きく異なります。しかし、それぞれの特性や使いどころを理解せずに選ぶと、エンコード時間の無駄遣いや画質の劣化、互換性の問題に悩まされることもあるでしょう。

本記事では、2025 年現在主流となっている 6 つのコーデック（H.264／H.265／AV1／VP9／ProRes／DNxHR）について、それぞれの特性、メリット・デメリット、具体的な FFmpeg コマンド例を交えて詳しく解説します。この記事を読めば、プロジェクトごとに最適なコーデックを自信を持って選択できるようになるはずです。

背景

動画コーデックは、動画データを圧縮・展開するためのアルゴリズムを指します。コーデックの選択は、ファイルサイズ、画質、エンコード速度、デコード速度、互換性など、さまざまな要素に影響を与えますね。

近年、インターネット動画配信の普及や 4K／8K 映像の一般化により、より高効率な圧縮技術が求められるようになりました。一方で、動画編集やプロフェッショナル用途では、圧縮率よりも画質保持や編集の快適さを重視する場面も多いです。

以下の図は、動画コーデックの主な分類と、それぞれの代表的なコーデックを示しています。

mermaidCopy codeflowchart TB
  root["動画コーデック"]
  配信用["配信用<br/>高圧縮コーデック"]
  編集用["編集用<br/>中間コーデック"]

  root --> 配信用
  root --> 編集用

  配信用 --> h264["H.264/AVC"]
  配信用 --> h265["H.265/HEVC"]
  配信用 --> av1["AV1"]
  配信用 --> vp9["VP9"]

  編集用 --> prores["ProRes"]
  編集用 --> dnxhr["DNxHR"]

図の要点：

• 動画コーデックは大きく「配信用（高圧縮）」と「編集用（中間）」に分類されます
• 配信用は H.264、H.265、AV1、VP9 など、ファイルサイズを抑えることが重視されます
• 編集用は ProRes、DNxHR など、画質保持と編集の快適さが優先されるのです

コーデックの歴史的変遷

動画コーデックは時代とともに進化してきました。以下の表は、主要コーデックの登場年と主な特徴をまとめたものです。

#	コーデック	登場年	主な特徴
1	H.264/AVC	2003 年	DVD やブルーレイ、Web 配信で広く普及
2	VP9	2013 年	Google 開発、YouTube で採用
3	H.265/HEVC	2013 年	H.264 の約 2 倍の圧縮効率
4	AV1	2018 年	ロイヤリティフリー、次世代コーデック
5	ProRes	2007 年	Apple 開発、編集用中間コーデック
6	DNxHR	2014 年	Avid 開発、編集用中間コーデック

H.264 は 20 年以上前に登場したコーデックですが、現在でも最も広く使われているコーデックの一つです。その後、より高効率な H.265 や AV1 が登場し、配信用途でのファイルサイズ削減が進んでいます。

一方、ProRes や DNxHR は編集用途に特化しており、圧縮率よりも画質保持と編集時のパフォーマンスを重視しているのが特徴でしょう。

課題

動画コーデックの選択は、以下のような課題を抱えています。

課題 1：用途に応じた最適なコーデックがわかりにくい

配信用、編集用、アーカイブ用など、用途によって求められる特性は異なります。しかし、各コーデックの特性を理解せずに選択すると、エンコード時間やファイルサイズ、画質などで最適な結果が得られません。

例えば、Web 配信用の動画を ProRes でエンコードすると、ファイルサイズが大きくなりすぎて配信に不向きですし、編集用の中間ファイルを AV1 でエンコードすると、デコード負荷が高くて編集作業が快適に進まないでしょう。

課題 2：圧縮効率とエンコード時間のトレードオフ

高圧縮率のコーデック（H.265、AV1）は、ファイルサイズを大幅に削減できますが、エンコード時間が長くなる傾向があります。一方、エンコードが高速なコーデック（H.264）は、ファイルサイズが大きくなりがちです。

また、エンコード設定（プリセット、CRF 値など）によっても、品質とエンコード時間のバランスが変わります。

課題 3：互換性と将来性のバランス

H.264 は互換性が高く、ほぼすべてのデバイスで再生できますが、圧縮効率は最新のコーデックに劣ります。逆に、AV1 は高効率ですが、古いデバイスではサポートされていないこともありますね。

以下の図は、コーデック選択時の主な課題を整理したものです。

mermaidCopy codeflowchart LR
  選択課題["コーデック<br/>選択の課題"]

  用途["用途の明確化"]
  性能["性能要件"]
  互換性["互換性"]

  選択課題 --> 用途
  選択課題 --> 性能
  選択課題 --> 互換性

  用途 --> 用途1["配信用"]
  用途 --> 用途2["編集用"]
  用途 --> 用途3["アーカイブ用"]

  性能 --> 性能1["エンコード時間"]
  性能 --> 性能2["ファイルサイズ"]
  性能 --> 性能3["画質"]

  互換性 --> 互換性1["デバイス対応"]
  互換性 --> 互換性2["将来性"]
  互換性 --> 互換性3["ライセンス"]

図の要点：

• コーデック選択には「用途」「性能」「互換性」の 3 つの軸があります
• 用途では、配信、編集、アーカイブのどれを重視するかを決めます
• 性能では、エンコード時間、ファイルサイズ、画質のバランスを考慮するのです
• 互換性では、デバイス対応、将来性、ライセンスを検討する必要があるでしょう

解決策

各コーデックの特性を理解し、用途に応じて適切に使い分けることで、上記の課題を解決できます。以下、各コーデックの特徴と使いどころを詳しく見ていきましょう。

H.264/AVC：互換性と汎用性の王道

H.264（正式名称：AVC／Advanced Video Coding）は、2003 年に標準化された動画コーデックです。20 年以上の歴史がありますが、現在でも最も広く使われているコーデックでしょう。

特徴

#	項目	内容
1	互換性	ほぼすべてのデバイス・ブラウザで再生可能
2	エンコード速度	高速（ハードウェアエンコーダーも広く普及）
3	圧縮効率	中程度（新しいコーデックと比べると劣る）
4	ライセンス	特許プール（商用利用には注意が必要）

使いどころ

• Web 配信：最大限の互換性を求める場合
• モバイル向け配信：古い端末でも確実に再生したい場合
• リアルタイム配信：エンコード速度が重要な場合
• 汎用的なアーカイブ：将来的な再生互換性を重視する場合

デメリット

• 4K 以上の高解像度では、ファイルサイズが大きくなりやすいです
• 最新のコーデックと比較すると、圧縮効率が劣ります

H.265/HEVC：高圧縮率の次世代標準

H.265（正式名称：HEVC／High Efficiency Video Coding）は、2013 年に標準化された、H.264 の後継コーデックです。H.264 と比較して約 2 倍の圧縮効率を実現しています。

特徴

#	項目	内容
1	圧縮効率	H.264 の約 2 倍
2	互換性	比較的高い（2015 年以降のデバイスで対応）
3	エンコード速度	H.264 より遅い
4	ライセンス	特許プール（複雑なライセンス体系）

使いどころ

• 4K／8K 動画配信：高解像度でファイルサイズを抑えたい場合
• ストレージ節約：品質を保ちつつファイルサイズを削減したい場合
• モバイル配信：帯域幅を節約したい場合
• HDR 動画：広色域や高ダイナミックレンジを扱う場合

デメリット

• エンコード時間が H.264 より長くなります
• ライセンス費用が複雑で、商用利用時に注意が必要です
• 古いデバイスでは再生できないことがあるでしょう

AV1：ロイヤリティフリーの次世代コーデック

AV1 は、Alliance for Open Media（AOMedia）によって 2018 年に標準化された、完全にロイヤリティフリーのコーデックです。Google、Netflix、Amazon、Apple など、主要企業が支援しています。

特徴

#	項目	内容
1	圧縮効率	H.265 より約 30% 向上
2	ライセンス	完全にロイヤリティフリー
3	エンコード速度	非常に遅い（改善中）
4	互換性	新しいブラウザ・デバイスで対応が進む

使いどころ

• Web 配信（最新ブラウザ）：Chrome、Firefox、Edge などの最新版
• ストリーミングサービス：Netflix、YouTube などがすでに採用
• ライセンスフリーが重要な場合：特許料を避けたいプロジェクト
• 将来を見据えたアーカイブ：次世代標準として期待される

デメリット

• エンコード時間が非常に長いです（H.265 の数倍）
• 古いデバイスでは再生できません
• ハードウェアエンコーダー・デコーダーの普及が進行中でしょう

VP9：Google 主導のオープンコーデック

VP9 は、Google が開発したロイヤリティフリーのコーデックで、2013 年に公開されました。YouTube で広く採用されています。

特徴

#	項目	内容
1	圧縮効率	H.264 より約 50% 向上
2	ライセンス	ロイヤリティフリー
3	エンコード速度	H.264 より遅い、AV1 より速い
4	互換性	Chrome、Firefox で広くサポート

使いどころ

• YouTube 配信：YouTube が標準で採用
• Web 配信（Chrome／Firefox）：これらのブラウザがターゲットの場合
• ライセンスフリーが重要な場合：AV1 より軽量な代替
• 4K 配信：H.264 よりファイルサイズを削減したい場合

デメリット

• Safari や一部のデバイスで非対応です
• AV1 の登場により、将来的には置き換わる可能性があるでしょう
• H.265 と比較すると、圧縮効率がやや劣ります

ProRes：Apple の編集用中間コーデック

ProRes は、Apple が開発した編集用の中間コーデックです。2007 年に登場し、プロフェッショナルな動画編集現場で広く使われています。

特徴

#	項目	内容
1	画質	非常に高い（ほぼロスレス）
2	編集性	イントラフレーム圧縮で編集に最適
3	ファイルサイズ	非常に大きい
4	デコード速度	非常に高速

ProRes には、用途に応じた複数のプロファイルがあります。

#	プロファイル	ビットレート	用途
1	ProRes 422 Proxy	低	オフライン編集、プレビュー
2	ProRes 422 LT	中	一般的な編集作業
3	ProRes 422	中高	放送品質の編集
4	ProRes 422 HQ	高	高品質な編集・グレーディング
5	ProRes 4444	最高	アルファチャンネル、広色域対応

使いどころ

• 動画編集の中間ファイル：DaVinci Resolve、Final Cut Pro、Premiere Pro など
• カラーグレーディング：色情報を保持したい場合
• アルファチャンネル：透過情報が必要な場合（ProRes 4444）
• Apple 環境：macOS や iOS デバイスでネイティブサポート

デメリット

• ファイルサイズが非常に大きいです
• 配信用途には不向きでしょう
• Windows でのサポートは限定的です（FFmpeg では利用可能）

DNxHR：Avid の編集用中間コーデック

DNxHR は、Avid が開発した編集用の中間コーデックで、2014 年に登場しました。ProRes の対抗として、Windows 環境でも広くサポートされています。

特徴

#	項目	内容
1	画質	非常に高い
2	編集性	イントラフレーム圧縮で編集に最適
3	ファイルサイズ	非常に大きい
4	クロスプラットフォーム	macOS、Windows、Linux で対応

DNxHR にも、複数のプロファイルがあります。

#	プロファイル	ビットレート	用途
1	DNxHR LB	低	オフライン編集、プレビュー
2	DNxHR SQ	中	一般的な編集作業
3	DNxHR HQ	中高	高品質な編集
4	DNxHR HQX	高	カラーグレーディング、広色域
5	DNxHR 444	最高	アルファチャンネル、最高品質

使いどころ

• 動画編集の中間ファイル：Avid Media Composer、DaVinci Resolve、Premiere Pro など
• クロスプラットフォーム環境：Windows と macOS を混在させる場合
• カラーグレーディング：色情報を保持したい場合
• アルファチャンネル：透過情報が必要な場合（DNxHR 444）

デメリット

• ファイルサイズが非常に大きいです
• 配信用途には不向きでしょう
• ProRes と比較すると、Apple 環境でのサポートがやや劣ります

コーデック選択フローチャート

以下の図は、用途に応じたコーデック選択のフローチャートです。

mermaidCopy codeflowchart TD
  start["コーデックを<br/>選択する"]

  用途{用途は？}
  配信["配信用"]
  編集["編集用"]

  start --> 用途
  用途 -->|配信| 配信
  用途 -->|編集| 編集

  互換性{互換性<br/>重視？}
  圧縮{圧縮効率<br/>重視？}

  配信 --> 互換性
  互換性 -->|はい| h264_choice["H.264"]
  互換性 -->|いいえ| 圧縮

  圧縮 -->|最高| av1_choice["AV1"]
  圧縮 -->|高| h265_choice["H.265"]
  圧縮 -->|中| vp9_choice["VP9"]

  環境{Apple<br/>環境？}

  編集 --> 環境
  環境 -->|はい| prores_choice["ProRes"]
  環境 -->|いいえ| dnxhr_choice["DNxHR"]

図で理解できる要点：

• まず「配信用」か「編集用」かを決めます
• 配信用では、互換性を重視するなら H.264、圧縮効率を重視するなら AV1 や H.265 を選びましょう
• 編集用では、Apple 環境なら ProRes、それ以外なら DNxHR が適しています

具体例

ここからは、FFmpeg を使った各コーデックの具体的なエンコード例を紹介します。実際のコマンドとともに、パラメータの意味や使い分けのポイントを解説していきますね。

H.264 エンコード例

H.264 でエンコードする際の基本的なコマンド例です。

基本的なエンコード

bashCopy codeffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k output.mp4

パラメータの説明：

• -c:v libx264：H.264 エンコーダーを使用
• -preset medium：エンコード速度と圧縮効率のバランス
• -crf 23：品質設定（0-51、低いほど高品質、18-28 が推奨）
• -c:a aac：音声を AAC でエンコード
• -b:a 128k：音声ビットレート 128kbps

プリセットの使い分け

プリセットは、エンコード速度と圧縮効率のバランスを調整します。

#	プリセット	エンコード速度	ファイルサイズ	用途
1	ultrafast	最速	最大	リアルタイム配信
2	superfast	非常に速い	大きい	クイックプレビュー
3	veryfast	速い	やや大きい	一般的な配信
4	faster	やや速い	中程度	バランス重視
5	fast	普通	中程度	バランス重視
6	medium	普通	標準	デフォルト推奨
7	slow	遅い	小さい	高品質配信
8	slower	非常に遅い	より小さい	アーカイブ
9	veryslow	最も遅い	最小	最高品質

2 パスエンコード

より高品質なエンコードを行う場合は、2 パスエンコードを使用します。

bashCopy code# 1 パス目（解析）
ffmpeg -i input.mp4 -c:v libx264 -preset slow -b:v 2M -pass 1 -an -f mp4 /dev/null

1 パス目では、動画の特性を解析します。

• -pass 1：1 パス目を指定
• -an：音声をエンコードしない（時間短縮）
• -f mp4 ​/​dev​/​null：出力をダミーファイルに（Windows では NUL）

bashCopy code# 2 パス目（エンコード）
ffmpeg -i input.mp4 -c:v libx264 -preset slow -b:v 2M -pass 2 -c:a aac -b:a 128k output.mp4

2 パス目では、1 パス目の解析結果を使って最適なエンコードを行います。

• -pass 2：2 パス目を指定
• -b:v 2M：ビットレート 2Mbps を指定

H.265 エンコード例

H.265 でエンコードする際の基本的なコマンド例です。

基本的なエンコード

bashCopy codeffmpeg -i input.mp4 -c:v libx265 -preset medium -crf 28 -c:a aac -b:a 128k output.mp4

パラメータの説明：

• -c:v libx265：H.265 エンコーダーを使用
• -crf 28：H.264 の crf 23 と同程度の品質

H.265 は H.264 より圧縮効率が高いため、同じファイルサイズで高品質を得るには、crf 値を 4-6 程度上げるのが目安です。

4K 動画のエンコード

4K 動画を H.265 でエンコードする例です。

bashCopy codeffmpeg -i input_4k.mp4 \
  -c:v libx265 \
  -preset slow \
  -crf 24 \
  -pix_fmt yuv420p10le \
  -c:a aac \
  -b:a 192k \
  output_4k.mp4

パラメータの説明：

• -pix_fmt yuv420p10le：10 ビット色深度を使用（より高品質）
• -b:a 192k：音声ビットレートを高めに設定

10 ビット色深度は、グラデーションのバンディング（階調のムラ）を軽減します。

ハードウェアエンコード（NVIDIA GPU）

NVIDIA の GPU を使ってエンコードを高速化する例です。

bashCopy codeffmpeg -i input.mp4 \
  -c:v hevc_nvenc \
  -preset p4 \
  -cq 28 \
  -c:a aac \
  -b:a 128k \
  output.mp4

パラメータの説明：

• -c:v hevc_nvenc：NVIDIA HEVC エンコーダーを使用
• -preset p4：品質重視プリセット（p1-p7、数字が大きいほど高品質）
• -cq 28：品質設定（crf に相当）

ハードウェアエンコードは、ソフトウェアエンコードより高速ですが、品質がやや劣る場合があります。

AV1 エンコード例

AV1 でエンコードする際の基本的なコマンド例です。

基本的なエンコード（libaom-av1）

bashCopy codeffmpeg -i input.mp4 \
  -c:v libaom-av1 \
  -cpu-used 4 \
  -crf 30 \
  -b:v 0 \
  -c:a libopus \
  -b:a 128k \
  output.webm

パラメータの説明：

• -c:v libaom-av1：libaom-av1 エンコーダーを使用
• -cpu-used 4：エンコード速度設定（0-8、数字が大きいほど高速）
• -crf 30：品質設定（H.265 の crf 28 と同程度）
• -b:v 0：可変ビットレート（VBR）を使用
• -c:a libopus：音声を Opus でエンコード（WebM 推奨）

libaom-av1 は非常に高品質ですが、エンコード時間が長いです。

高速エンコード（SVT-AV1）

SVT-AV1 は、Intel と Netflix が開発した高速な AV1 エンコーダーです。

bashCopy codeffmpeg -i input.mp4 \
  -c:v libsvtav1 \
  -preset 6 \
  -crf 30 \
  -c:a libopus \
  -b:a 128k \
  output.webm

パラメータの説明：

• -c:v libsvtav1：SVT-AV1 エンコーダーを使用
• -preset 6：エンコード速度設定（0-13、数字が大きいほど高速）

SVT-AV1 は、libaom-av1 より高速で、品質も十分に高いです。

2 パスエンコード

AV1 でも 2 パスエンコードが可能です。

bashCopy code# 1 パス目
ffmpeg -i input.mp4 \
  -c:v libsvtav1 \
  -preset 6 \
  -b:v 2M \
  -pass 1 \
  -an \
  -f webm /dev/null

bashCopy code# 2 パス目
ffmpeg -i input.mp4 \
  -c:v libsvtav1 \
  -preset 6 \
  -b:v 2M \
  -pass 2 \
  -c:a libopus \
  -b:a 128k \
  output.webm

2 パスエンコードは、ビットレート制約がある場合に有効でしょう。

VP9 エンコード例

VP9 でエンコードする際の基本的なコマンド例です。

基本的なエンコード

bashCopy codeffmpeg -i input.mp4 \
  -c:v libvpx-vp9 \
  -crf 30 \
  -b:v 0 \
  -c:a libopus \
  -b:a 128k \
  output.webm

パラメータの説明：

• -c:v libvpx-vp9：VP9 エンコーダーを使用
• -crf 30：品質設定（15-35 が推奨）
• -b:v 0：可変ビットレート（VBR）を使用

高品質エンコード（2 パス）

VP9 では、2 パスエンコードが推奨されます。

bashCopy code# 1 パス目
ffmpeg -i input.mp4 \
  -c:v libvpx-vp9 \
  -b:v 2M \
  -pass 1 \
  -an \
  -f webm /dev/null

bashCopy code# 2 パス目
ffmpeg -i input.mp4 \
  -c:v libvpx-vp9 \
  -b:v 2M \
  -pass 2 \
  -c:a libopus \
  -b:a 128k \
  output.webm

YouTube 向けエンコード

YouTube 推奨の VP9 エンコード設定です。

bashCopy codeffmpeg -i input.mp4 \
  -c:v libvpx-vp9 \
  -b:v 0 \
  -crf 23 \
  -row-mt 1 \
  -tile-columns 2 \
  -threads 4 \
  -c:a libopus \
  -b:a 192k \
  output.webm

パラメータの説明：

• -row-mt 1：行ベースのマルチスレッドを有効化
• -tile-columns 2：タイル分割を有効化（並列処理）
• -threads 4：スレッド数を指定

これらの設定により、エンコード速度が大幅に向上します。

ProRes エンコード例

ProRes でエンコードする際の基本的なコマンド例です。

ProRes 422 HQ（高品質編集用）

bashCopy codeffmpeg -i input.mp4 \
  -c:v prores_ks \
  -profile:v 3 \
  -pix_fmt yuv422p10le \
  -c:a pcm_s16le \
  output.mov

パラメータの説明：

• -c:v prores_ks：ProRes エンコーダーを使用
• -profile:v 3：ProRes 422 HQ を指定
• -pix_fmt yuv422p10le：4:2:2 色空間、10 ビット
• -c:a pcm_s16le：音声を無圧縮 PCM でエンコード

プロファイルの指定

ProRes のプロファイルは、-profile:v で指定します。

#	profile	プロファイル	用途
1	0	ProRes 422 Proxy	プレビュー・オフライン編集
2	1	ProRes 422 LT	一般的な編集
3	2	ProRes 422	放送品質編集
4	3	ProRes 422 HQ	高品質編集・グレーディング
5	4	ProRes 4444	アルファチャンネル・広色域
6	5	ProRes 4444 XQ	最高品質

ProRes 4444（アルファチャンネル対応）

bashCopy codeffmpeg -i input.mov \
  -c:v prores_ks \
  -profile:v 4 \
  -pix_fmt yuva444p10le \
  -c:a pcm_s16le \
  output.mov

パラメータの説明：

• -profile:v 4：ProRes 4444 を指定
• -pix_fmt yuva444p10le：4:4:4:4 色空間（アルファ付き）、10 ビット

ProRes 4444 は、透過情報を含む動画や、カラーグレーディングで広色域を扱う場合に使用します。

DNxHR エンコード例

DNxHR でエンコードする際の基本的なコマンド例です。

DNxHR HQ（高品質編集用）

bashCopy codeffmpeg -i input.mp4 \
  -c:v dnxhd \
  -profile:v dnxhr_hq \
  -pix_fmt yuv422p \
  -c:a pcm_s16le \
  output.mov

パラメータの説明：

• -c:v dnxhd：DNxHD/DNxHR エンコーダーを使用
• -profile:v dnxhr_hq：DNxHR HQ を指定
• -pix_fmt yuv422p：4:2:2 色空間

プロファイルの指定

DNxHR のプロファイルは、-profile:v で指定します。

#	profile	プロファイル	用途
1	dnxhr_lb	DNxHR LB	プレビュー・オフライン編集
2	dnxhr_sq	DNxHR SQ	一般的な編集
3	dnxhr_hq	DNxHR HQ	高品質編集
4	dnxhr_hqx	DNxHR HQX	カラーグレーディング
5	dnxhr_444	DNxHR 444	アルファチャンネル・最高品質

DNxHR 444（アルファチャンネル対応）

bashCopy codeffmpeg -i input.mov \
  -c:v dnxhd \
  -profile:v dnxhr_444 \
  -pix_fmt yuva444p \
  -c:a pcm_s16le \
  output.mov

パラメータの説明：

• -profile:v dnxhr_444：DNxHR 444 を指定
• -pix_fmt yuva444p：4:4:4:4 色空間（アルファ付き）

コーデック変換のワークフロー例

実際の作業では、複数のコーデックを組み合わせて使うことが多いです。以下の図は、典型的なワークフローを示しています。

mermaidCopy codeflowchart LR
  素材["カメラ素材<br/>（H.264）"]
  中間["編集用中間<br/>（ProRes/DNxHR）"]
  編集["動画編集<br/>カラグレ"]
  配信["配信用<br/>（H.264/H.265/AV1）"]
  アーカイブ["アーカイブ<br/>（ProRes/DNxHR）"]

  素材 -->|変換| 中間
  中間 --> 編集
  編集 --> 配信
  編集 --> アーカイブ

ワークフローの要点：

1. カメラ素材（H.264 など）を編集用中間ファイル（ProRes／DNxHR）に変換します
2. 編集用中間ファイルで編集・カラーグレーディングを行います
3. 編集完了後、配信用（H.264／H.265／AV1）とアーカイブ用（ProRes／DNxHR）を書き出します

このワークフローにより、編集時のパフォーマンスと配信時の効率を両立できるのです。

まとめ

本記事では、2025 年現在主流となっている 6 つの動画コーデック（H.264／H.265／AV1／VP9／ProRes／DNxHR）について、それぞれの特性、使いどころ、FFmpeg での具体的なエンコード方法を解説しました。

コーデック選択の基本的な考え方をまとめると、以下のようになります。

#	用途	推奨コーデック	理由
1	最大限の互換性が必要な配信	H.264	ほぼすべてのデバイスで再生可能
2	4K 以上の高解像度配信	H.265	高い圧縮効率と広い互換性
3	次世代の Web 配信	AV1	最高の圧縮効率、ロイヤリティフリー
4	YouTube 配信	VP9	YouTube が推奨、ロイヤリティフリー
5	Apple 環境での編集	ProRes	macOS/iOS でネイティブサポート
6	クロスプラットフォーム編集	DNxHR	Windows/macOS/Linux で対応

各コーデックには、それぞれの強みと弱みがあります。配信用では「互換性」「圧縮効率」「エンコード速度」のバランスを、編集用では「画質保持」「編集パフォーマンス」「ファイルサイズ」のバランスを考慮して選択することが重要でしょう。

また、実際のワークフローでは、編集用の中間ファイル（ProRes／DNxHR）と配信用ファイル（H.264／H.265／AV1）を使い分けることで、編集時の快適さと配信時の効率を両立できます。

今後、AV1 のハードウェアエンコーダー・デコーダーが普及すれば、AV1 が配信用コーデックの主流になっていくことが予想されますね。一方、編集用の ProRes や DNxHR は、当面の間引き続き使われ続けるでしょう。

本記事で紹介した FFmpeg コマンド例を参考に、ぜひ自分のプロジェクトに最適なコーデックを選択してみてください。

関連リンク

• FFmpeg 公式サイト
• H.264 (AVC) 規格
• H.265 (HEVC) 規格
• AV1 公式サイト
• VP9 公式サイト
• Apple ProRes
• Avid DNxHR
• FFmpeg Codecs Documentation