Twitchは、HLSの代わりとなる、ライブ配信プロトコルWarpを開発している
（情報: MLへの投稿、 カンファレンスでの発表）
このWarpと呼ばれるプロトコルの仕様「Warp - Segmented Live Video Transport」が、IETFに提出されています。
以前書いたFacebookのRushとは異なり、アップロードではなく配信がわのプロトコルのようです。面白そうなので、軽く目を通していこうかと思います
Warp
WarpはWebTransport上で実行されるようですが、今回提出された仕様では、QUICやWebTransportのコネクション確立には触れてません。
コネクションの確立後に、QUICの単方向ストリームを用いて、MP4(CMAF)を送信する方法について説明しています。
仕様の用語を用いると、通信はMedia producerからMedia consumerにセグメント化されたMP4が配信されます。
簡単にまとめると次の通り
- QUIC単方向ストリームでセグメントを送信する
- パケロス時の再送はすべてQUICレイヤに任せる (DATAGRAMフレーム使わない)
- 各セグメントを異なるストリームを用いて、パケロス時のヘッドオブラインブロッキングを回避する
- Media producerは各セグメントにPriorityを設定でき、高 priorityから優先して送信される (基本 最新のデータの方が優先度が高い。なので、パケロスの再送は相対的に優先度が低くなる)。オーディオストリームと、ビデオストリームで異なるPriorityの設定もできる。
- Media consumerは、パケロスしたデータに対してどれくらい待つか自身が判断する (巻き戻し出来るようにデータは受け取って起きたいなど。) ただし、ストリームの並列数に上限があるので、優先度の低いものからMedia consumerによってクローズされる。
(疑問: リクエストURLは、WebTransport確立時に与えられているってことでいいのかな)
メッセージとセグメント
各ストリームではメッセージと一つ以上のセグメントを送ることが出来る。メッセージはセグメントのメタデータで、識別子やPriorityが含まれる。セグメントは、 初期化セグメント(ftyp, moovなど)とメディアセグメント(styp, styp, mdat)の2種類がある (CMAFの要件を満たす)。
メッセージはjson形式であり、仕様上はinit, media, priority という値が定義されている。なお拡張可能になっている。（今後形式は変わるかも）
以下に例を示すが、mediaとpriorityなどJSONは結合してもよい。
init: 後続に初期化セグメントが続くことを示すメッセージ。初期化セグメントのIDを持つ。1つずつ増加していく
{
init: {
id: int
}
}media: 後続にメディアセグメントが続くことを示すメッセージ。関連する初期化セグメントのIDとタイムスタンプを持つ。
{
segment: {
init: int,
timestamp: int,
}
}priority: ストリームの優先度を示す。
{
priority: {
precedence: int,
}
}
その他の補足
いくつかの疑問にメーリングリスト上で回答している
https://mailarchive.ietf.org/arch/msg/moq/0ZNlt5SvEzH3mroPOHjlAFpfHDI/
