要約

  • RFC 9559 は EBML 文書、トラック記述、Block 構造を検証可能にする。その受領証は、コーデック能力、参照関係の閉包、同期提示より手前で終わる。
  • Cues は一部の時刻とトラックだけを索引化でき、ライブ配信では正当に省略できる。索引命中は、独立してデコードできる可視フレームへの到達を意味しない。
  • Default や Forced のフラグはプレーヤー方針への入力であり、特定の視聴者が実際に受け取った音声、字幕、アクセシビリティ経路の記録ではない。

Matroska リーダーがファイルを開き、EBML ヘッダーを受理し、合法な要素ツリーを最後までたどる。そこで「再生できる」という短い言葉が入り込む。RFC 9559 が標準化したのはコンテナである。トラックを識別し、符号化フレームを格納し、時刻を配置し、索引を渡す仕組みだ。いずれも有用な証拠だが、画面やスピーカーの結果そのものではない。

2024 年 10 月に IETF Standards Track として公開された仕様は、既に動いていた実装にも追いついた。RFC 8794 は 1 オクテットの Element ID 0x80 を予約していたが、Matroska 実装はそれを ChapterDisplay に使っていた。RFC 9559 はこの値を合法化した。文書が running code に整合したのであって、過去の全ファイルや全リーダーの挙動が同一だったと証明したわけではない。

読めることは、限定された互換判断である

EBML ヘッダーは DocTypeVersion と DocTypeReadVersion を分ける。前者は使用した最も新しい Matroska 要素を覆わなければならない。後者は、機能を一部減らした再生も含め、リーダーに最低限必要な版を示す。仕様の例では、version 4 の CueRelativePosition を使っても read version を 2 にできる。この要素はシーク精度を上げるが、通常再生には必須ではないからだ。

これは堅実な相互運用であって、全機能の認定ではない。対応リーダーは親要素のサイズ制約に収まる未知要素を飛ばす必要がある。「正常に開いた」は、別の実装が使う情報を意図的に無視した、という意味にもなる。構造受理を超える主張には、リーダーの版、宣言された版、スキップした要素の一覧が要る。

Block からフレームへ、さらに参照履歴へ

Block と SimpleBlock はトラック番号、Cluster に対する符号付き時刻、フラグ、任意の lacing、1 個以上の符号化フレームをまとめる。Xiph、EBML、固定長 lacing はオーバーヘッドを減らすが、内部のフレーム境界を正確に復元する責任を増やす。要素の終端を読めたことは、全フレームの切れ目を読めたことではない。

参照状態にも境界がある。依存フレームをランダムアクセスポイントと誤認すると、誤った出力やクラッシュを招き得ると RFC は警告する。AV1 や VP9 の intra-only フレームには、単独でデコードできてもコーデック状態をリセットしないものがある。以後の画像は、シークで捨てた過去に依存し続ける。「ここにフレームがあるか」より、「ここから先に必要な参照がすべて閉じているか」を問うべきである。

CodecID と必要に応じた CodecPrivate は、符号化データの識別と初期化条件を伝える。共通 mapping は名前をそろえるが、デコーダーを導入せず、対応 profile や資源、正しい出力を保証しない。そこはコンテナ解析とは別の能力受領証である。

時刻を読んでも、視聴者の時間軸にはならない

Matroska には Segment tick と Track tick がある。Block の提示時刻は Cluster 時刻、符号付き Block 時刻、TrackTimestampScale、TimestampScale、場合によって CodecDelay を組み合わせて得る。負の時刻を持つフレームはデコードが必要でも表示してはならず、浮動小数の結果は最も近いナノ秒へ丸める。

仕様は歴史的な実装差も隠さない。多くのリーダーが既定値以外の TrackTimestampScale を考慮しないため、1.0 以外は多くの環境で動かない可能性がある。同じ有効な構文から、異なる実装が異なる運用時間軸を作り得る。Track operation の重複フレームも、基盤が落とすか重ねて描くかを選び、プラットフォーム間の最終結果は確定できない。

したがって受領証には計算入力を残し、生成時刻、音画同期、出力 fingerprint を比較しなければならない。解析済みの整数は、提示済みの瞬間ではない。

Cues は道を示すが、シークを完了しない

Cues は絶対時刻へ速く移動するため、選ばれた Cluster 位置を索引化する。全 Block 時刻を載せても、一部だけでもよい。通常ファイルでは Cues を置き、映像の各 keyframe に CuePoint を置くことが推奨される一方、映像があれば音声 cue は省ける。索引なしでもファイルを探索できる。

検証順序は明確だ。要求したトラックと時刻が索引対象か。Cue は正しい Cluster と相対位置へ届くか。着地点で参照が閉じるか。そこからデコードした表示フレームは許容誤差内か。Cue 命中が閉じるのは、位置探索の段だけである。

ライブ配信では設計が変わる。連続する live Segment は SeekHead、Cues、Chapters、Attachments を使ってはならない。先頭に二つの索引がなければ非 seekable と扱うべきである。ライブとして正当な欠落でも、巻き戻しやスクラブを約束した製品には決定的な制約となる。

コンテナは視聴者に代わって選ばない

FlagDefault は、ある言語のトラックを自動選択候補にするだけで、プレーヤーはアクセシビリティ設定などを理由に上書きできる。FlagForced は、現在の音声では通常字幕を出さない場合でも特定字幕を表示するよう促す。他にも聴覚、視覚、解説、原語、コメンタリーのフラグがある。

これらは方針への入力であり、結果ではない。ユーザー設定、競合時の優先順位、実際に出力へ到達した Track UID は別に観測する必要がある。信頼できる再生受領証は、コンテナのフラグ、プレーヤー設定、実選択、可聴または可視の canary を結ぶ。

Heng Lu の running-code と reality-layer の考え方を当てはめると、RFC は調整物であり、結果は実行鎖にある。正確なバイト、パーサー判断、フレーム境界、参照状態、時刻計算、索引経路、選択方針、デコーダー、レンダラー、出力を分けて記録するほど、規格が与える共通性を過大評価せず活用できる。