GSoC 2025に採択された（Jitsi）

2025-05-09 Computer

2025年のGoogle Summer of Codeに採択されました。今年の夏はオープンソースのビデオ会議ツールであるJitsiに貢献していきます。

gsoc project overview

プロポーザル

後述するように今回プロポーザルを書くにあたって大量の先人のブログとプロポーザルを参考にしました。というわけで僕もプロポーザルを晒します。

Audio Switchboard API Proposal

実は提出後に色々実装方針が変わり、メンターとも話した結果、このプロポーザルに書いてあることのうちそのまま実装されるのは半分くらいになりそうです。

何をやるのか

Jitsiにて「Audio Switchboard API」の開発を行います。

現状Jitsiでは、映像ソースについてはとても柔軟なフィルタリング機構が存在します。JitsiのSFUサーバー（Videobrdigeと呼ばれる）は会議の各参加者について帯域を予測し、転送する映像をフィルタリングします。受信側はフィルターのパラメーターとして上限ソース数、特定のソースID、解像度などを指定することで、「この参加者の高解像度の映像を見たい」「ギャラリービューのために全参加者の低解像度の映像が欲しい」といった状況に柔軟に対応することができます。

一方、音声については基本的にフィルタリング機構がありません。これは映像と比較して音声ソースは帯域をそこまで消費しないこと、映像ほど細かな品質の分割がない（サイマルキャストのようなものはない）ことが理由として挙げられますが、例えばブレイクアウトルームや翻訳機能などを実装する際に、音声をフィルタリングする機能が必要になってきます。

というわけで今夏、僕が音声のフィルタリングを実装します。音声のフィルタリングは今後追加されうる機能への布石であり、映像のフィルタリングのように帯域消費を抑えることが目的ではありません。つまり映像のそれとは全く異なる仕組みを作る必要があるのです。

Audio Switchboard API

Jitsiにおいて、ブリッジサーバーとクライアントのメッセージングにはCOLIBRIなるプロトコルが使われており、このAudio Switchboard APIでもこれを用います。

audio switchboard's sequence

まず、音声ソースにメタデータを付加し、それをもとにブリッジサーバー側でフィルタリングを行う仕組みが導入されます。送信者（sender）はソースに対して例えば「言語」や「ブレイクアウトルームID」といったメタデータを付けて送信し、それを SourceAudioMetadata としてブリッジに送ります。一方、受信者（receiver）は ReceiverAudioSubscription という新しいメッセージをブリッジに送信し、自身が受け取りたい音声ソースのメタデータ条件を指定します。

実際のフィルタリングについては、受信者が指定したメタデータを持つソースを選択的にブリッジが転送します。この時、複数のメタデータでフィルタリングしたい場合に「全てマッチするソースのみ転送」するか「どれかにマッチするソースを転送」するかどうかはMatchTypeフィールドで指定することとします。以下にReceiverAudioSubscriptionの例を示します。

{
  matchType: ANY,
  filters: [
    { "language": "en" },
    { "language": "ja" },
  ]
}

この場合、受信者は言語メタデータの日本語、英語どちらかを持つソースを転送するよう指定しています。このmatchTypeにより少し柔軟なフィルタリングが可能になります。

実はプロポーザル提出後にメンターから連絡があり、フィルタリングはサーバー側で行うのではなくクライアント（受信者）がそれぞれ行った方が良いという意見をもらいました。僕は映像のフィルタリングのコードを読み、それを参考にこのアーキテクチャを考えたために必然的にサーバーでフィルタリングをすることになっていましたが、よく考えたらクライアントで行った方がサーバーの負荷も少なく、ソースのメタデータと受信者のフィルター設定を両方紐付けて保持しておく必要がないという点でも楽なので、クライアントでのフィルタリングを採用することになりそうです。

クライアントでフィルタリングする場合はReceiverAudioSubscriptionは存在せず、転送して欲しいソースのIDを直接指定するような形になります。その辺りはまた実装しながらメンターと議論していくつもりです。

応募までの流れ

今回、僕がJitsiへの応募を決めたのは3月末でした。3月中旬はIETFに行っていて完全にGSoCのことは忘れており、ギリギリで調査を始めて応募したという感じなので、来年以降応募を考えている方は絶対にこのスケジュールは参考にしないでください()。

通常、GSoCではプロポーザル提出前にメンターにレビューをしてもらうというのが定石ですが、Jitsiは今年、コミュニティフォーラムがGSoC関係の質問やレビュー依頼で埋め尽くされるほどの人気ぶりだったらしく、途中からメンターへのレビュー依頼は禁止になりました。また他のプロジェクトでは当たり前にあるQualification Task （簡単なバグ取りやデモ実装で応募者の技量を確かめるタスク）も今年のJitsiにはなく、とにかく自分でコード読んで自分で考えて自分でプロポーザル書いて出してくれという形態になっていました。これはギリギリで調査を始めた僕にとっては好都合で、並行で検討していたFFmpegなんかを選んでいたらQualification Taskも間に合わなかったんじゃないかとも思っています。

というわけで僕はIETFから帰国した3/22あたりから調査を始めました。元々リアルタイム通信や映像配信に興味があり、IETFにいたのもその辺りのInteropをやることが主な目的だったわけですが、B3の夏をかけるならちゃんと自分の興味がある分野の開発をやろうということでJitsiを選びました。ずっとWebを触ってきたのでスキル的にも合いそうだなと思ったのも理由の一つです。

テーマについてはJitsi側から提示されていたものの中からAudio Switchboad APIを選択しました。ただフロントエンドを改変するだけというよりは基盤の部分を触りたかったというのと、去年のアイディアリストにも載ったアイディアなので、おそらく去年は良い応募者がいなかったのだろう、つまりある程度難しいのだろう、という想像がつき、逆に燃えたというのが理由です。

テーマが決まったら設計を考えるわけですが、Jitsiはコンポーネントの数が多く、フロントエンドのjitsi-meet、ブリッジサーバーのVideobridge、シグナリングなどの管理サーバーであるJicofo、メッセージングのためのサーバーであるProsodyなど複数の機能が複数のリポジトリに分散しています。それらの関係性と役割を把握するのにかなりの時間を費やし、上述の設計を考えるのにさらに時間を費やし、結局プロポーザルを書き始めたのは4月に入ってからでした。設計を考えるフェーズにおいても、GPTとかなり壁打ちをしてみたのですがあまりパッとせず、最終的には2日ほど自分でコードを読み込んで考えたという感じでした。新しいアイディアを提示させるというのはやっぱりLLMとは相性が悪いなという感想です。

参考にしたプロポーザル

設計を考えるフェーズが終わり、やっとプロポーザルを書き始めたわけですが、何から書けば良いかよくわからなかったのでとりあえず先人のプロポーザルを読み漁りました。具体的には以下のブログ、プロポーザルを参考にしました。先人に感謝です。

4/8が締め切りで、4/6に初稿を提出したわけですが、そこから4~5回推敲してRevisedバージョンに更新していました。人に読んでもらって感想を聞いていては間に合わないので、GPTに論理展開についてツッコミを入れてもらって直す、それを見てもらってまたツッコミをもらうというのを繰り返していました。最終的には初稿に比べたら圧倒的に簡潔で初めて読む人にもわかりやすい文章になったんじゃないかと思っています。

応募してからの流れ

4月の中旬にメンターから初めて連絡がありました。「プロポーザルに興味を持ったからオンラインで少し話そう」という感じのメールが来て、お互いのタイムゾーンを擦り合わせて日程調整をやり、Jitsiを使って話しました。

基本的にはプロポーザルを見てちょっとずつメンターが質問をするという感じだったのですが、後から聞いた話だとAIに全て書かせたプロポーザルではないかということを確認していたらしいです。というのも、今年はJitsi単体で170を超えるプロポーザルが提出されたが、そのうち100個くらいは明らかにAIに書かせた適当なものだったらしく、採択するにあたってそこはFace-to-faceで確認しておきたかったという説明を後で受けました。GSoCも近年のバグバウンティ界隈と似たような状態になりつつあるようです。

ミーティング時点ではJitsiがGoogleからもらえる枠がどれくらいか確定していなかったので、「多分採択するけど確約はできない」と言われました。というわけで良い感触だったけどなんかモヤっとしたままミーティングを終え、これ本当に採択されるんか？。。とか思いながら5/9の公式発表を待っていたという感じです。

公式発表前に連絡が来るかどうかは対象のOrganizationによると思います。規模によっては全く連絡がないまま採択通知が来ることもあるでしょうし、逆に海外の学生では採択通知前からメールでやり取りが始まっていたというケースも観測しています。

おわりに

採択されたプロジェクトはLargeサイズ（350時間）のものなのでとりあえず6,7,8月は他の仕事などは入れずにGSoCと研究に費やそうと思います。問題なくプロジェクトが進めば7月中旬にStipendが入るのでそれまでは草でも食べて節約します。

全投稿に戻る