こんにちは、getstream.ioでWebRTCストリーミングの仕事をしています。WebRTCは設定が面倒なんですよね。でも、接続が完了すると低遅延を提供してくれます。接続設定が終わった後のMoQの比較についてどう思いますか？何か利点や問題点はありますか？

こんにちは！いくつか質問があります :) QUICが実際にブラウザで使えるようになるのはどれくらい近いですか？（つまり、ブラウザとインフラの両方がサポートしていて、"ただ動く"状態）QUICはNATの問題をどう回避しますか？WebRTCはフルコーンNATを通過するためにSTUN/TURNが必要ですが、特に後者は運用に多くのインフラが必要なので問題です。

ヘッド・オブ・ラインブロッキングがない：TCPのように、1つのパケットが失われるとその後ろのすべてがブロックされるのとは違って、QUICのストリームは独立しています。1つのストリーム（例えば音声トラック）でパケットが失われても、別のストリーム（例えばメインのビデオトラック）はブロックされません。この点だけでも、RTMPの悩みの種だったスタッタリングを排除します。これらの技術にあまり詳しくないので見逃しているかもしれませんが、音声トラックでパケットが失われた場合、ビデオトラックがブロックされずに再生を続けると、どうやって音声とビデオの同期が取れるのですか？

リレーの負荷分散は範囲外なの？書いてある内容には触れられてない気がするけど、見落としたかな。

こんにちは、質問があるんだけど。あなたのチームは、TCPとQUICの良好なスループットに関して具体的な計画を持ってる？リンク先の論文では、HTTP/2（TCP）からHTTP/3（QUIC）に移行することで、最大9.8%のビデオビットレートの削減が見られるって言ってるよね。もちろん、MoQは少し違うスタックに基づいているから、結果がそのまま当てはまるわけじゃないけど、問題は似てると思う。実はこの話、すごく興味深いんだ。最近、修士論文の一環でMsQuicのAF_XDPデータパスを調査してたから。結局、GSO/GROがより良い選択肢で、QUICはもっとハードウェアオフロードが必要だって結論に至ったよ :p

そうですね、もうすぐやりますが、他のことを直す時間にも使えるかもしれません。

そうですね…MoQはWebRTCのようなオールインワンの「ブラックボックス」から少し離れることを示しています。ブラウザの視点から見ると、重要なのはWebTransport APIです。MoQTをWebTransport APIと組み合わせて使うことで、例えばWebCodecsを使った動画プレイヤーのレンダリングの選択肢が増えます。でも、もう少し遅延を許容できるなら、再生のためにMSEのようなAPIを使ってDRMも利用できるようになります。OBSから配信できるのは、Cloudflareに入る前に取り組んでいたことですが、「ストリーミングフォーマット」層での作業に大きく依存します。そこにはメディアに関する詳細が詰まっています。その層はまだ進化中で、WARPが今のところリーディングスペックです。これがもっと固まってくると、OBSなどに組み込む意味が出てくるでしょう。今日の時点でも、Norsk（https://norsk.video/）を使って、WARPドラフトの初期バージョンに似た基本的なfMP4形式で動画を公開できます。YouTubeに関しては、GoogleにはMoQTに非常に積極的に貢献している人たちがいますが、彼らがYouTubeのような製品にいつ、どのように展開する予定なのかは正確にはわかりません。

https://caniuse.com/webtransport https://caniuse.com/webcodecs 技術的にはWebCodecsは必須じゃないけど、MSEを使って描画することもできる。ただ、その場合は手間がかかって遅延も大きくなる。Safariをサポートするために、WebSocketのフォールバックとWASMでのOPUSエンコーダーに取り組んでる。