WebRTC React Native WebRTC Kit の Android 対応
実装は一段落しました。ただここから細かい部分の修正、リリースにむけてのドキュメントやいろいろな整理とこっからが本番といえば本番です。
夏が終わる前にはリリースしたいと思います。
またリリース後に DataChannel の対応を進めていきたいと考えています。
React Native WebRTC Kit の M75 対応
iOS のみですがゆっくり進めています。
React Native WebRTC Kit の React Native for Windows 対応の調査
React Native for Windows の vnext が安定したタイミングで進めていきたいと思っています。iOS/Android とは全く別物にはなるとおもうので、コスト高めですが、かなりありなのでは？と思っています。色々やってみていこうと思っています。
WebRTC Signaling Server Ayame
方針
WebRTC の P2P 向けシグナリングサーバはベンダーロックフリーなオープンソースのがあるべきという方針で開発しています。あまり焦らずゆっくり開発しています。
シグナリングサーバは決まった仕様がないため色々苦労する人が多いことから、webrtc.org が公開している AppRTC のデモ互換で開発しています。
本番でも利用可能な性能を担保したいことから Go で開発しています。
Web SDK 公開
Ayame Web SDK を公開しました。とてもシンプルに実現できます。
まだ開発中ですが、とにかく簡単に使えるように作っていきます。依存ライブラリも一切ないのでかなり読みやすいと思います。
React Native SDK 対応
React Native WebRTC Kit を利用した SDK を検討しています。まだどう進めるかなどは決まっていませんが、開発はしていく予定です。
React SDK 対応
Reaft のコンポーネント化することで気軽に利用できるようにするための仕組みです。React Native SDK と同じになる予定です。
ウェブフック機能の追加
Ayame には認証の仕組みなどが一切乗っていないこともあり、ウェブフックを利用した認証の仕組みと、さらに多段認証の仕組みを用意する予定です。
Ayame サービス化
OpenAyame プロジェクトの成果を気軽に使えるようにする Ayame サービス化を検討しています。
- 完全無料で利用できる
- TURN-UDP/TCP/TLS を提供する
- 運用保証をしない
といった制約をつけてリリースできればと考えています。
WebRTC Native Client Momo
方針
WebRTC Native Client Momo の大きな方針はビルドの簡易化、libwebrtc への追従がメインです。様々な OS やアーキテクチャーに対応する必要がありますが、それらを簡易化し、誰もが簡単にビルドできるようにすることを目的としています。
また libwebrtc の最新バージョンに追従することで最新の技術を積極的に使えます。
ハードウェアエンコーダーへの対応も積極的にすすめています。現時点では Raspberry Pi と macOS のハードウェアエンコーダに対応しています。今後は Jetson Nano に搭載されている NVENC に対応していく予定です。
検証コストの削減
Momo は様々な OS やハードに対応していることもあり、検証コストがとても高いため、リリースまでにとても時間がかかるため、検証対象を Raspberry Pi 版のみに絞ることにしました。
ほかはビルドのみ確認して動作保証事態はせず、フィードバックベースで進めていくという方針をとります。
バイナリ提供を Rapsberry Pi のみに
Jetson Nano に搭載されている NVENC の H.264 ライセンスが不明なことや、macOS の環境依存を回避するため、バイナリ提供は Raspberry Pi 版のみに絞ることにしました。ハードウェアエンコーダ周りのライセンスが名確認なっているのは Raspberry Pi だけというのが現状だからです。
Windows 対応の有料化
今後 Momo を Windows 対応を進めていこうと考えていますが、こちらはビルド対応やハードウェアエンコーダ対応、画面共有対応の開発やメンテナンスコストを考えると有料で提供することで継続性を出したほうが良いと考えています。
データチャネル対応
ROS での対応を検討していますが、当面は様子見です。
NVIDIA Jetson Nano 対応
NVIDIA が出した格安の開発キットです。1.2 万円で NVIDIA の NVENC が内蔵されており 4K@30 のハードウェアエンコーダが入っています。
これをうまく使うことで超高画質な映像を超低遅延で配信できる Momo が実現できそうということで、進めていく予定です。
すでに Ubuntu 18.04 ARM64 版のバイナリはビルド可能になっています。
ハードウェア 4K@30 配信対応
Jetson Nano の NVENC を利用して 4K カメラの映像を 4K@30 で配信できるようにしていく予定です。
ライブラリのアップデート
利用しているライブラリを定期的にアップデートしていっています。これはとても重要だという認識です。
デバイス一覧とデバイス選択機能
すでに PR が出ていますが、libwebrtc 75 対応で色々変わったため再実装が必要という認識です。対応していく予定です。
ハードウェアエンコーダにデコーダをパイプで繋いで高速化
できるだけ処理を減らして高速化する方法です。これがうまくいくと Raspberry Pi で 1080p 30fps が実現可能かもしれません。
WebRTC Signaling Server Ayame 対応
今は p2p と sora のみ対応していますが、ここに ayame を追加する予定です。Ayame に対応することで様々な環境で気軽に利用することが可能になります。
HDMI to CSI-2 調査
HDMI からの映像を CSI-2 に流すことにより HDMI 経由の映像を Momo にわたすという仕組みを検討しています。ハードウェア必須です。
B110 HDMI to CSI-2 bridge (4k) この辺が使えるのでは？など色々調べてみています。
Simulcast 対応
利用は Sora のみとなりますが、クライアント側が複数の画質を配信する Simulcast に対応していく予定です。ただハードウェアエンコーダーと Simulcast についてはまだまだ現時点ではどうなるかわからないため、少し時間は掛かりそうです。
WebRTC SFU Sora
方針
機能は Simulcast と帯域推定による動的ビットレート変更の２つをメインに進めていっています。
内部の実装をいろいろ書き換えたりすることで表には見えてきませんが高速化、安定性、拡張性などを改善していっています。
次のリリースである 19.10 (2019 年 10 月リリース予定) では Simulcast がほぼすべてのブラウザで利用可能になる可能性がとても高いということもあり、Simulcast を優先しています。
Simulcast は複数の画質を配信する技術ですが、動的ビットレートの選択というのも重要になります。
クライアントの帯域が余裕があればある程度高画質の映像を自動で流すという仕組みです。
iOS / Android SDK の libwebrtc M75 対応
まだリリースはされていませんが、淡々と進めています。
DataChannel 対応
QUIC 対応がどうなるか見えないことや RTCQuicTransport が gQUIC 実装になってしまっていることもあり、DataChannel への対応を少しずつ進めています。ただパーミッション問題があったり、色々と SFU とは相性が悪いこともあり、慎重に進めています。
QUIC 対応
WebRTC QUIC P2P は Google QUIC のままでいくようなので、スルーします。ただ WebRTC QUIC Client/Server は WebTransport と名前を変えて進んでいくようです。
WebRTC の世界にこれがどう影響出るのかわかりません。できるだけ最低限の実装で WebRTC が QUIC に対応したタイミングで対応できるように追いかけはしていきます。当面は DataChannel を進めていきます。
Simulcast a=rid/a=simulcast 対応
実験的機能ではありますが、すでに利用可能になっています。今後は安定性、ビットレートやフレームレートの指定、解像度の指定などがサーバからできるように進めていく予定です。
また動的な解像度変更への対応の安定化も行っていきます。
帯域推定を利用した動的ビットレート制御
Simulcast にもきいてくる帯域推定を利用した動的ビットレートのい制御をガッツリやっていきます。
簡単に言えば使っている回線の状態に適した利用ビットレートをサーバ側から提案していくという仕組みです。
この仕組があれば Simulcast でどの解像度を受信すべきかというのもサーバ側が勝手に決定してくれるようになります。
品質に投資していきます。
Sora 専用自動テストサービスの開発
引き続き作っていっています。これのおかげでバグがいくつか発見されました。1 年で「とりあえず動くもの」までもっていくという方針です。テストサービスを焦って作ってもいいことありません。
毎日コツコツと作っていくのが大事です。実際動かすことで Sora のバグも発見できていますし、デメリットはありません。
品質に投資していきます。
Windows SDK の有料提供の検討
Momo の Windows 対応や React Native for Windows が出てきて、Sora の Windows SDK があってもいいのではないか？と考え始めています。
Windows SDK はサポートが必須になる可能性が高いだろうと考え、クローズドソース、有料で提供することを考えています。
今すぐに何かアクションをとるわけではありませんが、中長期的には対応していければと考えています。
OpenSora プロジェクト
無料で Sora を利用できるサービスを検討していたのですが、現時点では不要と判断しています。ただ、仕事で Sora を利用しているお客様が Sora をプライベートで使いたいという要望があるため、どう提供するのが良いか検討はしていく予定です。
取り組んでいないこと
Unity 対応
メンテナンスコストが高い事、需要が無いことから取り組んでいません。今後も対応していく予定はありません。
2019 年 5 月版は以下からどうぞ。
