IETFではQUICを使ってライブ映像などのメディアを転送するためのプロトコルの標準化を進めています。
MoQ (Media over QUIC) WGでは、今までユースケースや要件の整理を行ってきました。そうして、配信者からのアップロード(ingest) + 視聴者への配信 (distribution)をユースケースとして、メディアをQUIC上で配送するプロトコルの標準化を目指しています。
議論の中では、各社が独自に開発してきたプロトコルの紹介も行われました。
- Facebook: RUSH - Reliable (unreliable) streaming protocol
- Twitch: Warp - Segmented Live Media Transport (draft 01)
- Cisco: QuicR - Media Delivery Protocol over QUIC
先月行われたMoQ WGの中間会議では、各社の提案をもとに、メディアを転送するためのコモンプロトコルの設計について発表がありました。
(スライドpdf)
それが今回取り上げる、base draftと呼ばれるものです。
Base Draft
中間会議のあと、実際に提案仕様として提出されたのが「Warp - Segmented Live Media Transport (draft02)」です。プロトコルの名称は、Warpの名前を冠していますが中身はメディア転送用のcommon protocolになっています(参照: MLでの投稿)。先に上げたTwitch, Facebook(Meta), Ciscoの方の共著になっています。
ingestやdistributionなどの用途まではまだ設計されていませんが、その用途でもcommon protocolがベースになるものと思われます。
まだ、メディアを転送するための必要最低限を定義しただけで、設計のたたき台という意味が強そうです。
ざっくり次のような感じです
- WebTransportを用いた、一方向ストリーム
- 拡張で双方向ストリームもサポート
- CDNなどのリレーサーバを意識した設計
- 明示的な順序付け
- 優先度
- セグメントとしてfragmented MP4を利用 (その他も使えるようにする)
- (HTTP DATAGRAMは拡張でサポート?)
( メディアエンコーディングする都合、ソフトウェアエンコーディング/ハードウェアエンコーディングを色々考慮されてそうだが、僕個人が詳しくないのでよく分からず... )
Base Draftのメッセージ
「Warp - Segmented Live Media Transport (draft02)」はまだたたき台で、必要最低限の部分しか定義されていませんが、ストリームの様子を見ていきます。
現在仕様では、ストリーム上でやり取りされるメッセージは次のようになっています。
各ストリームでは次のメッセージが送信されます
- HEADERS: セグメントを配送するためのメタデータ。優先度や依存関係を指定できる
- SEGMENT: fragmented MP4 (初期化フラグメントを持つか、それを持つ他のストリームに依存する必要がある)
- APP: 任意のデータ
- GOAWAY: 接続のGracefullシャットダウンを要求する (クライアントに接続し直させる)
HTTPではストリーム上でやり取りされるデータをフレームと読んでいましたが、メディアの用語との混乱を避けるため、ストリーム上でやり取りされるデータをメッセージと呼びます。
HEADERSメッセージ
セグメントを配送するためにHEADERSメッセージを送ります。これらの情報はリレーする際にも利用されます。
HEADERSは次のフィールドを持ちます。
- id: HEADERSメッセージの一意な識別子
- order: 配送順序を指定する整数値。この順番に配送されるように優先制御される。
- depends: セグメントのデコーディングに必要な依存関係を配列値として指定する。