Zenn
Open12

Media over QuicTransport(MOQT)動向まとめ

WebRTC
HLS
moqt
yuki_uchidayuki_uchida

前回のinterim-meeting(vol.13)

2023/10/06に開催された。

スライド・議事録はあるが録画は無し。
https://datatracker.ietf.org/meeting/interim-2023-moq-13/session/moq

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的な、「ユーザーに近いところでキャッシュする仕組み」が存在しない。
      • 前のグループのオブジェクトは、現在のグループのオブジェクトよりも重要度が低ければ、これをドロップしても良い
    • 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_uchidayuki_uchida

ACM Mile-High Video 2024

flano_yukiさんのポストで知った。
2024/02/11~2024/02/14で開催される、映像配信技術のカンファレンスらしい。

https://www.mile-high.video/technical-program

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_uchidayuki_uchida

IETF公式のMedia Over QUICの概要

Media Over QUICの概要がIETFで公開された。

https://www.ietf.org/blog/moq-overview/

ユースケース

  • ⭐️ライブストリーミング(映像配信など)
    • これが一番重視しているユースケースのよう。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_uchidayuki_uchida

ゲーム業界におけるリアルタイム通信プロトコルについて

https://github.com/TakeharaR/game-realtime-protocol

調べた動機

ゲーム業界でリアルタイム通信プロトコルといえば独自UDPだと思うが、MOQTおよびWebTransportってどうなのだろう？
以前、MIXIさんがWebTransportに独自RTPを載せて運用されていたことがあったので、それに関連して気になった

https://speakerdeck.com/mixi_engineers/voice-communication-function-using-quic-which-created-on-agones
https://github.com/xflagstudio/requiem

ゲーム業界においてWebTransportはどうなのか

  • QUICならまだしも、WebTransportだとオーバースペック
    • WebTransportが乗っかることによるオーバーヘッドもある可能性
    • WebTransportはWebブラウザでも動くように設計されているが、ゲームにおいてはサーバーもクライアントも自前で実装できるので、無理にこの仕様に沿う必要がない
  • 一方で、メリットもある
    • TCP/UDPライクなユースケースに両対応できて、UDPが通らない(QUICが通らない)環境でもTCPでなんとか通信が可能
      • (感想) 標準化された技術に乗っかると、オレオレUDPとか作った時にISPでブロックされたりしないとかもありそう。
    • ロードバランサーがHTTP3等に対応する可能性が高いため、ロードバランサーで問題が発生する可能性が低い

感想

  • P2Pで通信したいとなるとWebTransportでは足りなさそうなので、P2Pのためには他の方法を考える必要がある。これは確かに大変そうだ。
    • WebTransportはサバクラが先行して策定されていて、p2p-webtransportという単語もあるにはあるが、Web業界的には当分(5年くらい？)サバクラはWebTransport、P2PはWebRTCで棲み分けというのが予想される。
  • P2Pとサバクラ両対応なWebRTCでは何が足りないのだろう？
    • MIXIさんでも以前WebRTC SFUを使って音声通信を提供されていたようだが、WebTransportの検証に踏み切った理由はスライドからは把握できなかった。
    • なんとなく、以下の理由を想像してみた。
      • 数百以上の音声通信をWebRTCでやるのは結構大変だから
      • WebRTCはウェブ会議に特化した処理になっていて、ゲーム業界むけのカスタマイズをするのが難しい(libwebrtcに手を入れなければならない)
      • QUICだとコネクションマイグレーション(接続がwifi -> テザリングに変わっても繋がる)ができる(WebRTCはできない)
    • こちらのスライドでは、「ゲームは小さいサイズのデータを高頻度で送るため、従来の暗号化では無駄が多い」と書かれていたので、この辺りも関係しているのかも。
      • QUICは暗号化必須のプロトコルなので、暗号化部分がネックになるのであればQUICに乗ることも難しいか・・・
      • 暗号化のボトルネックがどの程度なのかは気になる。許容できないレベルなのか？
        • 超低遅延暗号のアルゴリズムとして、Areion が挙げられていた。2023年に論文出された技術らしい。
yuki_uchidayuki_uchida

Media Over QUICTransportのプロトコルスタック

引用: https://datatracker.ietf.org/meeting/interim-2023-moq-08/session/moq

  • プロトコルスタックとしてはQUIC上に構築される。
  • MOQTはあくまで制御やペイロードの定義のみであって、ペイロードの中身のメディアフォーマットについては定義していない。
    • MOQTの上にWARPやLOC(Low Overhead Media Container)を乗せることを前提にしており、ペイロードフォーマットはこちらの仕様によって決定される。
      • WARPはCMAFというファイルフォーマットを前提に設計されている
        • CMAFはHLSやMPEG-DASHなどで利用されている仕様
      • LOCはWebブラウザのWebCodecs APIのフォーマットをそのまま流す前提に設計されている
      • (感想)テキストや3Dデータを流す話もあるらしく、その点ではここの仕様が乱立する可能性がありそう。

感想

MOQTの上に乗せるメディアフォーマットとしては、LOCの方がWebRTCからの乗り換えにおいては楽かもしれない。一方で、HLSやMPEG-DASHからの乗り換えではWARPの方が楽そう

参照

yuki_uchidayuki_uchida

2024/02/08,09のIETF interim-meetingの1日目まとめ

2日(4回)に分けてMTGが行われた。実際に使われたスライドは01,02の内容のみ。これを二日にかけて議論した模様。
https://datatracker.ietf.org/meeting/interim-2024-moq-01/session/moq
https://datatracker.ietf.org/meeting/interim-2024-moq-02/session/moq
https://datatracker.ietf.org/meeting/interim-2024-moq-03/session/moq
https://datatracker.ietf.org/meeting/interim-2024-moq-04/session/moq

注意事項

こちらのコメントで利用している画像は全て以下のスライドから引用しています

引用: https://datatracker.ietf.org/meeting/interim-2024-moq-01/materials/slides-interim-2024-moq-01-sessa-moq-denver-interim-01

moqt-draft 02における相互接続試験の結果

  • draft02への追従はまだ追いついていないようだ。(02は2024/01/24発行のため当然ではある) AlanさんとMartinさんの実装以外は成功していない。
    • 01の相互接続試験結果
    • 02の相互接続試験結果

MoQTのissueについての議論

issueはこちらのGithubに挙げられ議論される。

issueの細かい話については把握しきれていないので割愛。以下サマリ

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の概要についてはこちらをどうぞ。
https://zenn.dev/y_i/articles/common-catalog-format-moqt

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さんのこちらの記事をどうぞ
https://asnokaze.hatenablog.com/entry/2022/02/12/005150

MOQTの上に乗せるフォーマットのことで、以下のようなプロトコルスタックになります。

  • IETF117での内容の再掲
    • WARPを再利用可能なコンポーネントに分解する。
    • (感想)WARPってCMAF前提かと思っていたけど、これを見るとLOCにも対応していそう。となるとLOCとの違いはなんだ？(最新のドラフトちゃんと読まないと分からなさそう)
  • ドラフト・実装の変更点
    • CMAFの定義を別の独立したドラフトにした PR#20
    • WARP Streaming Formatを外部のCatalog定義を参照できるように変更 PR#19
      • CMAFの定義を別のドラフトに移したのに関連して、Catalog定義を好きなものを使えるようにした
    • timeline用のTrackの生成
      • メディアの時間に合わせて何かしらの処理をしたい場合に使う機能っぽい？
      • 映像配信の場合にDVRウィンドウを指定して広告挿入するとかのユースケースが挙げられている
  • CMAFをRFCの中で参照する場合にどうすれば良いのかという相談
    • CMAFはMPEGによって作成された仕様(ISO標準)だが参照して良いのか(HLSは参照しているか良い？)
      • (感想)CMAFの仕様書は有料？だから、こういう話が出てるのかも？
  • 重要な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.

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は正式名称はどれなんだろう？
yuki_uchidayuki_uchida

draft01から05の変更点

https://www.ietf.org/archive/id/draft-ietf-moq-transport-05.html#name-termination
ちゃんと把握しているのが01なので、01から05で変わっていそうなところを整理する

3. Termination

エラーが起きてQUIC/WebTransportコネクションが削除される際のエラーコードが増えた。 Parameter Length Mismatch などは、とりあえず0x1 Generic Errorとかで実装していたが、これによってエラーの理由が明確になった。

Code draft-01 draft-05
0x0 No Error No Error
0x1 Generic Error Internal Error
0x2 Unauthorized Unauthorized
0x3 Protocol Violation Protocol Violation
0x4 - Duplicate Track Alias
0x5 - Parameter Length Mismatch
0x10 GOAWAY Timeout GOAWAY Timeout

4. Priorities

draft-01ではコンセンサスが取れておらず、TODO状態になっていたが、draft-05ではそれなりに定まっている。

  • DataPlane相当のOBJECT / OBJECT_WITHOUT_LENGTHメッセージを除いたControlメッセージは、全てのOBJECT系メッセージよりも優先されるべきである [SHOULD]
  • PublisherとSubscriber両方に優先順位をつけることができ、複数のSubscriberの優先度が同じ場合には、Publisherの優先度を元に優先順位が決定する。PublisherもSubscriberも優先度が同じ場合には実装によって挙動は異なる
  • Subscriberの優先度は SUBSCRIBE_UPDATE メッセージによって変更することができる
  • Subscriptionは複数のグループが送信可能な場合はgroup idの数値の昇順・降順の順番で送られるべきである [SHOULD]
    • どちらを選ぶかは SUBSCRIBE メッセージで指定する
  • 同じgruop内のObjectはIDが低い数値のものから優先的に送信する。

5. Relays

draft-01では SUBSCRIBE_ERROR SUBSCRIBE_DONE メッセージのステータスコードが厳密に定義されていなかったこともあり、draft-05ではそこの詳細化が行われている。

SUBSCRIBE_ERRORのステータスコードが追加

Code Reasion
0x0 Internal Error
0x1 Invalid Range
0x2 Retry Track Alias

SUBSCRIBE_DONEのステータスコードが追加

Code Reasion
0x0 Unsubscribed
0x1 Internal Error
0x2 Unauthorized
0x3 Track Ended
0x4 Subscription Ended
0x5 Going Away
0x6 Expired

また、以前はRelayサーバー周りの挙動についてあまり書かれていなかったが、 UNANNOUNCE ANNOUNCE_CANCEL メッセージが追加されたことでこれらを扱うフローについて追記された。

  • PublisherがANNOUNCEしたものに対する新しいSubscriptionを停止したい時、 UNANNOUNCE を送る
  • Subscriber(ここではrelayを指す？)は ANNOUNCE_CANCEL メッセージを送ることで、以前 ANNOUNCE_OK と応答した ものに対する Subscriptionを新たに中継しないことを示す。

UNANNOUNCE メッセージに対する relayサーバーの返答が ANNOUNCE_CANCEL メッセージになるというわけではなく、独立したメッセージっぽい。

6. Message

MOQTメッセージの種類がかなり増えた。また、各種メッセージが持つプロパティの名前が変更されたり移動したりしている。特に、SUBSCRIBE や OBJECT 周りの変更点が多く、draft01ではメディア処理についてあまり考えられていなかったのが、version4つ分の検討によってかなり進んだ印象。

Code draft-01 draft-05
0x0 OBJECT with payload length OBJECT_STREAM
0x1 - OBJECT_DATAGRAM
0x2 OBJECT without payload length SUBSCRIBE_UPDATE
0x3 SUBSCRIBE SUBSCRIBE
0x4 SUBSCRIBE_OK SUBSCRIBE_OK
0x5 SUBSCRIBE_ERROR SUBSCRIBE_ERROR
0x6 ANNOUNCE ANNOUNCE
0x7 ANNOUNCE_OK ANNOUNCE_OK
0x8 ANNOUNCE_ERROR ANNOUNCE_ERROR
0x9 UNANNOUNCE UNANNOUNCE
0xA UNSUBSCRIBE UNSUBSCRIBE
0xB SUBSCRIBE_FIN SUBSCRIBE_DONE
0xC SUBSCRIBE_RST ANNOUNCE_CANCEL
0xD - TRACK_STATUS_REQUEST
0xE - TRACK_STATUS
0x10 GOAWAY GOAWAY
0x40 CLIENT_SETUP CLIENT_SETUP
0x41 SERVER_SETUP SERVER_SETUP
0x50 - STREAM_HEADER_TRACK
0x51 - STREAM_HEADER_GROUP
yuki_uchidayuki_uchida

Githubで議論されている最近ホットそうなissue

  • Object/group TTL: https://github.com/moq-wg/moq-transport/issues/249
    • https://github.com/moq-wg/moq-transport/issues/440 も関連issue
    • 映像の場合、Keyframe/Deltaframeで依存性があるため、それを適切にキャッシュするにはどうするべきかという議論らしい。
    • HLSのようにキャッシュをうまく使うのがMOQTには求められているため、この辺りは重要な議論になりそう(QUICやHTTP CDN周りの話も出てきていてあまり理解できていない・・・)
  • Adaptive Bit Rateの実現方法: https://github.com/moq-wg/moq-transport/issues/259
    • WebRTCのように、送信側でABRをやるのがリアルタイム通信においては良いが、HLS/DASHは送信側ABRと受信側ABRを組み合わせて使っている。
    • WebRTCはGCCを使っているが、このアルゴリズムは古く、ツギハギして作られているため理解するのが難しい&理解している人がかなり少ない
    • 受信側ABRは色々な研究がなされており、2024ACM MMSysでも Grand Challenge on Offline Reinforcement Learning for Bandwidth Estimation in Real Time Communications というコンペが行われるらしい。
    • Lukeさんの意見では、第三の方法としての Server-side ABRのよう。(一部反対意見もあり)
    • QUICの輻輳制御は固定されているので、QUIC WGとも協調して議論していく必要がある？
  • FECの実現方法: https://github.com/moq-wg/moq-transport/issues/320
    • QUICは複数のデータグラムを結合することがあるため、FECのように、1パケットごとに個別の処理を行う形だと、MOQT上でFECが実装できない。
    • QUICがデータグラムを結合しないように要求するか、QUICレイヤーでFECを導入してもらう必要があり、今後どうするか・・・
      • 議論は既にしており、こちらのドラフトが解決策の一つ
      • QUICはCDN企業の多くが参加して設計しているが、MOQTのWGにはakamaiの方も参加していて、CDN企業と近い場所で議論が出来ているのは素晴らしいなと思った。
yuki_uchidayuki_uchida

moq-transforkについて

https://www.ietf.org/archive/id/draft-lcurley-moq-transfork-00.html
MOQTの第一人者であるLukeさんが出したmoqtのforkドラフト。
このドラフト自体はmoq-transport draft-03から派生して書かれたもので、現在仕様策定が進んでいるmoq-transportに対して、大きく変更を加えたものである。

MOQTはQUICに依存しているため、QUICがサポートしていないことは実現できない。それによって、重要なプロパティが未定義になっており、MOQTには欠陥が残っているというのが、このmoq-transforkのドラフトを書いた理由のようだ。

派生したドラフトとはいえ、完全に別個の実装を新たに作りたいわけではなく、ここで記述した内容はMOQTWGに持ち込まれ、Github issueで議論されているものもある。
なので、もしかしたらdraft 04,05でmoq-transforkの内容が一部含まれているかも。

Objectモデル

MOQTにおいてはメディアの概念とObjectモデルが対応しており、グループはVideoのGoP(I/P/Bフレームをまとめたgroup of picture)、オブジェクトはVideoフレームに相当する。
しかし、QUICとマッピングされた概念ではなく、動的にQUICストリームのプロパティが色々なトラック・グループ・オブジェクト間で移動してしまう(?)ので、すぐに管理不能になるだろうと指摘している。
おそらくは、Lukeさんが想定したよりも仕様が複雑になってしまっているのだろう。

MoqTransforkでは、ObjectモデルはQUICに直接マッピングされた概念であるため、この管理が楽になる(らしい)

Priority

MOQTにおいては、送信側が優先順位を決定する。(これはLukeさん自身が間違ったアプローチを提案したと書かれている)
より良い方法として、送信側・受信側が協調して決定する必要がある。

MoqTransforkでは、優先順位の決定をsubscriberに移譲する。

Control Streams

MOQTにおいては、ANNOUNCEなどの制御メッセージは一つのストリームを共有する仕様になっているため、HoLBの可能性がある。

MoqTransforkでは、サブスクリプションごとに一つのストリームを使い、たくさんの制御メッセージを送ってもHoLBが起きないようにする。また、これによってQUICのステートをそのまま扱うようになり、UNANNOUNCEやUNSUBSCRIBE、SUBSCRIBE_DONE, SUBSCRIBE_ERROR, SUBSCRIBE_RESETなどのメッセージは消せるようになる。

Byte Offsets

MOQTにおいては、接続やSubscriptionが中断された場合、中断されたところから再開するために、グループのObject IDを使っている。しかし、オブジェクトの一部分は再度ダウンロードされることによって、キャッシュが断片化される(?)問題がある。

MoqTransforkでは、FETCHメッセージを使い、Byte Offsetsで始まる不完全なグループを提供する(ちょっと理解が及ばなかった)。

Datagrams

MOQTにおいては、送信者のpublisher track preferenceを通して、QUICのdatagramでOBJECTメッセージを送ることをサポートしているが、これは高レイテンシでも構わないユーザーは体験が悪い

MoqTransforkでは、subscriberがQUICのStreamとDatagramのどちらで受け取りたいかを選べるようにする。DatagramはGroupがMTUより小さく、希望するレイテンシがRTTより少ない時にのみ使用されるべきである。
これによって、Streamのオーバーヘッドを削減しながら再生できる。

おそらく、Datagramはドロップするが、Streamは再送されるため、高レイテンシでも構わないならStream使って、特定の場合だけDatagramを選択しろよってことなのだろう。

Use-Cases

MOQTにおいてはユースケースが曖昧になっており、そのせいで不必要な機能が生じている。

MoqTransforkにおいては、Appendixとしてユースケースを明示し、それに推奨されるアプローチを明記している。

yuki_uchidayuki_uchida

Common Catalog Format draft00と01の変更点

Catalog Formatについてはこちらの記事がおすすめ
https://zenn.dev/y_i/articles/common-catalog-format-moqt

そこまで大きく変更点はない。

  • Common Catalog FormatはJSONで各種パラメータを設定するが、そのパラメータの位置が明示されるようになっている。
  • 各種パラメータ値の型が決定されている。
  • 3.2.12 Track operationsが削除されている。
    • 以前はAdd/Deleteプロパティがあり、SUBSCRIBE可能かどうかを表現していた。
    • おそらくだが、MOQT draft-05を読むと TRACK_STATUS メッセージなどもあるので、Common Catalog FormatからMOQTに責任が移ったのだろう。
yuki_uchidayuki_uchida

IETF119で話されてた内容から面白かったもの

https://datatracker.ietf.org/meeting/119/session/moq

  • LOCのモチベーション
    • CMAFはフレームごとに100bytes以上のオーバーヘッドが存在する。audioの場合は100%以上のオーバーヘッドとなる
    • CMAFはheaderや複数フレームをパッケージング(chunks/fragments/segments)する時に複雑
    • parseする必要なく、フレーム境界がわかる仕様が欲しい