Cloubhouse はすでに OSS である Janus Gateway に切り替えており Agora は使用していないようです

ライセンス

Creative Commons — 表示 - 非営利 - 改変禁止 4.0 国際 — CC BY-NC-ND 4.0

前提

ざっくりと雑に解説。

どんな技術を使っていてこんな感じだろうという妄想は以下をどうぞ。

Clubhouse リアルタイム配信の仕組みについて (妄想編)

著者

• 商用 WebRTC SFU 開発者
• WebRTC プロトコルスタック実装者
• End to End Encryption プロトコルスタック実装者

Clubhouse の仕組みはとてもシンプルで配信者が N 人で、それを数千人が聞くという co-streaming と呼ばれる仕組みの一つ。この方式は今までは主に映像ありでパネルディスカッション的な使い方が主だっだ。それを誰もが配信者になれ、途中で誰もが参加できるという仕組みを音声のみに絞るというのに落とし込んで提供している。

そもそも N 人が双方向配信しているものを数千人が片方向で配信するというのは「話者が固定している」というのが一般的で、突然視聴者側から配信社側へ参加して多くの配信者がが生まれるというのは誰もが使えるサービスというのでは今まであまりない世界だったと思う。

大手企業のテレビ会議的な物ではよくあり、部署の会議とかであれば偉い人＋話者、後は聞いてるだけ。途中参加ありみたいな感じだった。これを一般的な世界に持ってきたのが ClubHouse という認識。

双方向＋片方向という組み合わせは実は映像ありだと I フレーム要求問題が発生する。途中参加者のために全配信者が I フレームを発行しなければならないからだ。

Clubhouse はこれを音声のみに絞ることで、途中参加しても配信者の負荷が一切上がらなくなっている。これに言及している記事が一切見られなかったのが不思議でならない。

蛇足

よく勘違いされているのだがリアルタイム通信での I フレーム間隔だが WebRTC では 90 秒ととても長かったりする。長ければ長いほどクライアントとネットワークに優しくなるためだ。

音声のみに絞ったことで転送量も減らせる。WebRTC を含めたブラウザを考慮すると Opus がメインにサンプリングレート48 kHz になってしまうが、 Clubhouse はモバイルアプリに限定されているため、このあたりも自由にいじれる。32 kHz に下げたって問題ないだろう。ブラウザを諦めるということは、技術的にやりたい放題できるということでもある。

実際 Opus 標準そのままかどうかは正直わからないが、自分だったら SDK 側でいろいろいじれるようにしてしまうと思う。SDK でプリセットとかを持って、それを利用するパターンが考えられる。

蛇足

ちなみに Discord も Opus を利用可能で、サーバをブーストすると超高音質な Opus が利用できるようになるというのはあまり知られていない。

視聴者側から配信者への切り替えだが、全く難しくない。再接続するときに配信者として接続するだけでいい。Clubhouse の場合はモデレータというのがいてそれの切り替えをする仕組みだが、SaaS 系にはよくある仕組みなので、これも珍しくない。

もちろん配信者から視聴者へ戻るのも難しくない。

なぜ視聴者への配信もリアルタイムなのかという話だが、これは途中参加を可能にしているのが理由だと思う。音声だけなので長くても 10 秒程度の遅延ですむと思うが、ぱっと切り替えるためにというのはありそう。

ただ、今後は MP4 (Opus) を CDN なプル型で配信というのはありえるだろう。技術的にも別に難しくない。そもそも配信社側に回らない人にとって遅延はほとんど気にならないからだ。

実はプッシュ型ははいろいろ用意しなくて良いという楽な面もあるので、そことのトレードオフになる。CDN 型にしてしまえば大規模が裁けるようになるので、まぁ今後もはやり続ければ CDN 型に切り替えてしまうだろう。

音質の向上の件だがモバイル側で何をするかによる。SDK 側にノイズキャンセルやエコキャンが入っていればまぁそれが効果を出る。マイクはスマホなのでよくできているマイクだと思っていい。もちろん専用マイクと比べてはいけないが。

スマホは電話機なのでマイクは本当にとてもよくできている事を皆忘れている。音がいいのはスマホのマイクが良いというパターンが多い。

音声の再送というのはほとんど行われず、FEC が利用されることが多い。Opus はデフォルトで FEC 機能が入っている。パケロス対策はこれがほぼ全てとなる。

より高音質で高ビットレートな場合は再送が効果を出す可能性もあるが、Opus のデフォルトビットレートは 32~64kbps のため、再送はあまり効果がない場合もある。

• How to enable in-band FEC for Opus codec
• Audio FEC Experimentation - Advancing WebRTC

録音はサーバ経由であクライアントとサーバ間での Hop by Hop 暗号を利用しているとみている。また、E2EE で守られているような挙動は今のところ画面上からは見て取れない。（それぞれの配信者の証明書のフィンガープリントなどが明示されていない）

そのためサーバ管理者は会話は録音可能であろう。何かあったときのために音声を録音しておくというのは不特定多数が利用するサービスとしては必要になる場合もあるので、そのあたりは利用規約に何か書いてある気がする。

Clubhouse の仕組みは複数配信者＋視聴者モデルに途中参加、そして音声のみ、さらにモバイルのみで絞ったという所だろう。UI/UX が優れていたという点などもあるのだろうがここでは割愛する。

Clubhouse のクローンを作るの実例もあるし難しくない。ただユーザを集め大規模に膨れたときのビジネスモデルをどうするのかという問題がついて回る。

この「誰もが配信できる」というサービスは転送量が天井知らずになるという問題があるためだ。SaaS を利用している場合は「転送量問題」というのが絶対に付いてくる。そのため誰もが自由に利用できる配信サービスは「自前で回線を用意する」や「転送量が定額なサーバを使う」といった選択肢を必ずとる。もしくは転送量が無料だとしても利益が出るようなくらいの何かビジネスモデルがあるか。

スケーラビリティの問題もある。Saas を使う場合は SaaS の性能に依存してしまうという問題もある。そのため Clubhouse は今は SaaS を利用しているが、今後は自前に切り替えていくだろう。

まとめ

• 難しい仕組みは一切使っていないので二番煎じは難しくない
• 音声のみに絞り負荷や転送量を下げて世界中で使われるサービスになったのは凄い
• 今後自前に切り替えたとき、他の追従が難しくなりそう