Media over Quic についてすでに知っている読者の 5% にとって、あなたはこの問題について自分の意見を持っていることはほぼ確実なので、記事を飛び越えてコメントに直接飛び込んで私が間違っている理由を説明してください。 残りの95%は、おそらく今このように感じているでしょう。 心配しないでください友人たち、私たちはQuic、どのようにメディアを送信するか、そしてそれがどのようにRTCをWebに置くかとは異なります。 WebRTCとは? まず、WebRTCについての迅速なレビューをしましょう。 WebRTC は、ウェブ上のほとんどのビデオ会議アプリケーションの背後にある API です。 これを説明するには、ウェビナーのアプリケーションを検討してください: Webinar Appを作ろう ウェブセミナーをホストするためのウェブアプリケーションを構築したいとします。ウェブセミナーのビデオとオーディオを共有できるホストが必要です。 あなたはまた、参加者がホストからそれらのビデオストリームを消費することができ、質問や一般的なインタラクティビティのために自分のウェブカメラのビデオとオーディオを共有する可能性があります。 WebRTCがウェビナーを可能にする方法 WebRTC アプリを構築するための標準的なソリューションは、主にビデオ会議アプリケーションを容易にするために設計された Web API である WebRTC を使用することです。 選択送信ユニット 各参加者はサーバーへの接続を開き、独自のローカルカメラストリームを取得し、サーバーと交渉し、コーデックの選択、ビットレートなどを調整し、サーバーからストリームを放送し、サブスクリプションを開始します。 コードでは、このように見えます: // SFU WebRTC: Single connection to server async function joinWebinar() { // 1. Get your webcam const localStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); // 2. Create ONE peer connection (to the server, not to each participant) const peerConnection = new RTCPeerConnection({ iceServers: [{ urls: ['stun:stun.example.com'] } }); // 3. Add your local stream to the connection for (let track of localStream.getTracks()) { peerConnection.addTrack(track, localStream); } // 4. Exchange connection details with the server const offer = await peerConnection.createOffer(); const answer = await signalingServer.send({ offer }); await peerConnection.setLocalDescription(offer); await peerConnection.setRemoteDescription(answer); // 5. When the server sends you other participants' streams, display them peerConnection.ontrack = (event) => { const participantId = event.streams[0].id; displayRemoteVideo(participantId, event.streams[0]); }; } WebRTCサーバー サーバーは参加者間の接続を調整するだけでなく、参加者間のストリームの選択的な転送も可能にします。 100人の参加者を含むウェブセミナーの場合、これは、各参加者がウェブサイトのストリームを99回異なる時間に共有していないことを意味し、サーバーに1つのストリームをアップロードするだけで、すべての人に転送されます。 100人の参加者のそれぞれが99の他のビデオフィードにサブスクリプトする必要はありませんが、アプリケーションはビジネスロジックを適用し、各参加者は利用可能なフィードのサブセットにのみサブスクリプトできます(たぶん誰もがホストのウェブカメラとスクリーンシェア、および5人のランダムな他の参加者のフィードを取得します)、すべての人の帯域幅を減らします。 WebRTC 実践 WebRTCは、ウェブセミナーの例のようなビデオ会議および隣接的な使用ケースのために構築されたため、AndroidやiOSなどのブラウザ以外のプラットフォームでもリアルタイムのビデオ交換を行うためのデファクトな方法となっています。 WebRTCの主な課題は、 Scalability - Server-side forwarding of many simultaneous video streams requires significant CPU and bandwidth, making it increasingly expensive to scale beyond a certain point (usually thousands) Control - WebRTC was built primarily with video conferencing in mind, and so while it is highly optimized for that use case, it lacks fine-grained control over media encoding & delivery (codecs, strings, packet-level control) that are relevant in other use cases like remote control or AI video pipelines. Media over Quicとは? Media over Quic (MoQ) は、WebRTC のようなリアルタイムのビデオをストリーミングするための新しいプロトコルです。 さて、もしWebRTCがすでに存在し、うまく機能しているのなら、なぜ企業が そして 新たなプロトコルに取り組むことの突然のすべて? クラウドフレア 目標 まずはQuicについてお話ししましょう。 ウェブ開発者として取り組むことのできる通常のセーバーコミュニケーションのほとんどは、接続を確立するためにネットワークとサーバー間でいくつかのバックアップステップを伴う HTTPS リクエストの形を取ります。 これらの HTTP リクエストと Websockets や WebRTC などの API は、ネットワークとサーバー間でデータを交換するプロトコルである TCP と呼ばれるプロトコルを使用し、パッケージが順番に送信されます。 パッケージが失われた場合、次のパッケージが維持され、これは秩序を維持するが、「ヘッド・オブ・ライン・ブロック」につながる可能性がある。 QUICは代替プロトコルであり、スピードを優先する高速クーリーターのように機能し、重要なパッケージ(ビデオフレームのように)を落とすことができますが、配送の残りをより速く受け取ることを意味します。 QUICと通常のTCP/HTTPの違い QUIC 接続にはより少ないセットアップが必要です。 QUICは、全体の接続を遅らせる代わりに、個々のパッケージをスマートに落とすことができます。 QUIC は、WIFI からモバイル接続への切り替えなど、ネットワーク間を切り替えるときに接続を維持できます。 したがって、QUICは、ビデオストリーミングに特に適した有用なネットワークプロトコルですが、理論的にはQUICを通じてデータを送信することができます。 すでに持っているので、QUIC、それについていくつかのメディアを送ろう Media over Quic のアイデアは、あなたがすでに推測したように、Quic 接続を介してメディアを送信することです。 具体的には、Media over Quic は QUIC の上に公式化されたプロトコルです。 Media over Quic は pub/sub システムとして機能し、 コードされたメディアのストリームをAに送信する (基本的にはCDN)と、 これらの流れをリレーから受信してください: publisher relay subscribers Media over Quic relays are content-agnostic, they don't know what's going across the network, whether it's video, audio, text or just random binary code. 彼らはまた、それが暗号化されているか否かについての可視性を持っていない。 もう一つの重要な側面は、Media over Quic レレイヤーを連鎖することができるため、一部のサブスクリプトは 1 つのレイヤーのみを通過したデータを受け取ることができ、他の人は 5 つのレイヤーを通過したデータを受け取ることができます。 Media over Quic レレイヤーは、全体的な「放送」の状態を維持する必要もなく、データパイプとして機能するだけで、出版社やサブスクリプトの数やセッションがどのくらいの期間にわたってアクティブであるかを知らない。 これらは、Media over Quic が実行されることを可能にする主要な機能です。 同時に何百万人もの視聴者にリアルタイムのストリーミングを可能にし、WebRTCでは不可能である。 CDN Pseudocodeの例 ストリームを見るには、It Media over Quicはこんな感じに見えます。 async function watchWebinarViaQuic() { // 1. Connect to the relay const connection = await Moq.connect("https://relay.moq.some-cdn.com"); // 2. Subscribe to the broadcast const broadcast = connection.consume("my-webinar"); // 3. Subscribe to the video and audio tracks const videoTrack = await broadcast.subscribe("video"); const audioTrack = await broadcast.subscribe("audio"); // 4. Decode and display/play the streams decodeAndDisplayVideo(videoTrack); decodeAndPlayAudio(audioTrack); } ストリームを放送するには、こんな感じになるでしょう: async function joinWebinarViaQuic() { // 1. Get your webcam const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true }); const videoTrack = stream.getVideoTracks()[0]; const audioTrack = stream.getAudioTracks()[0]; // 2. Connect to a MoQ relay (instead of connecting to an SFU) const connection = await Moq.connect("https://relay.moq.some-cdn.com"); // 3. Create a broadcast (namespace for your streams) const broadcast = new Moq.Broadcast(); connection.publish("my-webinar", broadcast); // 4. Get video and audio tracks from the relay const videoMoqTrack = await broadcast.requested('video'); const audioMoqTrack = await broadcast.requested('audio'); // 5. Stream your camera to the relay encodeAndStreamVideo(videoTrack, videoMoqTrack); encodeAndStreamAudio(audioTrack, audioMoqTrack); } 実際には、ビデオを暗号化/デコードし、表示するには、まったく別のことを意味します。 しかし、そこにはまた、 こういう扱い・・・ ウェブコード 図書館 ストリーム vs コネクション WebRTC と Media over Quic の基本的なアーキテクチャの違いは、WebRTC は一連のアクティブなステータフな接続として動作する一方、MoQ は一連の独立した並行ストリームとして動作するという点です。 WebRTC では、接続は本質的に二方向性(同僚間またはクライアントからサーバーへの接続)で、MoQ では並行して独立した一方向性のストリームで動作します。 なんでMOCなの? 多くの企業や開発者は、WebRTC(および他のウェブビデオテクノロジー)に比べて具体的な利点があるため、MoQに興奮しています。 MoQ は、ビデオ会議ソフトウェアと同じようなリアルタイムのビデオ体験を提供することができますが、ストリームが CDN 経由で送信されているため、ウェブカメラを持つ 1 人が何百万人もの人々にストリーミングすることができます。 Scale: QUICは、より信頼性の高いストリーミングを可能にし、ネットワーク(例えばモバイルからWIFI)を切り替える場合でも接続が続くことを可能にし、リアルタイムの配信を確保するためにフレーム/パケットを落とすことも可能にします。 Efficient transport インフラストラクチャモデルは非常に単純であるため、ネットワークステックを大幅に簡素化すると同時に、いくつかのアプリケーションにとって重要なビデオエンコーディングとデコーディングに対するより低レベルのコントロールを提供します。 Simple model Quic in Practiceについて 2026年1月時点で、Media over Quicはまだ非常に初期段階にあり、まだ開発中のいくつかのコンポーネントに依存しています。 WebTransport - QUIC接続を可能にするWebAPIは、ブラウザの80%でサポートされていますが、Safariではまだサポートされていません。 ライブラリ: Media over Quic のコアライブラリは、Rust (サーバー) および JS (クライアント) のみに存在し、モバイル SDK はまだありません。 リレー:複数の CDN プロバイダーが MoQ リレーを作成しており、Cloudflare にはすでにリレーがありますが、まだ「ベータ」にあり、現在最も信頼できる方法は独自のホスティングです。 Media over Quic には、初期の採用者にとっては十分なツールとサポートがありますが、まだ多くの「DIY」の調整と実装が必要であり、シームレスな開発者体験にはまだ早すぎます。 開発者(私を含む!)はQuicを介してメディアのコアライブラリに取り組んでおり、企業はレレイヤー/ホストソリューションを開発しているので、MoQは今後数カ月/数年でより安定し、生産が完了することを期待しています。 WebRTCを置き換えるのか? リアルタイムのビデオ空間の人々にとって、Media over Quicは熱い話題であり、Media over QuicがWebRTCを置き換えるかどうかについて多くの議論が行われています。 この記事に来る前に読者の5%はすでにMoQについて知っていたので、おそらくあなたはすでにこの記事に答えのいくつかの意見を持って来たので、コメントまたはあなたの反論を投稿してください、私はSEOを使用することができます。 あなたがこのレースで馬を持っていないかもしれないが、とにかく、あなたがウェブ開発で働いている場合、それはおそらくMoQに気付くことは良いことであり、それはリアルタイムメディアストリーミングの新しいスタンダードであることを指摘したい。 私がMoQライブラリの開発を手伝い始めたのは、WebRTCを置き換えたいという興味や願望があるからではなく、むしろ好きだからです。 そして、低レベルのコントロール、そして新しいプロトコルの地下階に到達することは素晴らしいことだ。それで言えば、私の最も近いプロフェッショナルな連絡先のいくつかはWebRTCの専門家です(私は以前、プロトコルを運営していました。 AIがWebRTC製品をターゲットにしたSDKをフィルターしている)と、開発者として、MoQのドキュメンタリーを見ると、まだ未だに原始的で、広範囲に使用するには早すぎていることが明らかです。 ウェブコード スタート WebRTCを置き換えるのか? たぶん WebRTCは確立されたエコシステムを持っており、以前は良いソリューションを持っていなかった問題を解決しました。WebRTCとは異なり、MoQは「何も」と競い合うのではなく、確立された、よくサポートされているプロトコルと競い合っています。 したがって、MoQはWebRTCやその他のストリーミングテクノロジーに比べて実際の利点を持っています。 したがって、以下は、MoQの利点が初期の採用者にとって説得力のあるケースである可能性のあるいくつかの用例です。 HLS/DASH ストリーミング Too big for WebRTC, to small for HLS/DASH 初期の採用者のための甘い場所は、WebRTCやHLS/DASHによってよくサービスされていないアプリケーションカテゴリである可能性があります(リアルタイムではありませんが、特に高いスケールです)。 いくつかの例が含まれるかもしれない: Webinar ソフトウェアは、ウェビナーにリアルタイムのインタラクティビティが必要ですが、数千人または数万人の参加者に拡大する必要があります。 通常、スピーカーが少数=>多くをストリーミングする仮想イベントを放送するが、しばしばインタラクティブなQ&Aを含む。 ブラウザベースのライブストリーミングツールは、ブラウザからサーバーや他の参加者にビデオをストリーミングし、Facebook LikeやYouTubeのようなソーシャルメディアプラットフォームを同時にストリーミングします。 More control and reliability than WebRTC Media over Quicは、強力なビデオ接続やビデオ配信の低レベルの制御が必要なシナリオ、例えばリモートカメラフィード(セキュリティカメラ、ドローン、リモートコントロールされた車両)やリアルタイムAIビデオパイプラインなどのシナリオでも役立ちます。 WebRTC はこれらのシナリオで頻繁に使用されますが、これらの場合、MoQ のスケール エフェクトは無関係であり、主な利点は HTTP3/Quic のより強力な接続性と低レベルのフレームコントロールで、MoQ を魅力的なオプションにします。 For everything else 他のすべてのもののために、そこには WebRTCです。 マスターカード あなたが標準のクッキーカッタービデオ会議を構築している場合、WebRTCは明らかにより良いテクノロジーであり、MoQが有意義な場合がある可能性はなく、MoQエコシステムがWebRTCの安定性と成熟度のレベルに達するまで(可能か?しかし、それでさえ、それはしばらくかかるかもしれません)。 より多くの資源 Media over Quic、WebRTC、または一般にリアルタイムのメディアストリーミングについて興味がある場合は、以下にいくつかのリソースがあります。 Media over Quic あなたがQuicでメディアについてもっと知りたい場合は、より深く掘り下げることができます。 MoQの公式サイト WebCodecsFundamentals、コード例を含むオープンソースの教科書 MOQ DISCORD WebRTC WebRTCについての多くのチュートリアルがあります( で、 ) また、他の WebRTC 専門家が MoQ vs WebRTC について話しているのを聞くこともできます。 また、WebRTC開発者のための素晴らしい discord コミュニティも存在します。 . ウェブサイト.dev MDN ウェブチャック ピオン
