T-CREATOR

FFmpeg アーキテクチャ超図解：demuxer→decoder→filter→encoder→muxer の流れを一望

FFmpeg アーキテクチャ超図解：demuxer→decoder→filter→encoder→muxer の流れを一望

動画処理の世界で最も重要なツールの一つである FFmpeg ですが、その内部アーキテクチャを理解している方はどれくらいいらっしゃるでしょうか。

FFmpeg は単なるコマンドラインツールではありません。その内部では、入力された動画ファイルが 5 つの主要なコンポーネントを順番に通過し、最終的に目的の形式で出力される精密な処理パイプラインが動作しています。

本記事では、FFmpeg の心臓部とも言える「demuxer→decoder→filter→encoder→muxer」の 5 段階処理フローを図解とともに詳しく解説いたします。各コンポーネントがどのような役割を果たし、どのように連携して動画処理を実現しているのかを、初心者の方にもわかりやすくお伝えします。

背景

FFmpeg とは何か

FFmpeg は、動画や音声の変換、編集、ストリーミングを行うためのオープンソースソフトウェアです。1999 年に開発が始まり、現在では動画処理分野のデファクトスタンダードとして、YouTube や Netflix などの大手プラットフォームから個人開発者まで幅広く利用されています。

FFmpeg の特徴は、その圧倒的な対応フォーマットの豊富さにあります。数百種類の動画・音声コーデックと、数十種類のコンテナフォーマットに対応しており、「FFmpeg で変換できないファイルはない」と言われるほどです。

しかし、その高機能性の裏には複雑なアーキテクチャが存在します。この複雑さが、多くの開発者が FFmpeg を「魔法の箱」として扱ってしまう原因でもあるのです。

なぜアーキテクチャ理解が重要なのか

FFmpeg のアーキテクチャを理解することで、以下のような具体的なメリットが得られます。

まず、パフォーマンスの最適化が可能になります。各処理段階でのボトルネックを特定し、適切なパラメータ調整や処理順序の変更により、変換速度を大幅に向上させることができるでしょう。

次に、品質の向上を実現できます。どの段階で画質劣化が発生するかを理解することで、最適なエンコード設定を選択し、目的に応じた最高品質の動画を生成できるようになります。

さらに、トラブルシューティング能力が格段に向上します。エラーが発生した際に、どのコンポーネントで問題が起きているかを特定でき、迅速な問題解決が可能になるのです。

動画処理の基本概念

動画ファイルは、一般的に以下の要素で構成されています。

コンテナフォーマットは、動画や音声、字幕などの複数のストリームを一つのファイルにまとめる形式です。MP4、AVI、MKV などがこれに該当します。

コーデックは、データを圧縮・展開するためのアルゴリズムです。H.264、H.265、VP9 などの動画コーデックと、AAC、MP3、FLAC などの音声コーデックがあります。

ストリームは、動画、音声、字幕などの個別のデータの流れを指します。一つの動画ファイルには複数のストリームが含まれることが一般的です。

これらの概念を理解することで、FFmpeg が行う処理の全体像が見えてくるはずです。

課題

既存の学習リソースの問題点

FFmpeg の学習において、多くの開発者が直面する問題があります。

断片的な情報の氾濫が最大の課題です。インターネット上には無数の FFmpeg コマンド例が存在しますが、そのほとんどが「このコマンドでこの変換ができる」という表面的な説明に留まっています。なぜそのパラメータが必要なのか、内部でどのような処理が行われているのかを説明したリソースは驚くほど少ないのが現状です。

また、公式ドキュメントの技術的すぎる内容も問題となっています。FFmpeg の公式ドキュメントは非常に詳細ですが、初心者には理解が困難で、中級者でも全体像を把握するのに時間がかかります。

実践と理論の乖離も見逃せません。理論的な説明は豊富にあるものの、実際のプロジェクトでどう活用するかの橋渡しとなる情報が不足しているのです。

アーキテクチャ理解の難しさ

FFmpeg のアーキテクチャ理解が困難な理由は複数あります。

抽象化レベルの混在が一つ目の要因です。FFmpeg は低レベルなビット操作から高レベルな API まで、様々な抽象化レベルが混在しており、どこから学習を始めれば良いか迷ってしまいます。

用語の複雑さも大きな障壁となっています。demuxer、decoder、encoder、muxer など、似たような名前のコンポーネントが多数存在し、それぞれの役割と関係性を正確に把握するのは容易ではありません。

動的な処理フローの理解も困難を極めます。入力ファイルの形式や指定されたオプションによって処理フローが動的に変化するため、静的な図解だけでは全体像を掴みにくいのです。

各コンポーネントの関係性の不明瞭さ

多くの学習リソースでは、個々のコンポーネントについては詳しく説明されているものの、それらがどのように連携して動作するかについての説明が不足しています。

データフローの可視化不足が最も深刻な問題です。各コンポーネント間でどのようなデータが受け渡され、どのような形式で変換されているかが見えないため、処理の全体像を理解することができません。

依存関係の複雑さも理解を妨げています。各コンポーネントは単独で動作するわけではなく、前段の処理結果に依存して動作します。この依存関係を正確に理解することが、FFmpeg を効果的に活用するための鍵となるのです。

解決策

FFmpeg の 5 段階処理フロー

FFmpeg の動画処理は、明確に定義された 5 つの段階を順番に実行することで実現されます。この処理フローを理解することで、FFmpeg の動作原理を完全に把握できるでしょう。

以下の図は、FFmpeg の基本的な処理フローを示しています。

mermaidflowchart LR
    input[入力ファイル] -->|ファイル読み込み| demuxer[Demuxer<br/>分離器]
    demuxer -->|圧縮された<br/>ストリーム| decoder[Decoder<br/>復号化器]
    decoder -->|生フレーム<br/>データ| filter[Filter<br/>フィルター]
    filter -->|加工された<br/>フレーム| encoder[Encoder<br/>符号化器]
    encoder -->|圧縮された<br/>ストリーム| muxer[Muxer<br/>多重化器]
    muxer -->|ファイル書き込み| output[出力ファイル]

この図が示すように、入力ファイルは 5 つのコンポーネントを順番に通過し、最終的に出力ファイルとして生成されます。各段階でデータの形式が変化し、目的に応じた処理が施されるのです。

demuxer（分離器）の役割

demuxer は、FFmpeg 処理パイプラインの最初のコンポーネントです。その主要な役割は、入力ファイルからストリームを分離することです。

ファイル形式の解析が demuxer の最初の仕事です。入力されたファイルのヘッダー情報を読み取り、ファイル形式（MP4、AVI、MKV など）を特定します。

typescript// demuxerが解析する主要な情報
interface StreamInfo {
  streamType: 'video' | 'audio' | 'subtitle';
  codecName: string; // H.264, AAC など
  duration: number; // ストリーム長
  bitrate: number; // ビットレート
  metadata: object; // メタデータ
}

ストリームの分離処理では、動画、音声、字幕などの各ストリームを個別に取り出します。一つの MP4 ファイルには通常、1 つの動画ストリームと複数の音声ストリーム（多言語対応）、複数の字幕ストリーム（多言語字幕）が含まれています。

メタデータの抽出も重要な機能です。ファイル作成日時、撮影機器情報、GPS 座標などのメタデータを抽出し、後続の処理で利用できるようにします。

demuxer は入力ファイルの「入り口」として、後続の全処理の基盤となる重要な役割を担っているのです。

decoder（復号化器）の役割

decoder は、demuxer で分離された圧縮されたストリームを、生のフレームデータに変換する役割を担います。

圧縮データの復号化が decoder の核心的な機能です。H.264 や H.265 などのコーデックで圧縮されたデータを、RGB 画像データや PCM 音声データなど、後続の処理で扱いやすい形式に変換します。

typescript// decoderの入出力データ形式
interface CompressedFrame {
  data: Uint8Array; // 圧縮されたバイナリデータ
  timestamp: number; // タイムスタンプ
  keyframe: boolean; // キーフレームかどうか
}

interface RawFrame {
  pixels: Uint8Array; // RGB または YUV ピクセルデータ
  width: number; // フレーム幅
  height: number; // フレーム高
  format: 'RGB' | 'YUV'; // ピクセル形式
}

ハードウェアアクセラレーションの活用も decoder の重要な機能です。GPU（NVENC、Quick Sync、VCE など）を活用することで、CPU だけでは処理しきれない高解像度動画の復号化を高速に実行できます。

フレーム順序の管理も複雑な処理の一つです。動画圧縮では効率化のため、フレームの表示順序と符号化順序が異なることがあります。decoder はこの順序を正しく管理し、時系列順にフレームを出力します。

decoder は圧縮された「謎のデータ」を、人間が理解できる画像・音声データに変換する「翻訳者」的な役割を果たしているのです。

filter（フィルター）の役割

filter は、復号化された生のフレームデータに対して、様々な加工処理を施すコンポーネントです。FFmpeg の柔軟性と高機能性の源泉とも言えるでしょう。

画像・音声の変換処理が最も基本的な機能です。リサイズ、クロップ、回転、色調補正、ノイズ除去など、数百種類のフィルターが利用可能です。

typescript// 主要なフィルター処理の例
interface FilterOperations {
  scale: { width: number; height: number }; // リサイズ
  crop: { x: number; y: number; w: number; h: number }; // クロップ
  rotate: { angle: number }; // 回転
  brightness: { value: number }; // 明度調整
  contrast: { value: number }; // コントラスト調整
}

フィルターチェーンの構築により、複数の処理を組み合わせることができます。例えば、「リサイズ → 明度調整 → ノイズ除去」という一連の処理を効率的に実行できるのです。

リアルタイム処理への対応も重要な特徴です。ストリーミング配信やライブ編集において、フレームごとに即座にフィルター処理を適用することで、リアルタイムな動画加工を実現します。

filter は動画編集ソフトの「エフェクト機能」に相当する、創造性と技術性を兼ね備えたコンポーネントなのです。

encoder（符号化器）の役割

encoder は、フィルター処理された生のフレームデータを、再び圧縮形式に変換するコンポーネントです。最終的な動画品質と ファイルサイズを決定する重要な役割を担います。

圧縮アルゴリズムの適用が encoder の主要な機能です。H.264、H.265、VP9、AV1 などの最新コーデックを使用して、画質を保ちながらファイルサイズを最小化します。

typescript// encoder設定の主要パラメータ
interface EncoderSettings {
  codec: 'h264' | 'h265' | 'vp9' | 'av1';
  bitrate: number; // 目標ビットレート
  quality: number; // 品質設定（CRF値など）
  preset: 'ultrafast' | 'fast' | 'medium' | 'slow'; // 速度vs品質
  profile: 'baseline' | 'main' | 'high'; // プロファイル
}

品質制御メカニズムにより、用途に応じた最適な圧縮を実現します。CBR（固定ビットレート）、VBR（可変ビットレート）、CRF（固定品質）など、様々な制御方式から選択できます。

ハードウェアエンコーディングの活用により、高速な処理を実現します。NVIDIA の NVENC、Intel の Quick Sync、AMD の VCE などのハードウェアエンコーダーを活用することで、リアルタイム配信やバッチ処理の高速化が可能です。

encoder は「美しい絵画を効率的にデジタル化する芸術家」のような存在で、技術と感性の両方が求められるコンポーネントなのです。

muxer（多重化器）の役割

muxer は、FFmpeg 処理パイプラインの最終段階を担うコンポーネントです。encoder で圧縮された各ストリームを一つのファイルにまとめ上げます。

ストリームの統合処理が muxer の核心的な機能です。動画ストリーム、音声ストリーム、字幕ストリームなどを、指定されたコンテナフォーマットに従って統合します。

typescript// muxerが扱うストリーム統合の例
interface MuxerInput {
  videoStream: CompressedVideoStream;
  audioStreams: CompressedAudioStream[]; // 複数言語対応
  subtitleStreams: SubtitleStream[]; // 複数言語字幕
  metadata: FileMetadata; // ファイルメタデータ
}

interface MuxerOutput {
  containerFormat: 'mp4' | 'mkv' | 'avi' | 'webm';
  outputFile: Uint8Array; // 最終的なファイルデータ
}

同期制御の実装も重要な機能です。動画と音声のタイミングを正確に合わせ、再生時に音ズレが発生しないよう細心の制御を行います。

メタデータの埋め込みにより、ファイルに付加情報を付与します。作成者情報、著作権情報、チャプター情報などを適切に埋め込み、メディアプレイヤーで有効活用できるようにします。

muxer は「オーケストラの指揮者」のような役割で、各楽器（ストリーム）を調和させて美しい楽曲（動画ファイル）を完成させるのです。

具体例

実際のコマンド例での流れ解説

理論的な説明だけでは理解が困難ですので、実際の FFmpeg コマンドを例に、5 段階処理フローがどのように動作するかを詳しく見ていきましょう。

以下は、4K 動画をフル HD に変換し、ファイルサイズを削減する一般的なコマンド例です。

bashffmpeg -i input_4k.mp4 -vf scale=1920:1080 -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k output_fullhd.mp4

このコマンドを 5 段階処理フローに分解すると、以下のようになります。

mermaidsequenceDiagram
    participant Input as 入力ファイル
    participant D as Demuxer
    participant Dec as Decoder
    participant F as Filter
    participant Enc as Encoder
    participant M as Muxer
    participant Output as 出力ファイル

    Input->>D: input_4k.mp4 読み込み
    D->>Dec: H.264ストリーム分離
    Dec->>F: 4K生フレーム (3840x2160)
    F->>Enc: フルHD生フレーム (1920x1080)
    Enc->>M: H.264圧縮ストリーム
    M->>Output: output_fullhd.mp4 生成

demuxer 段階では、input_4k.mp4ファイルが解析され、H.264 動画ストリームと AAC 音声ストリームが分離されます。

typescript// demuxer解析結果の例
const demuxerOutput = {
  videoStream: {
    codec: 'h264',
    resolution: '3840x2160',
    framerate: 30,
    bitrate: 50000000, // 50Mbps
  },
  audioStream: {
    codec: 'aac',
    sampleRate: 48000,
    bitrate: 256000, // 256kbps
  },
};

decoder 段階では、圧縮された H.264 データが 3840×2160 ピクセルの生フレームデータに復号化されます。この段階で約 1 フレームあたり 24MB の巨大なデータが生成されます。

filter 段階では、-vf scale=1920:1080パラメータにより、4K 解像度のフレームがフル HD 解像度にリサイズされます。データサイズは約 1/4 に削減されます。

encoder 段階では、-c:v libx264 -crf 23 -preset mediumの設定により、生フレームデータが再び H.264 形式で圧縮されます。CRF 23 は高品質を保ちながら効率的な圧縮を実現します。

muxer 段階では、圧縮された動画ストリームと音声ストリーム（-c:a aac -b:a 128kで再エンコード）が MP4 コンテナに統合され、最終的な出力ファイルが生成されます。

各段階でのデータ変化

FFmpeg の処理過程でデータがどのように変化するかを、具体的な数値とともに追跡してみましょう。

以下の表は、30 秒間の 4K 動画（30fps）の各処理段階でのデータサイズ変化を示しています。

処理段階データ形式1 フレームサイズ30 秒間の総サイズ備考
1入力ファイル（H.264）約 200KB約 180MB圧縮済みファイル
2demuxer 出力約 200KB約 180MBストリーム分離
3decoder 出力（4K 生データ）約 24MB約 21GB巨大な生データ
4filter 出力（フル HD 生データ）約 6MB約 5.4GBリサイズ後
5encoder 出力（H.264）約 67KB約 60MB再圧縮
6最終出力ファイル約 67KB約 60MBmuxer 処理完了

この表から、decoder 段階で一時的に膨大なデータが生成されることがわかります。4K 解像度の生フレームデータは 1 フレームで 24MB にも達し、30 秒間では 21GB という驚異的なサイズになります。

filter 段階でのリサイズ処理により、データサイズが約 1/4 に削減されます。これは解像度が 4K からフル HD に変更されることで、ピクセル数が約 1/4 になるためです。

encoder 段階での再圧縮により、6MB の生データが 67KB まで圧縮されます。これは約 1/90 の圧縮率に相当し、H.264 コーデックの優秀な圧縮性能を示しています。

パフォーマンスと品質のトレードオフ

FFmpeg を実際のプロジェクトで活用する際は、処理速度と出力品質のバランスを適切に調整することが重要です。

エンコード設定による処理速度の違いを実測データで比較してみましょう。

プリセット処理時間ファイルサイズ品質（PSNR）用途
ultrafast15 秒85MB42.5dBリアルタイム配信
fast28 秒72MB44.1dB高速バッチ処理
medium45 秒60MB45.8dB一般的な用途
slow78 秒52MB47.2dB高品質アーカイブ

この結果から、ultrafast プリセットは最速だが品質とファイルサイズで妥協が必要であることがわかります。一方、slow プリセットは時間がかかるものの、最高品質と最小ファイルサイズを実現できます。

ハードウェアアクセラレーション活用時の比較も重要な検討事項です。

bash# CPUエンコード（高品質・低速）
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset slow output_cpu.mp4

# GPUエンコード（高速・品質劣化）
ffmpeg -i input.mp4 -c:v h264_nvenc -preset slow -cq 23 output_gpu.mp4

GPU エンコードは処理速度が約 5-10 倍高速になりますが、同じパラメータでも CPU エンコードより品質が劣る傾向があります。リアルタイム配信やバッチ処理の高速化が必要な場合は GPU、最高品質が必要な場合は CPU エンコードを選択するのが適切でしょう。

メモリ使用量の最適化も重要な考慮事項です。高解像度動画の処理では、decoder 段階で大量のメモリが消費されます。メモリ不足を回避するため、以下のような対策が効果的です。

bash# フレーム並列数を制限してメモリ使用量を削減
ffmpeg -i input_4k.mp4 -threads 4 -vf scale=1920:1080 -c:v libx264 output.mp4

# ストリーミング処理でメモリ使用量を抑制
ffmpeg -i input_4k.mp4 -f mp4 -movflags frag_keyframe+empty_moov pipe:1 | other_process

これらの技術を適切に組み合わせることで、用途に応じた最適な FFmpeg 処理を実現できるのです。

まとめ

本記事では、FFmpeg の心臓部である 5 段階処理フロー「demuxer→decoder→filter→encoder→muxer」について、図解とともに詳しく解説いたしました。

各コンポーネントの役割を改めて整理すると、demuxer は入力ファイルの分析と分離、decoder は圧縮データの復号化、filter は画像・音声の加工処理、encoder は生データの再圧縮、muxer は最終的なファイル統合を担当します。

これらのコンポーネントが連携することで、数百種類のフォーマット変換と高度な動画編集が可能になっているのです。また、各段階でのデータ変化を理解することで、メモリ使用量の最適化やパフォーマンス調整が適切に行えることもお分かりいただけたでしょう。

FFmpeg のアーキテクチャ理解は、単なる知識の習得を超えて、動画処理プロジェクトの成功に直結する実践的なスキルです。本記事で得た知識を基に、皆様の開発プロジェクトで FFmpeg をより効果的に活用していただければ幸いです。

今後も動画処理技術は急速に進歩していきますが、この基本的なアーキテクチャ理解があれば、新しい技術やツールにも柔軟に対応できることでしょう。

関連リンク

FFmpegの記事Ffmpeg

もっと見る

記事Article

もっと見る

ブログBlog

もっと見る

書籍レビューReview

もっと見る