MediaPlayerを作ろうMW編．４：圧縮データを元に戻す！Decoderの魔法

はじめに：Decoderはパイプラインの「復元士」

こんにちは！前回は、Demuxer（デマルチプレクサ）がコンテナという大きな箱から、映像と音声のデータをきれいに仕分け、さらに再生に必要なタイムスタンプ（PTS/DTS）を付けてくれるところまでを見ました。Demuxerは、まさに縁の下の力持ちでしたね。

今回は、そのDemuxerから送られてきた「圧縮されたデータ」を受け取り、私たちが目で見たり耳で聞いたりできる「元のデータ」に復元する、Decoder（デコーダ）の仕事に迫ります。

Decoderは、例えるなら「復元士」や「翻訳家」です。

Decoderの役割を理解するために、まず「なぜ圧縮が必要なのか」を簡単に振り返りましょう。

もし、動画や音声を一切圧縮せずに保存しようとすると、データ量は膨大になりすぎます。例えば、フルHD（1920×1080）の映像を非圧縮で保存すると、たった1秒で数百MBにもなってしまいます。これでは、インターネットで配信したり、スマートフォンに保存したりするのは現実的ではありません。

そこで、Codec（コーデック）という技術を使って、データから「人間が気づきにくい情報」を賢く削り、データ量を大幅に減らします。この「賢く削る」作業がEncode（エンコード：符号化）です。

Demuxerから送られてくるデータは、このエンコードされた、いわば「暗号化されたメッセージ」のようなものです。

Decoderの仕事は、この「暗号化されたメッセージ」を解読し、元のデータに戻すことです。

これがDecoderの最も主要な仕事です。

Demuxerから送られてきた映像や音声のパケット（Packet）やフレーム（Frame）を受け取り、対応するCodecのアルゴリズムを使って、元の非圧縮データに戻します。

この復元されたデータは、次に控えるRenderer（描画・再生担当）が直接扱える「生データ」となります。

Demuxerは、コンテナのメタデータから「この映像はH.264で圧縮されている」「この音声はAACで圧縮されている」という情報を抽出していました。

Decoderは、この情報を受け取り、適切なCodecを選択し、初期化します。もし、対応していないCodecだった場合、Decoderは「このデータは扱えません！」とPlayerに報告することになります。

前回のDemuxerの記事で、DTS (Decode Time Stamp)とPTS (Presentation Time Stamp)について触れました。Decoderは、このDTSを非常に重要な情報として利用します。

特にH.264などの映像圧縮では、データ量を減らすために、「前のフレームとの差分」だけを記録する手法が使われます。このため、表示順（PTS）と復号化順（DTS）が異なることがあります。

Decoderは、DTSを頼りに、パケットを正しい順番で復号化し、その結果をPTSの順番でRendererに渡すための準備をします。Decoderは、一時的に複数のフレームを保持し、DTSの順番で処理し、PTSの順番で出力する、という「並び替え」の役割も担っているのです。

Decoderによって圧縮から解放された映像フレームや音声サンプルは、次の担当者であるRenderer（レンダラ）へと送られます。

Rendererは、この「生データ」を受け取り、映像であれば画面に描画し、音声であればスピーカーから音を出す、という最終的な役割を担います。

Decoderは、Demuxerが仕分けた「暗号化されたメッセージ」を、Codecという鍵を使って解読し、元の美しい映像とクリアな音声に戻すデータ復元のスペシャリストです。

パイプラインの次のステップであるRendererは、このDecoderが作り出した「生データ」をどう扱うのでしょうか？

次回は、いよいよ最終段階、Rendererの仕事に迫ります。お楽しみに！