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