時雨堂では自社製品 WebRTC SFU Sora 専用の SDK を様々なプラットフォームに向けて開発、提供しています。
今回は、新たに WebRTC SFU Sora C SDK を公開しました。
Sora C SDK は今までの Sora SDK がベースとしている libwebrtc ではなく、 libdatachannel をベースとした SDK になります。
目的
Sora C SDK は libwebrtc ではなく libdatachannel を利用することで、バイナリサイズとリリース頻度を抑えることを目的にしています。
バイナリサイズ
libwebrtc は WebRTC だけでなく音声や映像コーデックなど、何でも入っているいうこともあり、バイナリサイズもとても大きいです。しかし、libdatacahnnel は WebRTC 通信部分と WebSocket のみのライブラリです。
さらに Sora C SDK では映像コーデックにソフトウェアを利用せずハードウェアのみを採用することで、ライブラリのバイナリサイズを抑えています。
libwebrtc.a は Sora とのシグナリングやそれ以外のライブラリを含まない状態で約 70 MB ですが、libdatacahnnel を使った libsorac.a (Sora C SDK) は Sora のシグナリング機能を含めても約 10 MBです。バイナリサイズは約 1/7 になります。
リリース頻度
libwebrtc では最新の技術が利用されていますが、リリース頻度は高く、 Chrome に合わせて 4 週間に 1 回です。さらにセキュリティパッチは基本的に最新の安定版にしか適用されません。つまり、libwebrtc はリリース後 4 週間経過したらセキュリティパッチは当たらない状態になってしまいます。そのため SDK のリリース頻度も libwebrtc のリリース頻度に引っ張られてしまいます。これは組み込みで WebRTC を利用しようとすると嬉しくありません。
libdatachannel は前述したとおり機能が限定的なため、規模もとても小さいです。そのため時雨堂で変更内容を把握し、アップデートするべきかどうかの判断ができますし、最悪 libdatachannel を fork して、完全に時雨堂の管理下でメンテナンスすることが可能です。
libdatacahnnel はまだバージョンが 1.0 に達していないことから、枯れているとはいえず、アップデート頻度もまだ多いです。しかし libwebrtc のようにライブラリのアップデートを強制してくることはありません。
Sora C SDK は Sora と同様、 6 ヶ月に 1 回程度のリリースサイクルを考えています。よりリリース頻度を下げる Sora C SDK LTS 版などの提供も検討しています。
機能
現時点では Sora の配信のみ (role: sendonly) に対応しています。今後、視聴のみ (role: recvonly) にも対応していく予定です。
対応するコーデックは H.264 のみで、ライブラリには OpenH264 を利用しています。今後は macOS などの ハードウェアアクセラレーター (HWA) を利用した H.264 へ対応していきます。H.265 の対応も将来的には予定しています。
データチャネルを利用したシグナリングやメッセージには対応済みです。そのため音声や映像だけでなく、メッセージングの仕組みも利用可能です。たとえば遠隔支援で何かデータを送ったり、操作したりといった仕組みでご利用頂ければと思います。
サンプル
サンプルには時雨堂が公開している WebRTC Native Client Momo の Sora C SDK 版となる Sumomo を用意しています。クライアントを開発する場合は、こちらをベースにして頂ければと思います。
Sumomo には libdatachannel では提供されていない、各プラットフォーム向けの音声や映像デバイス関連の処理や、カメラからの映像を取り扱うための libyuv や libjpeg-turbo なども組み込んでいます。
開発経緯
Sora C SDK の開発経緯ですが、時雨堂としては libwebrtc ベースの SDK で困ってはいないものの、組み込み向けにより軽量でより扱いやすい SDK を提供したいなという思いはずっとありました。ただ、さすがに一から WebRTC ライブラリを開発する体力はないため、断念していました。
そんな中、 OBS から WebRTC が配信できる WHIP に libdatachannel が採用されたのを知り、libdatachannel をベースとした軽量な SDK が開発できないかと考えるようになりました。
libdatachannel を調べていくと WebRTC 通信部分だけでなく WebSocket もライブラリとして提供していました。そのため、Sora のシグナリングで利用している WebSocket のための追加ライブラリが不要なことがわかりました。
また、OBS に採用された際に、libdatachannel の開発者がとても活発かつ丁寧な対応をされていたことも好印象でした。
自分の中で、まず失敗してもいいのでチャレンジしてみようという気持ちが強くなってきて、プロトタイプを開発してみることにしました。
開発
まずは libdatachannel を利用したプロトタイプとして以下の機能を実現したクライアントを開発をしてみました。
- 送信のみ (role: sendonly)
- マルチストリームのみ
- 音声コーデックは Opus のみ
- 映像コーデックは H.264 のみ、かつ OpenH264 を利用
- データチャネルを利用したシグナリング対応
- データチャネルを利用したメッセージング対応
SDK をいきなり開発するのではなく、何ができるのか、何ができないのか、足りない機能は何なのかをクライアントを実装しながら確認していくことにしました。
開発は Sora C++ SDK の開発を主に担当してくれている めるぽん にお願いしました。
Sora を libwebrtc に特化させていたこともあり、libdatachannel に用意されていない仕組みを追加する必要はありましたが、問題なく配信できるクライアントが開発できました。
Sora の強みの一つであるデータチャネルを利用したシグナリングとメッセージングの動作も確認できました。
その後、プロトタイプで開発したクライアントをベースに SDK とサンプルを開発してもらい、コードを整理して公開に至りました。
貢献
libdatachannel を採用するにあたり、少しでも貢献したいと考え、まずは libdatachannel 開発者 Paul-Louis Ageneau 氏 の GitHub スポンサー ($100 / 月)になりました。
また DataChannel で利用されている SCTP で検討されている Zero Checksum 機能を実現するため libdatachannel と usrsctp への Pull-Request を送り、無事マージされました。
この Zero Chucksum 機能は DTLS で整合性が担保されているため、SCTP のチェックサム計算をせず常にチェックサム部分に 0 を入れるという仕組みです。SCTP のチェックサム計算は暗号化の次に CPU の負荷が高い部分なので、クライアントと SFU の両方で負荷を下げる効果があります。
それ以外にも Mbed TLS で CA 証明書のチェックをする仕組みを Pull-Request として送ってマージされています。
今後も積極的に libdatachannel や依存ライブラリに貢献をしていきます。
今後
まずはソースコード公開用に Ubuntu 22.04 x86_64 向けとして開発を進めてきました。
今後は検証をしやすくするため macOS arm64 向けに開発を進めていきます。それに伴い macOS arm64 の Video Toolbox を利用して H.264 と H265 の HWA を利用した配信を実現します。これらが実現できたタイミングで最初のリリースを予定しています。
リリース後は RISC-V (OS は Debian) で動作を進めて行きます。VisionFive 2 というボードで H.265 HWA を利用した配信を可能にする予定です。
その後は iOS や Android といったモバイルプラットフォームへの対応を進めていきます。
優先実装
Sora C SDK は多くの優先実装を用意していますので、ご相談をお待ちしております。
雑感
今回 libwebrtc を利用しない WebRTC SDK を開発するというのは自分の中では大きなチャレンジでしたが、やりたかった軽量で扱いやすい WebRTC SDK を提供するという目的は達成できたと思います。
具体的にどのような分野というのはないのですが、Sora C SDK は今までの SDK とは異なる分野で使ってもらいたいと考えています。
興味のある方は、Sumomo と Sora Labo を使うことですぐに Sora C SDK を試すことができますので、是非使ってみてください。
