Media over QUIC Transport 対応について

4 min readApr 6, 2024

Media over QUIC Transport (以下 MOQT) 対応に期待していますとお話をいただく事が増えてきたので、スタンスを明示しておこうと思います。

また MOQT について雑に意見を書いておきます。

まとめ

対応はします。ただし 2024 年中とかではないです。MOQT はまだまだ課題があるという認識で枯れている WebRTC と比較すると、実際に利用するところまでは来ていないというスタンスです。

もちろん新しい技術としては面白いのですが、時雨堂は「パッケージ製品」を販売しているので、今の時点で急いで対応するということはありません。

実際問題 WebRTC でも大規模配信が実現可能になっている今、MOQT に急いで対応しても、クライアント SDK の開発から始まり仕様が不確定な部分も多いと言うこともあり、正直採用してくれる企業はほとんどないと思います。実証実験であれば既存の OSS を利用するで充分です。

そのため、早くとも 2025 年だと考えています。

MOQT 対応は自社ですでに販売している製品に追加機能として対応します。価格は据え置きで追加費用などは一切ありません。

つまり自社製品を採用してくれているお客様はそのまま MOQT が利用できるようになります。さらに SDK も Sora SDK に追加する形で対応しますので、WebRTC と MOQT の両方が利用できるようになります。

つまり、MOQT 用に新しく何かの費用を払うといった必要はありません。

すでに Erlang/OTP のみで QUIC の実装を進めており、動作済みです。さらにそこに HTTP/3 と WebTransport を追加実装する予定です。

WebRTC SFU という名前がマッチしないので、Media Server とかにするかもしれませんが、ここはまだ何も考えていません。

MOQT は WebTransport と QUIC の両方が利用できます。ブラウザは WebTransport 対応必須ですが、モバイルであれば QUIC だけでも問題ありません。

自社製品でも両方に対応します。最初は QUIC のみになると思います。

自社製品向けに提供している SDK に追加という形で MOQT 対応しますので、気軽に MOQT を利用できるようにします。

負荷試験ツールなどもすでに公開しているツールに追加という形で提供します。

MOQT は QUIC というモダンなプロトコルを利用した新しいメディア配信プロトコルです。すでに動く OSS などは出てきていますがまだまだこれからです。

自社が得意としている双方向リアルタイムコミュニケーションというよりかは、片方向配信よりです。低遅延で大規模配信を実現するというのがゴールです。

ただ、WebRTC は「スケールしない」という世界から脱却しています。すでに多くの SaaS は大規模で WebRTC を実現し始めています。

このタイミングでまだまだ未完成の MOQT 切り替えるというのはあまりうまみがありません。将来的に MOQT が配信のメインになる時代が来るかも知れませんが、まだまだ先です。

超低遅延での配信はまずは WebRTC が侵略してきそうというのが自分の感想です。これはもちろんポジショントークですが、自社がお手伝いしている Twitch のバックエンドである Amazon IVS も WebRTC の大規模配信を実現しています。

レイテンシーを優先しすぎるという問題が WebRTC にはありますが、それでも大規模配信というのが実現できるようにはなってきています。

そもそも MOQT でいきなりやったとしても、ノウハウが少なすぎます。libwebrtc のような 10 年投資されたライブラリもありません。libwebrtc を超える低遅延向けクライアントライブラリを作るのは本当に大変です。

OBS も libdatachannel を利用した WebRTC の配信に対応し始めています。

まずはいったん WebRTC が広まっていくというのがここ数年で、その後 MOQT にゆっくり置き換わっていくと考えています。

なので、研究開発などでなければ、あせって MOQT をやるより、WebRTC に取り組む事をオススメします。