要約

  • RFC 2448は、重要度の高いHP情報をより確実に届け、残りのLP映像は通常の経路に残す設計を提案した。
  • HPの受信だけでは、LPの到着、両者の整合、復号、期限内の表示まで証明できない。

圧縮によって、すべてのビットが同じ役割を担うわけではなくなった。映像の構造や復号パラメーターを記す情報がある一方、大半の視覚情報を運ぶ部分もある。しかしネットワークに見えるのはパケットだ。優先制御を備えていなければ、どの欠落がコーデックに大きく響くかは判断できない。

RFC 2448は、その判断をエンコーダーやアプリケーション側に置いた。送信側は、復号に不可欠とみなす高優先度（HP）セグメントと、残りの低優先度（LP）セグメントを分ける。HPを先に信頼性のある転送で届けてからLPを流す、別個のRTPパケットに載せる、元のストリームに含めたまま複製を送る、あるいは再利用可能なHP情報を帯域外で一度送り受信側にキャッシュする、といった方法がある。ネットワークに優先度を求めず、送信側が信頼性の経路を分ける発想だった。

難所は分類にある。RFCは、HPの識別には符号化方式の構文と意味を理解する必要があり、あらゆるビットストリームに通用する方法はないと述べる。MPEG-2の例では、ヘッダーだけのHP部分は通常、映像データの2％未満だった。DC係数まで含めると約40％に増え、HP単独でも多少利用できる映像を構成できるが、信頼して届ける量も大きくなる。これはRFC内の例であり、映像一般の測定値ではない。

HPを先に配れば損失にさらされる時間は減るが、開始待ちが増える。別のRTPパケットにしたHPは異なるペイロードタイプを使いつつ、主映像と同じタイムスタンプ形式やSSRC空間を共有できる。ただし識別子の共有は、配送の保証を共有することではない。元の非分割ストリームにもHPを残し、損失時だけ別コピーを使う設計も可能だ。帯域外で一度送る再利用可能な情報ではタイムスタンプに意味がない場合があり、キーフレームや、利用できる場合のマーカービットがLPとの位置合わせに役立つ。

受信側に必要なのは、信頼できる転送が終わったという事実だけではない。HPが現在のコーデック版とLPストリームの該当位置に合うか、必要なLPが届いたか、復号結果が再生期限に間に合ったか、表示まで行われたかを別々に確かめる必要がある。HPの完全受信だけでは、どれも答えられない。

RFC 2448は1998年11月のInformational文書で、インターネット標準を定めるものではない。AT&T/Lucentの特許に言及し、IESGとIETFはいずれも特許の有効性、範囲、ライセンスの可用性について立場を示さないと明記した。文書が技術を記述していても、採用、現在の展開、相互運用性、視聴者への効果が立証されたわけではない。歴史的な要点は、選択的な信頼性によって転送上の問題がコーデックの方針へ移り、経路を増やすたびに検証すべき接合条件が生まれることだ。

出典

RFC 2448；RFC 2448の記録；IETF Datatrackerの記録；RFC 2448の正誤表；RFC 2250：MPEGのRTPペイロード；RFC 3550：RTP；RFC 2198：冗長音声データ；RFC 2733：RTP FEC；RFC 5109：RTP汎用FEC；RFC 4588：RTP再送；RFC 1191：経路MTU探索；RFC 1889：初期のRTP仕様；Heng Lu：実行コードの優先；Heng Lu：仕様と自発的な採用。