2025 年 12 月時点での時雨堂の QUIC 対応方針

時雨堂では QUIC を利用した音声や映像、データのリアルタイム配信 を少しずつですが準備をしています。そのなかに Media over QUIC (MoQ) も含まれていますが、とはいえ、まだまだ課題が多い分野だと思っているので、本当に少しずつです。

そんな中で 2025 年 12 月現在、QUIC 対応方針をとっているのかを雑に書いていきます。

三行

• msquic 採用する
• Multipath QUIC やる
• Python でやる

前提

時雨堂のサーバー側の QUIC は Erlang/OTP で対応します。実装は最終的に派時前ですが、まずは Erlang/OTP の HTTP サーバーライブラリ Cowboy (HTTP/3 と WebTarnsport 対応済み) を利用する方針です。

書いていくのは基本的にはクライアント側の話になります。

msquic を採用

時雨堂ではクライアント側の QUIC 実装は msquic を採用する事にしました。

• 公式サポートではないが iOS / Android 向けのビルドがある
• CMake を採用している
• 当たり前だが Windows ビルドが簡単
• C で書かれており C++ / Rust からも利用できる
  • 公式で C++ と Rust が提供されている
• Sans I/O ではなく I/O 周りが実装されている
• Python から scikit-build-core と nanobind と cmake の組み合わせで利用できる

色々な QUIC ライブラリを試していたのですが、Python から利用する事を考えると Sans I/O だと厳しいということが一番の理由です。

またプロトタイプとして Python から nanobind 経由で msquic を呼び出して、Media over QUIC Transport (MOQT) を実装したところ特に問題無く動作し、クライアントとサーバーでの E2E テストも上手くいきました。

msquic は Microsoft が開発しており、将来的には 5 年間のメインストリームサポートと 5 年間の延長サポートが提供される公式リリースブランチ LTSC (Long Term Service Channel) も提供されると考えているためです。

Multipath QUIC

時雨堂では QUIC を利用した音声や映像技術でリソースをつぎ込みたいと考えているのは Multipath QUIC です。マルチパスというのは複数のネットワークインターフェースや経路を同時に使って通信を行う技術です。

これにより複数キャリアの携帯網を同時に利用したり、無線 LAN と携帯キャリア網を同時に使用したりすることができます。

時雨堂では msquic を fork して Multipath QUIC を実装し、Python から利用できる用に準備を進めています。まずはサーバー再度も msquic で実装し、将来的に Erlang/OTP に切り替えていきます。

Multipath QUIC が実現すると複数の回線を上手く利用する事で音声や映像、データを安定して送る事ができるようになると考えています。もちろんそんな簡単な話ではないのですが、チャレンジする価値はあると考えています。

ちなみに QUIC のコネクションマイグレーションもすばらしいと考えてます。

なぜ Python ?

時雨堂では QUIC は Python 経由での利用を前提として進めることを考えています。ブラウザ経由は当面は WebRTC で良いと考えており、モバイル経由は検証コストが高いので、まずは検証しやすく色々な部分で応用がきく Python を前提として進める事にしました。LLM との相性が良いのも魅力的です。

そのため Python で音声や映像のコーデックを気軽に扱える webcodecs-py を開発し OSS (Apache-2.0) として公開しています。

これは QUIC では当たり前ですが libwebrtc と違って多くの便利な機能を提供してくれないので、色々時前で頑張る必要があるためです。

また、生データ (NV12 や I420) などを気軽に見られる生データプレイヤーライブラリも絶賛開発中です。こちらも OSS (Apache-2.0) として公開予定です。

さらに、受け取った音声や映像を MP4 で保存するために mp4-py を開発して OSS (Apache-2.0) として公開しています。これは Rust ベースの MP4 ライブラリを C API として公開し、それを Python バインディングとして提供しています。

さらに色々なダミー映像を作るために高性能 2D グラフィックライブラリ Blend2D の Python バインディング blend2d-py も開発して公開しています。

HTTP/3 とかどうするの？

msquic は HTTP/3 の実装は提供していません。あくまで QUIC 実装のみです。そのため、時雨堂では HTTP/3 部分は Sans I/O として提供されている nghttp3 を利用する予定です。WebTransport 部分も将来的に nghttp3 の作者である tatsuhiro-t 氏に相談できればと考えています。最初は Python 実装でも良いと思っています。

ちなみに tatsuhiro-t 氏には時雨堂の QUIC 関連のアドバイザーをしていただいています。本当にありがたいです。

また tatsuhiro-t 氏 は nghttp2 でもあるため、MoQ での TCP フォールバック先である HTTP/2 も nghttp2 を安心して採用できるようもありがたいです。

iOS/Android とかどうするの？

基本的には msquic ベースを考えています。コーデックは HWA のみを利用することで負荷を下げようとも考えています。ただ正直 iOS/Android に関しては libwebrtc を超えるのはすぐには難しいと考えているため、それよりは Multipath QUIC にリソースを振った方が良いと判断しています。

まとめ

MoQ は正直どうなるかわからないので、弊社のような零細企業としてはリソースをあまり割きたくないと考えています。ただ QUIC 自体はとても良いプロトコルだと思っており、特に Multipath QUIC に関しては実現できたら凄く便利な仕組みになるはずだと期待しています。

時雨堂としては QUIC を活用した、Raft ベースでのスケールアウトするリアルタイム配信（音声、映像、データ）を実現し、既存の Sora へ組み込んで提供していければと思います。