QUIC上でライブメディアなどを扱うプロトコルの標準化が、IETFのMoQ WGで進められています。
WarpやRUSHというプロトコル案が出ていましたが、プロトコルの設計が進み、コアプロトコルになる『Media over QUIC Transport (MOQT)』が登場しています。この仕様は、Twitch、Facebook(Meta)、Cisoco、Googleの方の共著となっています。
プロトコル スタック
MOQTは、QUICプロトコルもしくはWebTransport上に位置するプロトコルです。その上に、Warpのようなメディアフォーマット・ストリームフォーマットを定義する仕様が乗っかります。(WarpとMOQTの役割が分割された感じになります。)
Warp
「WARP Streaming Format」は、MOQTのストリームフォーマットを定義する仕様であり、CMAF [CMAF] 準拠のメディア コンテンツを配信します。
登場人物
MOQTでは、通信の種類として下記の3つの利用を想定しています。
- 動画のアップロード (ingestion)
- 動画の視聴 (delivery)
- CDNなどによる中継 (relay)
そのうえで、登場人物は次のようになります。
ここで、Client/Serverはプロトコルの通信をどちらか開始するかの観点の用語です。Clientには役割に応じて、メディアを送信するProducerと、メディアを受信するConsumerが居ます。その間に通信を中継するRelayサーバが存在し得ます。
また、上記の図では片方向的な送信でしたが、ビデオカンファレンスのようにRelayサーバを介した双方向メディア通信もありえます。その場合はClientはProducerとしてもConsumerとしても振る舞うことになります。
オブジェクトモデル
MOQTはメディアのデータを「Objects」「Groups」「Tracks」という単位で管理します。
- Tracks: 例えばHD Videoトラック、SD Videoトラックといったもので、Consumerが視聴を要求する単位です
- Groups: 複数のObjectのグループで、視聴を開始点できる単位です。例えば、Group Of Picture (一連のI, P, Bフレーム)のグループです。
- Objects: メタデータとペイロードからなるメディアデータ。リレーサーバによって変更や分割・結合は行われない。
TrackはConsumerにより視聴が要求されるため、そのためにFull Track Nameを持ちます。例をみるとわかりやすいかと思います。
Track Namespace = security-camera.example.com/camera1/ Track Name = hd-video Full Track Name = security-camera.example.com/camera1/hd-video
なお、単一のObjectをQUICの単方向ストリームで送信することを想定しています。こうすることでHead of Line Blockingを狙いです。
プロトコル メッセージ
MOQTではプロトコルのメッセージとして以下のものが定義されています。QUICもしくはWebTransportのコネクションが確立するとストリーム上で送受信されます。
- OBJECT: ObjectのPayload及び、配送に必要な情報を含みます。
- SETUP: MOQTの通信の最初にやりとりされる。プロトコルバージョンなど、通信に必要な情報を交換する。
- SUBSCRIBE REQUEST: トラックの受信(subsribe)を要求する
- SUBSCRIBE OK: SUBSCRIBE REQUESTが成功したことを示す
- SUBSCRIBE ERROR: SUBSCRIBE REQUESTが失敗したことを示す
- ANNOUNCE: 受信者がSUBSCRIBEできるトラックを通知する
- ANNOUNCE OK: ANNOUNCEが成功したことを示す
- ANNOUNCE ERROR: ANNOUNCEが失敗したことを示す
- GOAWAY: 通信を終了する
