Media over QuicTransport(MOQT)動向まとめ
yuki_uchidaIETFのサイトにMedia over QUICに関連するInternet-Draftやinterim Meetingの予定が纏まっている。
yuki_uchida前回のinterim-meeting(vol.13)
2023/10/06に開催された。
スライド・議事録はあるが録画は無し。
draft-ietf-moq-requirements-02が 2023/09/29に発行。
- vol1との違いについて整理
-
Handling Scalable Video Codecsセクションの追加- SVCの使う場合、拡張レイヤは前のベースレイヤだけでなく前の拡張レイヤにも依存する。あるオブジェクトを削除すると、依存関係にある全てのオブジェクトが使えなくなる。AV1のドキュメントでも、複雑な依存関係が図示されているため厄介な部分。
- 依存関係をオブジェクトのプロパティとしてエンコードし、その依存関係をクリアできる場合にのみデコードできるようにすることもできるが、relayが複雑になるため、
linear approachが望ましいと考えている。(linear approachは、依存関係をグラフではなく線形で表すこと？)
-
Application choise for orderingセクションの追加- アプリケーションは
frame rate firstかdefinition firstかを選択できる- フレームレート優先か画質優先か
- (感想) WebRTCでは、フレームレートと画質の優先度が厳密に決められなかったが、MOQTでは制御できるらしい。風景を流すか人物の映像を流すかアニメーションを流すかで求める形が異なると思われるので、この制御は素晴らしいが、アプリケーション側でこれを指示できるようにするのはちょっと大変そうだ
- 「最低でも720p@15fps、可能であれば30fpsを確保するようにし、その上でさらに利用可能な帯域幅があれば1080pで60fpsを目指す」といった、非常に高度な制御が可能。
- アプリケーションは
-
Linear ordering using prioritiesセクションの追加- オブジェクト番号とオブジェクト優先順位の組み合わせを使って依存関係を表現する。(具体例あり)
- オブジェクト番号とオブジェクト優先順位はpublisherによって決定され、relay部分で変更はされない
- (感想) Internet Draftなのでどうなるかわからないが、MUSTになるのかな
-
Intervals and congestionセクションの追加- オブジェクトの依存関係にはルールが仕様上設定される。このルールによってリレーや他ノードでのリアルタイムな輻輳制御が可能になる。
- 欠点は、drop priority(不要な場合にパケットを落とす) を持つパケットが実際にドロップされた場合、同じグループ内のシーケンス番号が大きく、drop priorityが高いか等しいオブジェクトを全て落とさなければいけなくなること
- (感想) SVCの時は特に依存関係が複雑なので、どのパケットを落とすかのdrop priorityはかなり綿密に決められてないとバグりそう。
-
Relay behaviorセクションの追加- 輻輳発生時に、relayはオブジェクトの優先順位を用いてオブジェクトをドロップさせる。relayが輻輳の発生を検知し、オブジェクトをドロップさせる方法を持っていることが前提となっている
- (感想1) WebRTCにおけるTURNではない。TURNはRTPパケットの中身を見て制御したりしないため
- (感想2) WebRTCにおけるSFUはSFU単体でオブジェクト選択してドロップさせたりはしていない(多分)ため、あくまで輻輳制御して流すパケット量を変更するのはpublisherなので、WebRTCにおけるSFUがこれをできるのであればかなり効率が良さそう。WebRTCではpub->SFU->subという都合上、pubが制御するのはpub <- SFU間のレイテンシ分遅延しそうだから。
- また、間のrelayのところでデータをキャッシュすることができると、再送要求の遅延が短くなるだろう。WebRTCはCDN的な、「ユーザーに近いところでキャッシュする仕組み」が存在しない。
- 前のグループのオブジェクトは、現在のグループのオブジェクトよりも重要度が低ければ、これをドロップしても良い
- 輻輳発生時に、relayはオブジェクトの優先順位を用いてオブジェクトをドロップさせる。relayが輻輳の発生を検知し、オブジェクトをドロップさせる方法を持っていることが前提となっている
-
High Loss Networksセクションの追加- Web会議システムでは20%以上のパケロスがあるNWで利用されることも多い。この場合、audioは維持してvideoだけ流さないようにする仕組みがよく使われる。
- また、FECや再送などの仕組みによってパケロス耐性を得ることも多い
- 最近では3kbps程度の軽量な音声コーデック(Lyra等)が開発されている
-
interval between access pointsセクションの追加- ストリーミングのユースケースでは、「アクセスポイント間の距離が短い」ことを特徴として、再同期が重要視されている。これにより、早送りや巻き戻しなどの機能に利用できる。
- (感想)ここでいう再同期は、キーフレーム(参照フレーム)を受け取らないと映像をデコードできないので、キーフレームを要求する仕組みが必要だということ。WebRTCでは会議への入室時などにキーフレーム要求が走る。
- 参照フレームはサイズが大きく、差分フレームは参照フレームよりもサイズが小さい。差分フレームは参照フレームに依存するような関係。このため、参照フレームを受け取るタイミングでトラフィックのピークが生じる。このピークは、ビデオ会議のようなユースケースよりも、ストリーミングのようなユースケースの方が吸収するのがはるかに簡単である。
- これが理由で、ビデオ会議では、より長いグループ(chromeでは参照フレームの後の差分フレームが30秒くらい続く)が使われている。
- ストリーミングのユースケースでは、「アクセスポイント間の距離が短い」ことを特徴として、再同期が重要視されている。これにより、早送りや巻き戻しなどの機能に利用できる。
-
Media Insection and Redirectionセクションの追加- 広告の挿入などでは、メディアのソースが別のものに切り替わったことを消費者に伝えたい(広告再生中であると消費者が分かるように)。
- メディアのソースが変わったらデコーダの初期化などが必要。なのでこれを消費者に伝える必要がある
- 広告の挿入などでは、メディアのソースが別のものに切り替わったことを消費者に伝えたい(広告再生中であると消費者が分かるように)。
-
Media Encriptionセクションの修正
-
次回のinterim-meeting(vol.14)
2024/02/08,09に開催予定。
yuki_uchidaACM Mile-High Video 2024
flano_yukiさんのポストで知った。
2024/02/11~2024/02/14で開催される、映像配信技術のカンファレンスらしい。
Day3にはMOQT関連のセッションがある。
- Video Streaming 4: Low-Latency Media and Media over QUIC
- MoQ Goes to Kindergarten (Our Little Streaming Format Grows up)
- This is The Way: Prioritization in Media-over-QUIC Transport
- MOQTで議論されている「優先順位」の話。オブジェクトの依存関係が複雑になりそうなので、この辺りの議論は最近のMOQTで議論されている大きなトピックなのかも。
- Ultra-low Latency Video Delivery Over WebRTC Data Channels
- MOQTではなく、WebRTC DataChannelを利用した超低遅延配信のセッションっぽい。WebRTC SFUを多段に繋げてやるケースはよくあるが、その中でもDataChannelを使っているのは初めて聞いた。面白そう。
- Toward WebTransport Support in dash.js
- MOQTの普及には再生プレイヤーの対応も必要なので、こういった話がすでに進んでいるのは驚いた。結構普及が早いのかも知れない。
yuki_uchidaIETF公式のMedia Over QUICの概要
Media Over QUICの概要がIETFで公開された。
ユースケース
- ⭐️ライブストリーミング(映像配信など)
- これが一番重視しているユースケースのよう。Youtubeやtwitchなどの数秒~数十秒の遅延を1秒未満に削減することで、配信者と視聴者のインタラクションを強化する。
- リアルタイムコラボレーション(ビデオ会議など)
- 「遅延が低いビデオ会議サービスは、コスト効率の高い方法でスケールアウトすることができません」と書かれていることから、こちらも視野には入れているよう。
- 一方で、WebRTC事業者目線では、まだ遠いんじゃないかなという気がする。RTP Transport など、WebRTC側でも色々と変更が想定され、根本からWebRTC=>MoQへの乗り換えは大変そう。(技術遺産をMoQに載せ替える作業が必要)
- ゲーム(クラウドゲーミング？)
歴史的に重要な観点
いくつかの技術をまとめて一つのテクノロジーセットにするというモチベーションから、複数の技術のいいとこ取りを目指している。
- WebRTC(RTP)のリアルタイムメディアに関する知見
- HLS/DASH/HTTP CDNのスケーラビリティのアイデア
低遅延かつ高品質なプロトコルとして策定が進められている。
- WebRTCは低遅延だが高品質を維持するのが困難。また、スケーラビリティにも問題があり、一般的には数百が限界
- HLSは高品質だが低遅延で配信できない。
その他素晴らしい点
- MoQではメディアをEnd-to-Endで暗号化できる。さらに、暗号化した上で、キャッシュに必要な情報にはアクセスできるように設計されており、relayするサーバでパケットを取捨選択してキャッシュしたり、輻輳制御の結果ドロップしてエンドユーザーに配信することができる。
- MoQはユースケースによって柔軟なカスタマイズが可能である。「フレームレートと画質のどちらを優先するのか」「映像と音声のどちらを優先するのか」「レイテンシと品質のどちらを優先するのか」を選択できる。WebRTCやHLSではこの制御が難しい。
- (感想)「どういった制御をするべきなのか」はユースケースによって異なるため、正しくアプリケーション側で定義するのはそれなりに難しそうだ
気になった点
MOQTがWebRTCやHLSの次の技術であることはわかっていたが、他の市場にも影響を与える可能性が記載されている。
ジェニングス氏は、MoQ はメディア配信を改善するために設計されていますが、それによってさらに多くのことが可能になり、他の市場に利益をもたらすだろうと述べています。
「MoQ は実際には、メディアの配信以上のことを可能にする非常に汎用的なメカニズムです」と彼は説明します。「MoQ を使用すると、低遅延、高ファンアウト、高スケーラビリティで機能するパブリッシャー/サブスクライバー ネットワークをインターネット上に構築でき、これは多くのアプリケーションに使用できます。」
- IoT
- プッシュ通知
- 5Gネットワーク
- テキストメッセージングプロトコル
- (感想) 確かに、WebRTCやWebSocketでも実現可能だが、ビデオ会議システムでは映像・音声はWebRTC、テキストはWebSocketというのが一般的である。ここが面倒なところではあるので、この辺りも含めて一つのプロトコルに統合するというのは革新的。Next WebSocketの側面はあまり聞かなくなっているが、今でも視野の中には入っていそう。
今後の動きで面白そうな点
- 2024/02/06にMOQTのhackathonが予定されており、相互接続試験が行われる予定
- (参加したかった・・・)
yuki_uchidaゲーム業界におけるリアルタイム通信プロトコルについて
調べた動機
ゲーム業界でリアルタイム通信プロトコルといえば独自UDPだと思うが、MOQTおよびWebTransportってどうなのだろう？
以前、MIXIさんがWebTransportに独自RTPを載せて運用されていたことがあったので、それに関連して気になった
ゲーム業界においてWebTransportはどうなのか
- QUICならまだしも、WebTransportだとオーバースペック
- WebTransportが乗っかることによるオーバーヘッドもある可能性
- WebTransportはWebブラウザでも動くように設計されているが、ゲームにおいてはサーバーもクライアントも自前で実装できるので、無理にこの仕様に沿う必要がない
- 一方で、メリットもある
- TCP/UDPライクなユースケースに両対応できて、UDPが通らない(QUICが通らない)環境でもTCPでなんとか通信が可能
- (感想) 標準化された技術に乗っかると、オレオレUDPとか作った時にISPでブロックされたりしないとかもありそう。
- ロードバランサーがHTTP3等に対応する可能性が高いため、ロードバランサーで問題が発生する可能性が低い
- TCP/UDPライクなユースケースに両対応できて、UDPが通らない(QUICが通らない)環境でもTCPでなんとか通信が可能
感想
- P2Pで通信したいとなるとWebTransportでは足りなさそうなので、P2Pのためには他の方法を考える必要がある。これは確かに大変そうだ。
- WebTransportはサバクラが先行して策定されていて、p2p-webtransportという単語もあるにはあるが、Web業界的には当分(5年くらい？)サバクラはWebTransport、P2PはWebRTCで棲み分けというのが予想される。
- P2Pとサバクラ両対応なWebRTCでは何が足りないのだろう？
- MIXIさんでも以前WebRTC SFUを使って音声通信を提供されていたようだが、WebTransportの検証に踏み切った理由はスライドからは把握できなかった。
- なんとなく、以下の理由を想像してみた。
- 数百以上の音声通信をWebRTCでやるのは結構大変だから
- WebRTCはウェブ会議に特化した処理になっていて、ゲーム業界むけのカスタマイズをするのが難しい(libwebrtcに手を入れなければならない)
- QUICだとコネクションマイグレーション(接続がwifi -> テザリングに変わっても繋がる)ができる(WebRTCはできない)
- こちらのスライドでは、「ゲームは小さいサイズのデータを高頻度で送るため、従来の暗号化では無駄が多い」と書かれていたので、この辺りも関係しているのかも。
yuki_uchidaMedia Over QUICTransportのプロトコルスタック
引用: https://datatracker.ietf.org/meeting/interim-2023-moq-08/session/moq
- プロトコルスタックとしてはQUIC上に構築される。
- WebTransportも含まれる。WebTransportは省略して、QUICの上に直接構築するのも許容される
- 既存のライブラリを読むと、サーバー側はWebTransportとRAW QUICの両方に対応するようになっている
- WebTransportも含まれる。WebTransportは省略して、QUICの上に直接構築するのも許容される
- MOQTはあくまで制御やペイロードの定義のみであって、ペイロードの中身のメディアフォーマットについては定義していない。
- MOQTの上にWARPやLOC(Low Overhead Media Container)を乗せることを前提にしており、ペイロードフォーマットはこちらの仕様によって決定される。
- WARPはCMAFというファイルフォーマットを前提に設計されている
- CMAFはHLSやMPEG-DASHなどで利用されている仕様
- LOCはWebブラウザのWebCodecs APIのフォーマットをそのまま流す前提に設計されている
- (感想)テキストや3Dデータを流す話もあるらしく、その点ではここの仕様が乱立する可能性がありそう。
- WARPはCMAFというファイルフォーマットを前提に設計されている
- MOQTの上にWARPやLOC(Low Overhead Media Container)を乗せることを前提にしており、ペイロードフォーマットはこちらの仕様によって決定される。
感想
MOQTの上に乗せるメディアフォーマットとしては、LOCの方がWebRTCからの乗り換えにおいては楽かもしれない。一方で、HLSやMPEG-DASHからの乗り換えではWARPの方が楽そう
参照
yuki_uchida2024/02/08,09のIETF interim-meetingの1日目まとめ
2日(4回)に分けてMTGが行われた。実際に使われたスライドは01,02の内容のみ。これを二日にかけて議論した模様。
注意事項
こちらのコメントで利用している画像は全て以下のスライドから引用しています
moqt-draft 02における相互接続試験の結果
- draft02への追従はまだ追いついていないようだ。(02は2024/01/24発行のため当然ではある) AlanさんとMartinさんの実装以外は成功していない。
- 01の相互接続試験結果
- 02の相互接続試験結果
- 01の相互接続試験結果
MoQTのissueについての議論
issueはこちらのGithubに挙げられ議論される。
issueの細かい話については把握しきれていないので割愛。以下サマリ
- SUBSCRIBEメッセージにERROR/FIN/RSTがあるが、他にも
TRACK_OVERとか必要なのでは？また、FINとRSTは同一なのでは？統合してメッセージ減らす余地もあるかもしれない - オブジェクトが全く送信/作成されなかったときに、SUBSCRIBE_FIN/RSTでどうやって表現する？現状表現方法がないので新たなフラグ等が必要になる。
- group N の全てをsubscribeするときにどうやって指示する？
- https://github.com/moq-wg/moq-transport/issues/312
- groupは映像や音声の塊のことで、映像ではkeyframeから最後のdeltaframeまでを指す
Rapid Recoveryについて
有線からwifiに突然切り替えた時に、高速に復旧させる処理
- Receiver側の場合の処理
- こちらは仕様の変更をせずとも実現可能。
- Receiverが切り替わり、QUICコネクションが切断され、Consumerが0人になった場合でも、relayは多少の時間維持するため、復旧可能
- Publisher側の場合の処理
- こちらは仕様の変更が必要。
- Producerが切り替わった場合、QUICコネクションが切断される前にANNOUNCEメッセージがRelayに送られ、このタイミングで同じ名前のTrackが生成されてしまう。同じ名前のTrackが生成されたタイミングで、既存のTrackと新規のTrackのSUBSCRIBEメッセージをPublisherが受け取るようにしたい
そのほかの複数の切り替えシナリオについても議論されている
- QUICのコネクションマイグレーションで再接続はできるのでは？という話
- 議事録の中で、「QUICのコネクションマイグレーション使えば？」「WebTransportはQUICを前提としていない」というやりとりがあった。
- 恐らく、WebTransportはQUICが通らない時のためにover HTTP2も想定しているので、フォールバックした時のことも考えるとQUICのコネクションマイグレーションを前提とした仕様にはできないということなのだろう。
Common Catalog Format
MOQTではOBJECTメッセージがメディアをペイロードとして含めて送受信されますが、ペイロードの仕様については定義しておらず、LOCやWarpなどの仕様によって定義されます。これらの仕様を統合するのがCommon Catalog Formatです。
Common Catalog Formatの概要についてはこちらをどうぞ。
Common Catalog FormatのissueはGithubに挙げられ、議論される。
こちらもPRやissueの議論がメインなので、抜粋して紹介。
- JSONの形式として、JSON Patch(RFC6902)とJSON Merge Patch(RFC7396) のどちらをサポートするか議論になっていたが、 JSON Patch(RFC6902) の対応で合意が取れた
- Catalogのtrack nameが継承できるようになった。
-
commonTrackPropertiesプロパティをrootに追加し、継承するプロパティを毎回付与しなくても良いようにする仕様の提案 - DRMを必要とするフォーマットに対してDRMデータを伝送するために、現在のカスタマイズメカニズムは十分か？
- IETF118(2023/11)でCENC DRM情報を付与するためのフィールドが提案されたが、特定の技術に特化しすぎているとして却下された。
- 対案として、DRM情報を伝送するためにカスタムフィールドに好きにフィールドを追加して良いという仕様が提案されている
Live Edge, Expiry Edge & Gaps
ここについては理解が追いついていないため大雑把に要約。
- Groupの中の各Objectの有効期限が異なる場合に、どのような処理をするべきかについて議論？
- 複数Relayがあったときに、Clientが複数のrelayにリクエストを送ると、レスポンスに含まれるlatestなObjectの値がそれぞれ異なる可能性がある件について議論？
- relayからrelayに最新Group/Objectの情報が伝播するまでに時間がかかるためこの問題が発生する？
- 最新Objectがどれかクライアント側でわかったとして、それをリクエストした時に別のrelayにアクセスしてしまったら情報が共有されておらずエラーになるみたいな話かな・・・
- sliding DVR windowを導入する方法が挙げられている
- ex) Objectナンバーが15以前はexpireしていて、15-20がCurren Group, 21-25がFuture Groupの場合に、13-21のObjectのsubscribe要求が来たらどうするか？など
この辺りの解消のためにsubscription APIをSUBSCRIBEとFETCHの二つの仕様に分けることが提案されている
WARP Draftのアップデートについて
WARPについてはflano_yukiさんのこちらの記事をどうぞ
MOQTの上に乗せるフォーマットのことで、以下のようなプロトコルスタックになります。
- IETF117での内容の再掲
- WARPを再利用可能なコンポーネントに分解する。
- (感想)WARPってCMAF前提かと思っていたけど、これを見るとLOCにも対応していそう。となるとLOCとの違いはなんだ？(最新のドラフトちゃんと読まないと分からなさそう)
- WARPを再利用可能なコンポーネントに分解する。
- ドラフト・実装の変更点
- CMAFをRFCの中で参照する場合にどうすれば良いのかという相談
- CMAFはMPEGによって作成された仕様(ISO標準)だが参照して良いのか(HLSは参照しているか良い？)
- (感想)CMAFの仕様書は有料？だから、こういう話が出てるのかも？
- CMAFはMPEGによって作成された仕様(ISO標準)だが参照して良いのか(HLSは参照しているか良い？)
- 重要なissue
- Seeking&DVR: リアルタイムとVODの二つの要素をWARPは兼ねているので、シークバーも使えないと行けない
- Bitrate Adaption: 可変アダプティブビットレートの実現方法
- Adverting Insertion: 広告挿入の実現方法
分散AdaptiveBitRateについて
MOQTでは、Publisher -> Relay1 -> (Relay2) -> Consumer(Client)という流れでデータが流れていくため、どの区間で品質を計測してbitrateを調整するべきなのか？という議論が出てくる。
シンプルにはfinal hopだけやるのが考えられる。
以下の画像の下の構成図のように、final hop以外でもAdaptive Bitrateを実現したい場合には、SUBSCRIBEメッセージを拡張してあげる必要がある
- (感想) 確かに、relay1とrelay2の間の帯域幅が何かしらの原因で圧迫される可能性はある。(例えばUS->EUへの転送など) なので、final hopだけのABRでは上手くいかないかもしれない。
- ここで書かれているABR、サイマルキャスト的な意味で使われていることに注意。複数画質をrelayに送信し、帯域幅によってどの画質を転送するかを決めている。
-
Publisher produces multiple copies of the content at different bitrates
and quality levels.
-
- ここで書かれているABR、サイマルキャスト的な意味で使われていることに注意。複数画質をrelayに送信し、帯域幅によってどの画質を転送するかを決めている。
Content Protetion
ネットワークレイヤーではQUICがTLS/DTLS相当のセキュリティを担保しているが、DRMやE2EE(End-to-End Encription)をどうやって実現するかについての議論。
Encryptionレイヤーの追加
現時点では、EncoderとPacketizer、DecoderとPacketizerの間に新たにEncryptionレイヤーを作成してそこで暗号化することを想定。鍵はライセンスサーバを経由してやり取りを行う。
ecription プロパティの追加
Encriptionレイヤーを追加するにあたって、CatalogとTrackの両方に encription プロパティを追加することを提案。
画像にある cenc は Common Encryption のことで、MPEG-DASHのDRMで使用されている暗号技術。
ここでは複数の暗号技術を選択できると思われる。
KeyMap
どのgroupがどの復号鍵を使う必要があるかを keyMapで表現する。暗号化されていないgroupは-1で通知される。
- この仕組みによって、鍵は動的に入れ替えることが可能。
“keyMap”: [
[10, 0], // groups 10 to 19 are encrypted with keys[id=0]
[20, -1], // groups 20 to 24 are unencrypted (an inserted ad)
[25, 1], // groups 25 to 49 are encrypted with keys[id=1]
[50, 2] // groups from 50 onward are encrypted with keys[id=2]
]
Note: groups
感想
- 議論内容がかなり多い。参加者 を見ても、Google/Cisco/Meta/Tencentなど、配信事業をやっている会社の方が参加している(合計33人)。盛り上がっているのかも？
- jitsiの方が参加しているのも見えた。Web会議的な観点ではまだまだ遠いような気がするが、どうだろう・・・
- ところでMOQTとMoQT、WAPRとWarpは正式名称はどれなんだろう？