要約

  • draft-ietf-mlcodec-opus-extension-06 は Opus のパディングを拡張領域として使い、旧来のデコーダーが拡張を捨てても基本層を復号できるようにする。
  • RTE による反復、フレーム区切り、長さ、順序を正しく再構成しなければ、識別子を認識しても拡張効果は成立しない。
  • 基本復号、拡張解析、能力交渉、ローカル受理、フレーム別適用、観測出力を一つの成功値にまとめてはならない。

圧縮された順序

複数の Opus フレームを一つのパケットに入れ、同じ種類の拡張を各フレームに付けたいとする。すべての識別子と区切りを毎回書けば分かりやすいが、オーバーヘッドが増える。そこで構造 ID 2 の Repeat These Extensions、RTE が、直前の拡張列を後続フレームに反復し、新しいペイロードだけを運ぶ。

受信側が識別子を発見したことと、正しいフレーム列を復元したことは同じではない。一つのフレームに属する拡張集合がパケット内で連続しない場合があり、短い拡張と長い拡張では反復時の長さ規則も異なる。順序はフレーム内で意味を持ち、各拡張仕様は出現回数や位置をさらに制約できる。

基本音声はその混乱を待たずに成立し得る。だから再生成功は、RTE 展開成功の代用にならない。

パディングが互換性の境界になる

RFC 6716 では、エンコーダーはパディングをゼロにし、デコーダーは任意の値を受け入れる。草案は非ゼロのパディングを拡張の合図に使う。旧来のデコーダーは中身を捨て、基本 Opus データを処理する。拡張対応デコーダーも、拡張がない場合は非対応デコーダーと同じ動作をしなければならない。

さらに、エンコーダーは拡張のために非拡張部分を変え、旧デコーダーで目立つ品質低下を起こしてはならない。これは互換性の下限を守る規則である。オプションの上限を保証する規則ではない。

拡張インスタンスは七ビット ID と L フラグから始まり、必要に応じて長さとデータが続く。短い ID はデータをゼロまたは一バイト持ち、長い ID は任意長を持てる。長い拡張の L=0 は通常、残りのパディング全部を使う。L=1 は明示長を置き、255 による継続もパケット境界内に限られる。

宣言長が境界を越える、長さ自体を最後まで読めない、RTE の反復ペイロードが足りない。そのいずれでも不正な部分は無視される。基本層は継続できる。堅牢なフォールバックが、拡張の欠落を見えにくくする。

フレーム区切りは所属証明である

構造 ID 1 はフレーム区切りである。ある形式は一フレーム進み、別の形式は後続バイトの値だけ進む。結果のインデックスはパケット内フレーム数未満でなければならず、範囲外フレームに関連付けられたインスタンスはすべて無視される。

ID、長さ、データが個別に正しくても、所属先が存在しなければ適用できない。必要な証拠は「拡張を見た」ではなく、「どの展開規則で、どの順序に戻し、どのフレームへ付け、どの判断で適用したか」である。

RTE による規定の並べ替えは、個別に符号化した場合と等価に扱われる。しかしそれは任意の並べ替えを許すものではない。解析結果には展開前と展開後の両方を残す必要がある。

対応実装でも無視できる

未知の拡張は無視し、存在しないものとして基本層を復号しなければならない。草案はさらに、技術的に対応している拡張でもデコーダーが無視してよいとする。実装能力は適用義務ではない。

ビルドにコードがあっても無効化されているかもしれない。CPU やメモリの上限が処理を拒むかもしれない。アプリケーション方針や別の交渉条件が足りない場合もある。したがって「対応」は、実装あり、現在有効、セッションで許可、インスタンス受理、出力反映へ分解しなければならない。

悪意あるペイロードに対する堅牢性も同じである。拡張処理は割り当て済みメモリを越えたり、過大な資源を消費したりしてはならない。安全に基本層へ戻れたことは防御結果であり、拡張が正しいことの証明ではない。

SDP は能力の記述であって実行記録ではない

草案は audio/opus に、受信側 ID の extensions と送信側 ID の sprop-extensions を加える。固有パラメーターは extN-* と sprop-extN-* を使う。拡張機構を理解する受信側は構造 ID 0、1、2 を必ず扱うが、一覧に書く必要はない。

SDP パラメーターは明示し、別の offer や answer から機械的に持ち越してはならない。交渉が失敗しても、受信側は未知または未交渉の拡張を含むパケットの基本層を復号できなければならない。これは安全な無視を要求するのであって、拡張実行を要求するのではない。

セッション継続だけでは合意を立証できない。offer、answer、採用値、ビルド、設定、受信インスタンス、逐次判断を同じセッションに結び付ける必要がある。

番号の制度と実行の現実

草案は七ビットの Opus Extension IDs レジストリを提案する。0、1、2 は構造用、3 から 119 は Standards Action、120 から 126 は実験用、127 は将来の機構拡張用である。実験では実験番号と版番号の二バイト接頭辞、そして衝突回避が推奨される。

公開番号は調整点であり、実行結果ではない。実験同士が衝突し得る。同じ番号でも版が異なり得る。安定仕様でもローカル実装が古い場合がある。番号、定義、版、ビルド、設定、判断を別々に記録して初めて解釈できる。

隣接する Opus HD 草案は、追加解像度と 20 kHz 超の成分、96 kHz 処理を提案し、コードとビルドスイッチを示す。だが、それは特定端末での有効化、セッションでの交渉、品質向上を証明しない。本稿はその性能を評価せず、一般機構と具体的効果の間にある証拠段階だけを扱う。

文書状態と限界

改訂 06 は mlcodec ワーキンググループの有効な Internet-Draft で、2026 年 7 月 23 日付、Datatracker 更新は 8 月 27 日、WG Last Call 中、想定ステータスは Proposed Standard、失効日は 2027 年 1 月 24 日である。RFC ではなく、変更や置換の可能性がある。

本調査は実際のエンコーダー、デコーダー、製品、事業者、通話を試験していない。攻撃、障害、衝突、資源超過、ビットレート、周波数応答、聴取品質も観測していない。例は証拠境界を説明する構成である。

基本音声が出たなら基本出力は観測された。拡張効果は、それとは別に証明されなければならない。

出典