WebRTC はスケールしないという誤解
WebRTC について誤解している発表や記事が増えたので、よくある誤解について雑に書いておきます。
WebRTC はスケールしないという誤解
これ、よく言われるんですが、ブラウザで P2P でやりとりするために生まれた WebRTC だから「ブラウザ同士ではスケールしない」という話を、なぜか「サーバー経由でもスケールしない」とか「WebRTC の仕組み上スケールしない」という話になっていますが、完全な誤解です。
WebRTC はただの UDP ベースで音声、映像、データを送受信する仕組みでしかないので、スケールはあとはサーバーの仕事です。そもそもステートフルな仕組みなので、複数のサーバーで同じルームに入れるようにするに何かしらの仕組みが必要です。
WebRTC はこの部分は「サーバー実装」に任せている岳で、スケールしないわけではありません。そもそもただの送受信する仕組みなので、スケールは別の話です。
時雨堂では複数サーバーの状態管理には Raft を利用し、さらにサーバー間通信の効率化のために Plumtree を採用して、複数サーバーでのスケールアウトを実現できています。
さらに Raft や Plumtree の恩恵により、耐障害性も実現できています。これは別に WebRTC 意外でも利用できる汎用的な仕組みです。SRT や Media over QUIC でだって利用できます。
ステートフルなサーバーでスケールアウトかつ耐障害性を実現するの WebRTC 関係ありません。
時雨堂の WebRTC SFU Sora で実現している仕組み
WebRTC はバッファリングできないという誤解
これもよく言われるんですが、WebRTC には視聴者側でバッファリングする仕組みが何年も前から用意されています。Playout Delay という仕組みで、視聴側で好きなようにバッファリングすることができます。
左が配信、右上がバッファ 0 ms / 右下がバッファ 1000 ms
これは WebRTC の仕組みとして提供されているものです。これはちゃんと「視聴者単位」で指定できるので、回線が不安定な人はバッファリング多めなど全然できます。
WebRTC は再接続できないと言う誤解
これもよく言われるのですが、 WebRTC には ICE Restart という仕組みがあり、再接続というか経路変更ができます。
ICE Restart を利用する事で WebRTC を再度確立させることなく経路変更することが可能になります。
ここからは駄文ですが、そもそも WebRTC は多くの企業が採用し、10 年以上積み上げてきた仕組みなのでまぁまぁ穴が少ないです。さらに libwebrtc という Google が途方もないリソースをつぎ込んで作り込んできたライブラリもあります。
結局 Media over QUIC やそれ以外の新しい技術を採用する場合は libwebrtc と同レベルの仕組みを作り上げる必要があります。つまり Media over QUIC が実現しようとしていることはほぼほぼ WebRTC の二番煎じなんです。
時雨堂でも Media over QUIC への対応を少しずつ進めており、Google の Quiche ベースの MOQT ライブラリのビルドを公開したりもしています。
shiguredo-webrtc-build
MOQT はコーデック実装もデバイス実装も含まれていませんし、様々な便利な機能も一切ありません。全て 1 から用意する必要があります。帯域推定自体 QUIC ライブラリに依存するのがほとんどで、独自のチューニングは大変でしょう。
さらに MOQT は QUIC ベースなので TCP や TLS しか通らない仕組みを通すには over HTTP/2 の仕組みが必要になります。WebRTC は TURN で既に持っています。
そもそも Safari にはまだ WebTransport がテスト段階段階です。これは大きなハードルになると思います。
ただ、Media over QUIC が発展していくのはとても良い方向だとは思っています。なぜなら WebRTC は RTP や SCTP といった枯れている技術をベースにしており、今後の発展性はほぼないからです。とはいえやること自体は山ほどありますが ... 。
蛇足
時雨堂としては Sora に Media over QUIC の口を追加するだけで普通にスケールアウトする Media over QUIC サーバーを持つ事ができるので、特に Media over QUIC のスケールアウトについては全く心配していません。Erlang/OTP + Raft + Plumtree という汎用的な仕組みを持っているのは本当に強いです。それも商用環境で安定して稼働しています。
自分が懸念しているのは libwebrtc のような仕組みがないことです。libwebrtc という存在が WebRTC をここまで広めたのは間違いないからです。
そこで、時雨堂ではGoogle の MOQT のビルドをベースにして、moq-cli という音声や映像のハードウェアアクセラレーターを利用して映像や音声を送受信する仕組みを準備しています。結局、配信系はクライアント、特にブラウザ以外が大事だと考えています。ブラウザ部分はそもそもブラウザが提供している以上の事をしようとすると Wasm ベースで踏ん張るだけなので、難しい話ではありません。
今のところ moq-cli を公開した後、moqt-py と Python から利用できる C++ ベースのライブラリを公開予定です。また webcodecs-py という WebCodecs API にできるだけ寄せたハードウェアアクセラレーター対応のライブラリも絶賛開発中です。 moqt-py と webcodecs-py を組み合わせて Python で気軽に音声や映像などを取り扱える仕組みを用意したいと考えています。