Kota's Blog

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が入るのでそれまでは草でも食べて節約する．

全投稿に戻る