Cloudflare、QUICベースのメディア配信MoQ CDNを初公開

 (moq.dev)
8 ポイント 投稿者 GN⁺ 2025-08-24 | 1件のコメント | WhatsAppで共有
  • Cloudflareが初のMedia over QUIC(MoQ)ベースのCDNを正式公開
  • MoQはリアルタイムメディア配信のための新しい標準で、WebRTC、HLS/DASH、RTMP/SRTを置き換えることが期待されている
  • 現在は開発者プレビュー段階で、Cloudflareの公開エンドポイントを通じて複数のクライアントやライブラリでテスト可能
  • リアルタイム配信の送出と視聴、AIベースの字幕などの試験的機能がWebおよびRustクライアントで提供される
  • まだ認証、Safari対応、ANNOUNCEなどの主要機能は未実装で、関心のある開発者は自分でMoQリレーを運用することもできる

Cloudflare、初のMoQ CDNを正式リリース

紹介

  • CloudflareがMedia over QUIC(MoQ)標準ベースのCDNを正式リリースしたことで、リアルタイムメディア配信分野に大きな変化を予告している
  • MoQは、リアルタイム動画や音声などのライブメディアデータ配信において、既存のWebRTC、HLS/DASH、RTMP/SRTプロトコルをすべて置き換える次世代標準として注目されている
  • 今回の公開は正式な製品の形で行われ、世界中のAnycastネットワーク上で実際の利用者が直接テストできる
  • Cloudflareは最初のMoQ CDN事業者となり、この技術はリアルタイムメディア配信エコシステムの革新を促進すると見込まれる

現在提供されている機能

  • 本技術はプレビュー版であり、サービスの安定性と機能範囲には制限がある
  • Cloudflareはrelay.cloudflare.mediaoverquic.comという公開エンドポイントを公開している
  • 以下のようなさまざまなオープンソースライブラリやクライアントを通じてテストできる
  • Webデモやライブラリを使って、ブラウザ内でリアルタイム配信の送出と視聴が可能
  • AIベースの字幕処理機能を試験適用
    • ブラウザ内で[silero-vad]、[whisper]、[transformers.js]、[onnxruntime-web]、[WebGPU]などの技術により字幕を生成・配信
  • Web Component方式のAPIだけでなく、JavaScript APIによる高度な活用にも対応
  • Rustライブラリにより、MP4インポート、ffmpeg連携、gstreamerベースの配信送出・視聴など、JavaScriptを好まない層向けの環境も用意されている

未実装の機能

  • 現在提供されているバージョンは、限定的なDraft-07サブセットのみをサポートする
  • まだ提供されていない主な機能
    • 配信認証未対応: 各配信ごとに推測されにくい名前を自分で指定する必要がある
    • ANNOUNCE未対応: 配信開始・終了の検知機能がない
    • Safariブラウザ未対応: WebTransport対応の問題によりSafari互換がない
    • 最適化未完了: ユーザー体験などは段階的に改善予定
  • 必要に応じて、直接moq-relayインスタンスを構築し、高度な機能を活用できる
    • JWTベースの認証、Safari/TCP向けのWebSocketフォールバックなどの追加機能を開発中
    • terraformモジュールでグローバルなCDNネットワークを構成することも可能

MoQとCloudflareの意味

  • MoQの標準化作業は3年以上続いており、実際に世界的に採用されるまでにはかなりの時間がかかる見込み
  • CloudflareはRFC採択前に実製品を迅速に投入することで、開発者と利用者から実質的なフィードバックを引き出す大胆な判断を下した
  • MoQ技術はWebRTC/HLS/RTMPなど既存のメディアプロトコルを置き換える潜在力を持つ
  • 標準草案やコードの課題に関する議論は今後も続くが、実運用の経験が標準の発展に大きく貢献すると見られる
  • 今後、MoQベースのメディア配信市場ではGoogle、Akamai、Fastlyなども自社ネットワークやサーバーにコードを展開し、実際に必要な要件を把握する必要がある

今後の計画とコミュニティ

  • 今後はWebRTCおよび既存プロトコルをWebベースの最新APIとして再実装するための多くの作業が残されている
  • 現段階の性能や機能だけでMoQ全体を評価すべきではなく、積極的なテストとフィードバックへの参加が必要
  • コミュニティ（Discord）には900人以上が参加しており、質問や協力の提案が可能

関連記事

1件のコメント

 
GN⁺ 2025-08-24
Hacker Newsのコメント

  • https://moq.dev/publish/ でデモを試してみたが、本当に滑らかに感じた。とても впечат象的だった。そして素晴らしい技術に感謝したい。https://moq.dev/watch/?name=bbb で Big Buck Bunny のデモをスマホで見ると、水平の黒い線がたくさん出る現象がある（なぜか同じWi‑Fiを使っているPCでは正常）。これがバッファサイズのせいなのか気になる。クライアント側でバッファを増やせるのか、それともサーバー側の設定なのか聞いてみたい。それと「グローバル」CDNマップで South Korea を入れ忘れていないことに感謝したい

    • これが Chrome でしか動かないのか気になる。Android Firefox では対応ブラウザではないというメッセージしか出ない

    • 水平の黒い線の現象についてはよくわからない。<canvas> 要素でレンダリングしてソース動画サイズに合わせてリサイズし、さらに CSS でウィンドウサイズに合わせてリサイズしている

    • OnePlus Ten で Chrome 再生すると、黒い線が頻繁に点滅する。特に画面上部から右下へ下がっていくように見え、もしかすると画面のリフレッシュ由来のアーティファクト（rolling shutter effect）かもしれない

    • ページでは Rust コードと WASM への言及が多いので、もしかするとスマホの CPU が WASM を十分速く実行できずに起きている問題かもしれない。自分の Samsung S20 では黒い線はまったく見えない

    • mac book air m4 と 600mbps 接続で試したが、反応が即座で驚いた

  • この記事には「なぜ気にするべきなのか？」というセクションがあるが、Media over QUIC がメディア配信者やエンドユーザー、つまりこのやり取りで最も重要な（おそらく唯一の）二者にどんな利益をもたらすのか説明がない。なので、なぜ自分がこの技術を気にするべきなのか知りたい

    • 私のミスだ。以前のブログ記事と重複する内容を避けようとして説明が足りなかった: https://moq.dev/blog/replacing-webrtc/ 。実際のところ MoQ は主に開発者に利益をもたらす技術だ。スケーラビリティや機能実装がずっと簡単になるので、利用者への利益は間接的なものになる

    • エンドツーエンド（glass-to-glass）の遅延がかなり改善する。主な理由は、プロトコルがもはや request/response 方式ではないからだ

  • こんにちは！Cloudflare MoQ の開発者です。質問歓迎です。それから賞をありがとうございます、kixelated xD

    • 「ヘッド・オブ・ライン・ブロッキングなし: TCP と違って QUIC のストリームは独立している。1つのストリーム（例: オーディオトラック）でパケット損失が起きても、別のトラック（例: ビデオトラック）は止まらない。RTMP で常に起きていた引っかかりがこれでなくなる」という説明があったが、この構造だとオーディオトラックでパケット損失が起きてもビデオトラックが止まらず再生され続けるなら、音声と映像の同期がずれることはないのだろうか。この点は技術に詳しくなく、理解不足かもしれない

    • 質問がある。TCP と QUIC の goodput の差を縮めるための具体的な計画があるのか気になる[1]。リンク先の論文では、HTTP/2(TCP) から HTTP/3(QUIC) に移行した際、最大 9.8% の動画ビットレート低下が見られたという。もちろん MoQ はスタック構造が少し違うので直接一般化は難しいが、似た問題はありそうだ。（個人的にはここ数か月、修士論文の一環として MsQuic の AF_XDP datapath を調べていた。結論としては GSO/GRO の方がより良い代替で、QUIC にはハードウェアオフロードが確実にもっと必要だと感じた :p）
      [1]: https://arxiv.org/pdf/2310.09423

    • いくつか気になる点がある :)
      QUIC がブラウザで実際に使える段階（ブラウザとインフラの両方が対応し、「普通に動く」レベル）にどれくらい近づいているのか知りたい
      それと QUIC は NAT 問題をどう解決するのか気になる。WebRTC では full cone NAT を越えるために STUN/TURN が必須で、特に TURN が問題だ。かなりのインフラを回さないといけないから

    • getstream.io で WebRTC ストリーミングに取り組んでいる。WebRTC はセットアップがやや面倒だが、接続できれば低遅延が利点だ。MoQ も接続完了後にどんな利点や課題があるのか、つまり WebRTC と比べてどう感じるのか気になる

    • リレーのロードバランシングは MoQ の範囲外なのだろうか。記事ではこの部分に触れられていないように思う

  • このプロジェクトが大好きで、時々 kixelated のブログも読み、Github でもフォローしている。
    まず、こんなに素晴らしい仕事をした kixelated と Cloudflare の両方にお祝いを伝えたい。
    リアルタイムのライブストリーミングが気になる。通常ライブ配信は何百人、何千人が同時に視聴するが、MoQ で multicast を使う、あるいは実装する考えや可能性があるのか知りたい。HTTP/1.1 や HTTP/2 では TCP ベースなので難しかったが、HTTP/3 では UDP を使うので現実的なアイデアになったように思う。どう考えているのか気になる。Akamai と BBC でもこの点を研究していると認識している

    • ありがとう！
      multicast は不要だ！CDN は実際のところ、L7（アプリケーション層）で multicast を実装したものとほぼ同じだ。ルーターや ISP が L3 でこれを直接実装する必要はない。これこそ Twitch で5年間、自分がやっていた仕事だ
      理論上、multicast は CDN エッジから ISP へのトラフィックを減らすだけだが、これは年に一度の超巨大配信（例: Super Bowl）でしか意味がなく、大半のイベントには効果がない。多くの CDN はすでに CDN エッジを ISP 内部に設置してこの問題を解決しており、小規模イベントでは2人の視聴者が同じ経路を共有する確率が低いため利点がない
      multicast には輻輳制御や暗号化など別の問題もあり、しかもこれは連合構造の multicast なのでさらに難しい
      multicast が最も恩恵をもたらすのは P2P だが、巨大な CDN エコシステムでは採用が難しいと思う
      WebRTC も multicast に最も適しており、RTP（もともと multicast 用に設計）も使っているが、実際には multicast 対応に関心が持たれていない
      ただし、Google が自社ネットワーク内の Meet サービスに multicast を使っているという噂もあるので、絶対にないとは言えない

  • 「just announced」のリンクは、これが何なのかまったく知らない人にもとても良い: https://blog.cloudflare.com/moq/ （自分も最初は見落とした）

    • 「放送規模でサブ秒の超低遅延（sub-second latency at broadcast scale）」、でも実際の multicast はない

    • 「単なる別のプロトコルではなく、新しい設計思想だ」という文句を見て、AI 検知レーダーが反応した

  • MOQ がフェイルバック時の解像度と graceful degradation をどう扱うのか気になる。それと zed で全画面にしても画面いっぱいにならない問題もある

  • Firefox ユーザーで、Cloudflare がホスティングしていて HTTP/3 を使うサイトを訪れたことがあるなら、参考までに共有したい:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1979683

    • happy eyeballs の問題かもしれないように見える？もっと詳しい人たちに伝えてみるつもりだ

    • ブラウザ内の DNS over HTTPS（DoH）リゾルバを使っているか知りたい。個人的にはこの現象を再現できていない。1.1.1.1 で DoH を使っている
      Chrome と Firefox の両方で、システム DNS の代わりに DoH リゾルバを使うと HTTP/3 の利用がより安定するように感じた。システムリゾルバを使うと HTTPS DNS レコードを安定して（あるいは全く）取得できないことが多く、
      HTTP/3 のサーバー対応は HTTPS DNS レコード、または以前の HTTP/2/1.1 でキャッシュされた Alt-Svc ヘッダーのどちらかでブラウザに通知されないと動作しない。しかも既存接続を再利用する傾向があり、新しい接続をあまり張らない
      Alt-Svc ヘッダーも、特に Firefox では安定してキャッシュされない
      さらに状況を複雑にしているのは、ブラウザが（特に Chrome）接続失敗が一定数たまると HTTP/3 対応を完全に無効にしてしまうことだ。自分が大学の Wi‑Fi を使っていたとき、UDP トラフィックが頻繁に（不規則に）遮断されてその現象が起き、その後は自宅でも HTTP/3 が使えなくなった。解決策は chrome://flags に行って QUIC 対応を手動で有効にすることだけだった。見た目では「enabled by default」と表示されていても、実際のブラウザ状態は違うことがある。Firefox も同様に HTTP/3 を諦めることがあるが、Chrome ほど頑固ではなく大きな問題にはならなかった
      さらにデバッグしたいなら、EncryptedClientHello（ECH）が動いているか https://tls-ech.dev で確認するとよい。これは ECH キーのためだけに HTTPS レコードを使うので、問題の切り分けになる。
      次に Fastly の HTTP/3 チェック（https://http3.is）で Alt-Svc ネゴシエーションだけを使っているか確認できる。
      Cloudflare のテストページ（https://cloudflare-quic.com）は HTTPS DNS レコードと Alt-Svc の両方を使うので、すぐに HTTP/3 でつながるなら HTTPS レコード解決がうまく動いているということだ
      テスト結果を教えてもらえるとうれしい。Firefox の問題が全員で一貫していないのは、こうしたさまざまな変数があるからだ
      （Cloudflare の人に伝えたいのだが、https://cloudflare-quic.com/favicon.ico は何か設定がおかしい。それと https://web.archive.org/web/20230424015350im_/https://www.cloudflare.com/img//nav/globe-lang-select-dark.svg の画像を Wayback Machine から読み込んでいてページ表示が遅くなっているが、images は id_ リンクを使えば rewrite されず、もっと速くなる。以前 Cloudflare Workers と組み合わせて、サーバー移行失敗時にサイトを一時的に復旧させるのに使えた。または単に https://www.cloudflare.com/img/nav/globe-lang-select-dark.svg の元URLを使えばよい。今のサイトでもまだ生きているファイルだ）
      ここ数年、HTTP/3 のさまざまな奇妙な実装やデプロイ上の問題をひたすら試してきた。素晴らしいプロトコルだが、奇妙で独特な実装・展開上の問題が数多くある

    • macOS 限定なのか気になる。Windows の FF 141、142 では再現しない

  • 本当にすごい！努力に感心した。最初は QUIC CDN と読んで「まさか」と思ったが、Media over QUIC が別の概念だと詳しく見ていくとかなり興味深い

  • 最初のアプリが面白かった。Show HN に投稿してみると良いと思う。ライブ動画プラットフォームで働いたことがあるが、MoQ はもう一度この開発をやってみたいと思うほど十分に魅力的だ

    • 近いうちに投稿する予定だ。ただ、もう少し直したい部分を手直しする時間も必要だ

  • 「技術が内部で動いてくれるなら」主要ブラウザ対応さえあれば構わないと思う（caniuse に情報も見当たらない）。
    そして Microsoft Edge WebView2 のような WebView エンジンでも対応するなら、すぐに開発へ適用できそうだと感じる。
    ただ逆に、OBS や YouTube のような側が対応しないと実際には意味がないとも思う

    • そういう意味では、MoQ は WebRTC のような1つの大きな「ブラックボックス」Web API から少し離れる方向に進んでいる。ブラウザ視点では WebTransport API 対応が鍵になる。
      WebTransport と MoQT を使えば、たとえば映像プレーヤーとして WebCodecs のような新しいやり方がいくつもある。少し遅延を許容するなら MSE で再生しつつ DRM も適用できる
      それから OBS から直接パブリッシュできるようにする作業は Cloudflare に来る前から進めていたが、これは「ストリーミングフォーマット」層でメディア関連の細部をどう実装するかにかなり依存する。業界ではまだこの層の仕様が継続的に発展中で、現時点では WARP が主導的な仕様だ。WARP 仕様が徐々に定着するにつれて、OBS などにもこの機能が組み込まれるかもしれない。現時点でも Norsk（https://norsk.video/）を通じて、fMP4 ベースの予備フォーマットで動画をパブリッシュできる
      YouTube については、Google に MoQT に積極的に貢献している人たちがいるが、これが YouTube 製品にいつどのように適用されるかは、自分には判断できない

    • https://caniuse.com/webtransport
      https://caniuse.com/webcodecs
      実際には WebCodecs は必須ではなく、MSE でレンダリングすることもできるが、より厄介で遅延も長くなる。
      Safari 対応のために WebSocket フォールバックと WASM ベースの OPUS エンコーダを作業中だ