【ITニュース解説】A moov box at byte 28 did not make this MP4 a faststart file

MP4ファイルは、私たちの日常生活で最もよく目にする動画形式の一つだ。このニュース記事は、MP4ファイルの内部構造が、動画の再生開始速度にどのように影響するかという、一見すると専門的だが、システムエンジニアを目指す上で非常に役立つテーマを扱っている。具体的には、MP4ファイルの重要な部分である「moovボックス」がファイルの冒頭に配置されていても、必ずしも動画がすぐに再生される「faststart」の状態になるとは限らない、という意外な発見について解説している。

まず、MP4ファイルの基本的な構造から理解しよう。MP4ファイルは、単一の大きなデータではなく、「ボックス」と呼ばれる小さな情報の塊が積み重なってできている。これらのボックスそれぞれが、動画の特定の情報やデータを含んでいるのだ。例えば、ファイルの冒頭には「ftypボックス」があり、これはファイルの種類やバージョンを示す。そして、動画の再生に必要なあらゆる情報、例えば動画全体の長さ、使われている映像や音声の形式、それぞれの映像フレームや音声サンプルがどこに位置するかといった目次のようなデータは、「moovボックス」という別のボックスにまとめられている。

動画プレイヤーは、動画を再生するために、このmoovボックスに含まれる情報を最初に読み込む必要がある。もしmoovボックスがファイルの最後の方に配置されていると、プレイヤーはファイル全体をダウンロードし終えるまでmoovボックスを読み込むことができない。その結果、動画の再生開始が遅れてしまうのだ。この問題を解決するために、「faststart」という技術が考案された。これは、moovボックスをファイルデータの先頭近くに配置することで、プレイヤーが動画ファイル全体をダウンロードする前に、必要な情報を読み込み、素早く再生を開始できるようにする仕組みだ。これにより、特にインターネット経由でのストリーミング再生において、ユーザー体験が向上する。

今回の記事の著者は、WebM形式の動画ファイルをImgIngというツールを使ってMP4形式に変換した。変換後のファイルを確認すると、ftypボックスが最初の28バイトを占め、その直後のバイト28からmoovボックスが始まっていた。この配置は、まさにfaststartの条件を満たしているように見えたため、著者はプレイヤーが動画全体をダウンロードし終えることなく、すぐに再生を開始できるだろうと期待した。

しかし、ここからが記事の核心部分だ。moovボックスがファイルの冒頭にあったにもかかわらず、その後に続くボックスの並びが、一般的なfaststartとは異なる構造を示していたのだ。具体的には、「moofボックス」（Movie Fragment Box）と「mdatボックス」（Media Data Box）というペアが繰り返し現れ、最後に「mfraボックス」（Movie Fragment Random Access Box）が続いていた。これは、いわゆる「フラグメント化されたMP4」（Fragmented MP4、略してfMP4）と呼ばれる特殊な構造を持つファイルである。

従来のfaststartMP4では、冒頭にあるmoovボックスが動画全体の完全な目次情報を持っている。これに対し、フラグメント化されたMP4は、動画データを小さな断片（フラグメント）に分割し、それぞれの断片ごとに「moofボックス」でその断片のメタデータ（どこからどこまでの映像や音声データか、など）を提供し、「mdatボックス」で実際の映像・音声データを含んでいる。そして、「mfraボックス」は、これらの断片に効率的にアクセスするためのインデックスを提供している。

この構造上の違いが重要だ。フラグメント化されたMP4の場合、たとえmoovボックスがファイルの冒頭にあっても、そのmoovボックスは動画全体の完全なインデックス情報を含んでいるわけではない。プレイヤーは、動画を再生していく中で、次のフラグメントを再生するために、そのフラグメントに対応するmoofボックスとmdatボックスを読み込む必要があるのだ。そのため、従来のfaststartのように、冒頭のmoovボックスを読み込んだだけで即座に再生が始まるわけではない。プレイヤーは、後続のmoof/mdatのペアを順次フェッチ（取得）していく必要がある。

著者はこの挙動を検証するため、変換されたMP4ファイルを、意図的にネットワーク帯域を制限し、初期遅延を設けたローカルのHTTPサーバー経由で提供し、主要なWebブラウザ（Chromium、Firefox、WebKitベースのテストビルド）で再生テストを行った。このテスト環境では、ネットワークからのデータ取得に時間がかかるようになっている。特にChromiumブラウザでの結果が注目に値する。ブラウザが「Rangeヘッダー」を有効にしてデータリクエストを行った場合、最初のフレームが表示されるまでに約7.9秒かかったという。Rangeヘッダーは、ファイル全体ではなく、指定した範囲のデータのみを要求するHTTPの機能で、ストリーミング再生やシーク（早送り・巻き戻し）において重要な役割を果たす。この結果は、moovボックスが早期にあったとしても、プレイヤーが後続のフラグメントデータを読み込むために追加のネットワークリクエストを必要としたため、再生開始までに時間がかかったことを示している。

もしRangeヘッダーを無効にした場合、最初のフレーム表示は約1.4秒と、より速くなった。これは一見するとRangeヘッダーが悪いように思えるかもしれないが、そうではない。Rangeヘッダーを無効にすると、ブラウザはファイル全体を一気にダウンロードしようとする傾向があるため、結果的に部分的なデータ取得のメリットを享受できず、むしろファイル全体がダウンロードされてから再生が始まることで、より早く「再生可能」になったという見方もできる。重要なのは、Rangeヘッダーは動画のシーク機能など、再生中に必要なデータを効率的に取得するために不可欠な機能であり、今回の結果だけでその重要性を否定すべきではない、ということだ。

このニュース記事がシステムエンジニアを目指す皆さんに伝える重要な教訓は、MP4ファイルの内部構造は見た目よりも複雑であり、単にmoovボックスがファイルの早い位置にあるというだけで、そのファイルが「faststart」として機能すると断定するのは危険だ、ということだ。ファイルが「フラグメント化されたMP4」のような特殊な構造を持っていた場合、期待する再生特性が得られない可能性がある。したがって、動画ファイルの再生パフォーマンスを評価する際には、moovボックスの位置だけでなく、その後に続くボックスのシーケンス、つまりファイル全体の構造を詳細に検査することが極めて重要となる。また、実際のネットワーク環境やプレイヤーの挙動をシミュレーションしたテストを通じて、具体的なパフォーマンスを確認する実践的なアプローチの重要性も示唆されている。技術的な仕様だけでなく、それが実際のシステムでどのように振る舞うかを深く理解することが、優れたシステムエンジニアになるための鍵となるだろう。