Sora では、1:多の大規模な配信が可能です。最大で 1:1000 程度までの配信を想定しており、例えば学校や塾の授業、企業のセミナーや研修などで利用できます。
WebRTC SFU は、P2P ではなく、音声や映像を「サーバー (SFU) 経由」で配信する技術であり、サーバー (SFU)、すなわち Sora
が、配信者に代わって音声や映像を視聴者に配信してくれる仕組みです。
そのため、視聴者の数がどんなに増えても配信者の通信相手は Sora のみであり、使用する端末や回線に高い負荷がかかることなく、一度に多くの視聴者へ音声や映像をリアルタイムに配信できます。
遅延は、ネットワークなどの環境に依存しますが、基本的に 1 秒未満です。
WebRTC (P2P) および WebRTC SFU については、こちらも合わせてご確認ください。
Sora では、1:1 の双方向配信や、多:多の双方向配信が可能です。
※ この機能は Chrome、Firefox、Safari、Edge で利用可能です。
マルチストリームとは一つのピアコネクションで複数の音声や映像を動的に追加したり削除したりする仕組みです。
マルチストリームでは role に sendrecv (配信と視聴)、sendonly (配信のみ)、recvonly (視聴のみ) のいずれかを指定できます。例えば、右図のようなオンラインセミナーでは、講師および受講生は sendrecv (配信と視聴)、講師による画面共有は sendonly (配信のみ)、セミナーの見学者は recvonly (視聴のみ) を指定しています。
また、Sora では「同時接続数」によってライセンス料金が異なりますが、このマルチストリームを使うことで、同時接続数を節約することが可能です。この図の場合、Sora の同時接続数は「4」となります。
サイマルキャストとは、配信者が 1 つの接続だけで複数種類のエンコードした映像を配信できる技術です。
例えば、配信者は 1 つの接続で複数の画質の映像を配信することができます。
サイマルキャストが無い頃の WebRTC SFU では、配信者はすべての視聴者に対して一種類の画質の映像しか送れませんでした。
そのため、高画質の映像を視聴できるネットワーク環境の A さんに対しても、低画質の映像しか視聴できないネットワーク環境の B さんに対しても、同じ画質の映像しか送ることができず、結果として B
さんは視聴できないなどの問題が発生するケースがありました。
Sora では、その後登場したサイマルキャストに対応し、配信者が 1 つの映像を、「高」「中」「低」最大 3 種類の画質で Sora に配信できるようにしています。これにより、視聴者は自身のネットワーク環境に合わせてその 3 種類の画質のどの映像を受信するか選択でき、視聴の途中で動的に画質を切り替えることも可能です。
また、サイマルキャストのエンコーディングパラメータをカスタマイズすることで、上記のような画質の指定以外にも、最大 3 種類のエンコードした映像を送れるようになりました。たとえば「解像度もフレームレートもとても低い」「解像度は高いがフレームレートは低い」という 2 種類の映像を配信する、といった設定も可能です。
※ この機能は Chrome、Edge、Safari で利用できます。
WebRTC SFU を利用して 20 名で会議を行う場合、各参加者は自分以外の 19 名の音声と映像を常に受信し続ける必要があります。また、WebRTC SFU サーバーも、常に 20 名分の音声や映像を受信/配信し続ける必要があります。
ところが実際は 20 名の会議でも、ひとつのトピックに対して発言している人はせいぜい 2〜3 名で、映像も常に参加者全員のものを高画質で配信しなくとも、その時点で発言している人だけの音声と映像がクリアであれば十分というケースも多くあります。
そこで、Sora では発言中の参加者についてはその人の音声と高画質の映像を配信し、それ以外の発言していない参加者についてはその人の低画質の映像のみを配信する、といったように会議に合わせた配信ができるうようにしました。
この機能は、参加者が発言するとその人の音声と高画質の映像が配信されてスポットライトが当たるイメージから、スポットライト機能と名付けています。
参加者が発言してから高画質に切り替わるまでの秒数は自由に設定できます。例えば参加者が発言すると、音声はすぐに配信され、映像は「2 秒」経ってから高画質に切り替わる、といった設定が可能です。
これにより、参加者が短いあいづちや物音を発するたびにすぐ高画質の映像が配信される場合と比べ、クライアントやサーバーのパケット転送量、端末上での画面表示を切り変えるコストをより低く抑えながら、大人数で会議することができます。
スポットライト機能は無料の評価版で実際にお試しいただくことが可能です。ご希望の方はお問い合わせください。
※ この機能は実験的機能として提供中です。
OBS (Open Broadcaster Software) はストリーミング配信や録画が可能なソフトウェアです。OBS では今後 WebRTC のシグナリング規格である WHIP (WebRTC HTTP Ingestion Protocol) への対応を予定しているため、Sora も WHIP に対応することで、OBS と Sora を組み合わせた WebRTC による低遅延の配信ができるようになります。
OBS WHIP 対応の詳細はドキュメントをご参照ください。
Sora では、配信している音声や映像を録音・録画して保存することが可能です。
配信されている映像を変換することなくそのまま保存するため、サーバーへ負荷が掛かることがなく、録画が完了すればすぐにブラウザで確認することができます。
また、サイマルキャスト機能やスポットライト機能を利用した際の録画にも対応しています。
長時間の録画が必要な場合は、録画ファイルを分割して出力することができます。
・1 つのファイルとして録画する
・1 つのファイルと、指定した時間ごとに分割したファイルとして録画する
・分割したファイルとして録画する
いずれのパターンも可能です。
Sora で生成される録画ファイルは WebM 形式です。また、録画ファイルは Sora に接続しているクライアントごとに個別に生成されます。それぞれの録画ファイルを合成する必要がある場合は、専用の録画合成ツール「Recording Composition Tool Hisui」をオープンソースとして公開していますので、必要に合わせてご利用ください。
※ この機能は実験的機能として提供中です。
※ この機能を利用するには、クラスターを組むノードの数に合わせたライセンス契約が必要です。
Sora はクラスター機能を保有しています。Sora そのものはダウンしにくい製品ですが、クラウドやハードに障害があった場合を想定し、複数の Sora でクラスターを組めるようになっています。また、Sora のクラスター機能では、障害が起きたノードを自動的に無効にし、障害から復旧したタイミングで自動的に再度クラスターに参加させることが可能です。
チャネルに初めてクライアントが接続する場合
接続済みのクライアントがいるチャネルに別のクライアントが接続する場合
※ この機能は実験的機能として提供中です。
WebRTC では、その機能の一つとして DataChannel があり、リアルタイムにデータの送受信を行うことができます。Sora のメッセージング機能はこの DataChannel を利用し、そこに独自の仕様を追加して実現しています。
Sora の メッセージング機能では、「ラベル」と「方向」の 2 つの要素を利用します。「ラベル」は、# で始まる文字列で、メッセージにこのラベルを付けることにより、特定のメッセージのみを送受信することができます。「方向」は、sendrecv / sendonly / recvonly のいずれかで、それぞれ (送信 + 受信) / (送信のみ) / (受信のみ) を指定します。
Sora はシグナリング機能を内蔵しています。これから配信を行う WebRTC クライアントは、視聴する WebRTC クライアントと直接通信するのではなく、Sora
のみと通信を行えばよいため、経路の確立でつまずくことがありません。
Sora ではシグナリングに WebSocket の他、DataChannel も利用しています。初めに WebRTC クライアントとの接続を確立する際は必ず WebSocket を利用し、その後シグナリングを
WebSocket から DataChannel に切り替えることも可能です。
※ この機能は実験的機能として提供中です。
Sora では特定のクライアントに対してのみ音声や映像を配信する、もしくは特定のクライアントに対してのみ配信しない、といったフィルターを設定することができます。音声や映像の配信を特定のクライアントのみに限定することで、クライアントやサーバーの負荷を減らすことができます。また、特定のクライアントには接続直後に音声や映像を配信せず、何らかの必要な確認やアクションを取った後に初めて配信するといった設定ができるようになります。
転送フィルターは、クライアント単位以外にチャネル単位でも設定できます。詳細はドキュメントをご参照ください。
Sora は TURN 機能を内蔵しています。そのため WebRTC による通信が NAT を越えられない環境でも、TURN サーバーを別に用意していただく必要がありません。
Sora は 4K 配信に対応しています。WebRTC での映像の配信では、ブラウザによる 4K
配信に必要な高ビットレートの制限や、高いビットレートでの配信時の再送制御の影響により、4K から解像度が引き下げられてしまう場合があります。
Sora では、クライアントに対して、ビットレートの上限値を引き上げるように通知することで、最大 15Mbps
という高いビットレートの映像の配信を可能にしています。また、高いビットレートの映像を配信する場合でも、解像度が下がらないような再送制御の仕組みも搭載しています。
また、WebRTC Native Client Momo を合わせてご利用いただくことで、4K
配信を手軽に検証していただくことが可能です。
Sora では、Sora を利用する際に、E2EE (End-to-End Encryption) をブラウザで実現するためのライブラリを、オープンソースライセンス Apache
License 2.0 として公開しています。
E2EE の鍵合意やメッセージ暗号には Signal で利用されている Signal
プロトコルを採用しています。また、音声や映像の暗号には Google Duo で利用されている SFrame を採用しています。
詳細は WebRTC SFU Sora 向け E2EE ライブラリをご確認ください。
Sora は、IPv6 のみの環境や IPv4 と IPv6 の混在する環境でも WebRTC による通信が可能です。
Sora では、クライアント SDK を、オープンソースライセンス Apache License 2.0 として公開しています。
Sora の SDK は、WebRTC の複雑な接続処理を肩代わりする API を提供し、Sora を利用するアプリケーションを最小限のソースコードで実装できます。以下の各 SDK ともに最新の WebRTC
に追従しています。詳細はそれぞれの URL をご確認ください。
※ SDK は、Sora をご利用中のお客様であっても、サポートの対象外としています。お問い合わせをいただく場合は、Discord コミュニティに参加していただくようお願いしています。
WebRTC を使ってサービスを提供する事業者にとって、配信者や視聴者を認証したり、利用時間を制限したりといった管理は必要不可欠です。
Sora は、アプリケーションと連携するためのウェブフックを提供し、認証や接続・切断などの判断をアプリケーション側に任せる仕組みを採用しています。
外部のサーバーに問い合わせて認証の可否を判断する場合
30 分以上接続するクライアントを切断する場合
Sora は時雨堂がフルスクラッチで開発したパッケージ製品です。また、WebRTC 関連のライブラリも全て自社で開発をしています。
2014 年から途切れることなく開発・機能追加を行っており、WebRTC に関する知識やノウハウ、最新情報への追従の速さについてはトップクラスであると自負しています。
Sora では、ドキュメントにも力を入れています。自社でフルスクラッチで開発しているからこそ実現できる詳細なドキュメントを強みの一つとしています。 導入事例でご紹介している多くのお客様からも、Sora の導入を決めた理由として高い評価をいただいています。
Sora のドキュメントはこちらからどなたでもご確認いただけます。
ドキュメントと合わせて、Sora では、自社でフルスクラッチで開発しているからこそ実現できる迅速で確実なサポートを強みの一つとしています。 導入事例でご紹介している多くのお客様からも、Sora の導入を決めた理由として高い評価をいただいています。