こんにちは、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エンコーダーに取り組んでる。

macOS限定？WindowsのFF 141と142では再現しないよ。

ハッピーアイボールズの問題かも？詳しい人に伝えてみるね、ありがとう。

うーん…ブラウザ内でDNS over HTTPSリゾルバを有効にしてる？私はこれを再現できないけど、1.1.1.1でDoHを使ってるんだ。システムDNSを使うと、ChromeもFirefoxもHTTP/3の使用が一貫しないことが多い気がする。ブラウザがHTTPS DNSレコードを一貫して取得できないことが多いから、システムリゾルバを使うと問題が起きるんだよね。サーバーのHTTP/3サポートは、HTTPS DNSレコードか、前回成功したHTTP/2またはHTTP/1.1接続からのキャッシュされたAlt-Svcヘッダーで広告されなきゃいけないし、ブラウザは新しい接続を開くよりも、既にオープンしている接続を再利用することを好むから、HTTP/3を使うのがすごく難しくなることがあるんだ。（Alt-Svcヘッダーも、特にFirefoxでは一貫してキャッシュされないことがあるよ。）さらに厄介なのは、ブラウザ、特にChromeが接続が頻繁に失敗すると自動的にHTTP/3サポートを無効にすることがあるんだ。大学のWi-Fiをよく使ってたときにこれが起こったんだけど、UDPトラフィックの大きな（でも不安定な）量をブロックしてるみたい。Chromeがこの状態に入ると、HTTP/3の使用を完全にやめちゃって、開発者ツールでも理由がわからないんだ。（通常、開発者ツールのネットワークタブで「プロトコル」列を有効にすると、リストされたプロトコルにカーソルを合わせると、Chromeがどのようにそのプロトコルが最適な選択肢だと判断したかのツールチップが表示されるんだけど、この「強制無効」状態ではそのツールチップが表示されない。）イライラするのは、Chromeがこの状態を特定のネットワークに限定できないみたいで、突然自宅でもHTTP/3が使えなくなったこと。これを解決するには、about:flagsに行って（はい、今はchrome://flagsだって知ってるけど、気にしないで）QUICサポートのオプションを手動で有効にするしかないんだ。デフォルトで「有効」と表示されていても、ブラウザの実際の状態を反映してないことがあるから。Firefoxも同様にHTTP/3を諦めるけど、そのメカニズムはChromeよりも「粘着性」が少ないみたいで、一貫した問題は起きてないよ。さらにデバッグするには、まずEncryptedClientHelloが機能しているかどうかを確認してみて。https://tls-ech.devでテストできるよ。ECHはHTTPS DNSレコードのサポートが必要だから、それが機能していれば、あなたの設定がHTTPSレコードを解析できることを確認できる。次に、FastlyのHTTP/3チェッカーをhttps://http3.isで試してみて。これはAlt-Svcヘッダーだけを使って交渉するから、最初の読み込みは常にHTTP/2になるけど、ページをリフレッシュすれば成功したHTTP/3接続が得られるはず。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.cl...から画像を引っ張っているからで、本来は「id_」リンクを使うべきなんだ。そうすれば、インターネットアーカイブのサーバーが何かを再書き換えようとしなくて済むから、通常見られる遅延の原因になることが多いんだよ。（実際、数年前のサーバー移動の失敗時に、Cloudflare Workersとその機能を使ってサイト全体を一時的に復活させたことがあって、id_トリックを知った瞬間にうまくいったよ。）あるいは、そのアセットをhttps://www.cloudflare.com/img/nav/globe-lang-select-dark.sv...に戻してもいいよ。メインサイトでまだ生きてるから、Wayback Machineから引っ張る必要はないしね。）HTTP/3とその奇妙な特性について、過去数年でかなりの時間をかけて実験してきたんだ。素晴らしいプロトコルだけど、実装やデプロイに関しては奇妙で特異な問題がたくさんあるんだよね。

横の黒いライン？それが何かはわからないけど、ソース動画に合わせて要素をリサイズして、さらにウィンドウに合わせてCSSでリサイズしてるよ。

Android/Chromeでは黒いラインは出ないけど、フルスクリーンにするとアスペクト比を無視される。横に黒いバーを追加する代わりに、動画の上下が完全にカットされちゃう。

すごい、めっちゃ早くストリーミング始まるじゃん！ WTF

これってChromeだけなの？AndroidのFirefoxだと「ブラウザサポートなし」って出るんだけど :(

MacBook Air M4で600Mbpsの接続だと、瞬時にすごくいい感じだよ。

ページにはたくさんのRustコードとWASMが書かれてるね。もしかして、君のスマホのCPUがWASMを速く処理できないのかも？僕のSamsung S20では黒い線は全然出ないよ。

OnePlus TenのChromeで、黒い線が頻繁にちらつくんだ。上の方から右下に向かって出てくるのを見ると、リフレッシュのアーティファクトかもしれないな。ローリングシャッター効果みたいな感じだよ。

ごめん、前のブログ記事を繰り返さないように頑張りすぎたかも。https://moq.dev/blog/replacing-webrtc/ それに、君の言う通り、MoQは主に開発者に利益をもたらすもので、エンドユーザーにはあまり関係ないんだよね。機能をスケールさせたり実装したりするのがすごく楽になるから、間接的な利益があるって感じ。

エンドツーエンド（ガラスからガラスまで）のレイテンシーがかなり良くなったね。主にプロトコルがリクエスト/レスポンスじゃなくなったからだよ。

ただの別のプロトコルじゃない；新しいデザイン哲学だ。 これにはAIセンサーが反応した…

放送規模でのサブ秒レイテンシー でも、実際のマルチキャストはないんだよね。

ありがとう！マルチキャストは必要ないよ！CDNは実質的にマルチキャストを実装していて、L7でキャッシュを使ってるから、ルーターやISPにL3で実装させる必要がないんだ。実際、僕もTwitchで5年間それをやってたよ。理論的には、マルチキャストはCDNのエッジからISPへのトラフィックを減らせるかもしれないけど、年に一度の大規模な放送（例：スーパーボウル）だけだね。多くのCDNは、ISP内にCDNエッジを置くことでこれを回避してる。小規模なイベントは、同じ経路を共有する視聴者が少ないから恩恵を受けないんだ。他にもマルチキャストには混雑制御や暗号化の問題があるけど、解決できないわけじゃない。ただ、マルチキャストの連携的な性質が修正を難しくしてる。マルチキャストはP2Pに最も恩恵をもたらすけど、CDNがこんなに大きくなっちゃったから、普及するとは思えないな。マルチキャストから恩恵を受けるはずのWebRTCも、RTP（マルチキャストを考慮して設計された）を使ってるのに、サポートに興味を示してないみたい。でも、Googleが自社のネットワーク内でMeetにマルチキャストを使ってるって噂は聞いたことがあるから、もしかしたらね？