特長・機能

片方向の配信

1 : 多の片方向配信

Sora では、1:多の大規模な配信が可能です。最大で 1:10,000 程度までの配信を想定しており、たとえば学校の授業や企業のセミナーからコンサートやスポーツのライブ配信などで利用できます。

WebRTC SFU は、P2P ではなく、音声や映像を「サーバー (SFU) 経由」で配信する技術であり、サーバー (SFU)、すなわち Sora が、配信者に代わって音声や映像を視聴者に配信してくれる仕組みです。
そのため、視聴者の数がどんなに増えても配信者の通信相手は Sora のみであり、使用する端末や回線に高い負荷がかかることなく、一度に多くの視聴者へ音声や映像をリアルタイムに配信できます。

遅延は、ネットワークなどの環境に依存しますが、基本的に 1 秒未満です。

WebRTC (P2P) および WebRTC SFU については、こちら も合わせてご確認ください。

双方向の配信

Sora では、1:1 の双方向配信や、複数人での双方向配信が可能です。

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 種類の映像を配信することが可能です。

さらに、その複数の画質の配信には優先順位をつけることができます。回線が不安定だったりマシンの負荷が高かったりする場合は、優先順位の最も低い配信が最初に停止します。優先順位の最も高い映像は必ず配信されます。

サイマルキャスト機能の詳細は ドキュメント をご参照ください。

サイマルキャストマルチコーデック機能
※ この機能は実験的機能として提供中です。
※ ブラウザからはマルチコーデックで配信することはできません。
マルチコーデック機能は昨今のブラウザが実現している仕組みです。簡単に言えば、 1 つの接続で複数のコーデックが利用できる仕組みです。このマルチコーデック機能により、Sora のサイマルキャストで複数コーデックを利用できるようになります。 たとえば、配信者は 1 つの接続で H.265 (HEVC) と H.264 の両方で配信することができます。以下の図のように、iPhone アプリで視聴するクライアントは H.265 を、PC や Android の Chrome で視聴するクライアントは H.264 をといったように、視聴者は自身の視聴環境に合わせてコーデックを選択できます。
マルチコーデックサイマルキャストでも、通常のサイマルキャストと同様に、複数のコーデックの配信に優先順位をつけることができます。 回線が不安定だったりマシンの負荷が高かったりする場合は、優先順位の最も低い配信が最初に停止します。たとえば、配信者の回線が不安定などの理由で、優先順位を最も低く設定した H.265 による配信が停止した場合は、それまで H.265 で視聴していたクライアントも、途中で切断することなく、自動で H.264 での視聴に切り替わります。

サイマルキャストマルチコーデック機能の詳細は ドキュメント をご参照ください。

スポットライト機能

WebRTC SFU を利用して、たとえば 12 名で会議を行う場合、各参加者は自分以外の 11 名の音声と映像を常に受信し続ける必要があります。また、WebRTC SFU サーバーも、常に 12 名分の音声や映像を受信/配信し続ける必要があります。

ところが実際は 12 名の会議でも、ひとつのトピックに対して発言している人はせいぜい 2〜3 名で、常に参加者全員の映像を高画質で配信しなくとも、その時点で発言している人の音声と映像がクリアであれば十分というケースも多くあります。

そこで、Sora では発言中の参加者についてはその人の音声と高画質の映像を配信し、それ以外の発言していない参加者についてはその人の低画質の映像のみを配信できるようにしました。

この機能は、参加者が発言すると、その人の音声と高画質の映像が配信されてスポットライトが当たるイメージから、スポットライト機能と名付けています。

参加者が発言した際に、低画質から高画質に切り替わるまでの秒数は自由に設定できます。たとえば参加者が発言すると、音声はすぐに配信され、映像は「2 秒」経ってから高画質に切り替わる、といった設定も可能です。
これにより、参加者が短いあいづちや物音を発するたびにすぐ高画質の映像が配信される場合と比べ、クライアントやサーバーのパケット転送量、端末上での画面表示を切り変えるコストなどをより低く抑えながら会議を行うことができます。

スポットライト機能の詳細は ドキュメント をご参照ください。

OBS WHIP/WHEP 対応

※ この機能は実験的機能として提供中です。

OBS Studio (以降 OBS) はストリーミング配信や録画に特化した、オープンソースのソフトウェアです。

OBS WHIP 対応
OBS は、WebRTC による音声や映像の配信を可能にするための WHIP (WebRTC-HTTP Ingestion Protocol) という規格に対応しています。Sora では この OBS WHIP に対応することで、OBS と Sora を組み合わせて 1 秒未満の低遅延な配信ができるようにしています。
OBS WHIP 対応の詳細は ドキュメント をご参照ください。
OBS WHEP 対応
Sora では 2024 年 6 月リリースの Sora 2024.1.0 より、OBS が今後対応を予定している WHEP (WebRTC-HTTP Egress Protocol) に対応しています。WHEP は WebRTC による音声や映像の受信を可能にするための規格で、WHEP を利用することで、Sora からの複数の配信を OBS で受信できるようになります。また、受信した音声と映像を合成し、Sora に WHIP を利用して配信することで、リアルタイムな音声と映像の合成配信が実現できます。
OBS WHEP 対応の詳細は ドキュメント をご参照ください。

録音 / 録画

※ 以下の説明では読みやすいように「録画」と記載していますが、これには「録音」も含まれます。
※ 音声の「録音のみ」、映像の「録画のみ」も可能です。

Sora では配信している音声や映像を録画して保存することが可能です。配信されている音声や映像を変換することなくそのまま保存するため、サーバーへ高い負荷が掛かることがなく、また、録画が完了すればすぐにブラウザで確認することができます。加えて、サイマルキャスト機能やスポットライト機能を利用した際の録画にも対応しています。

Sora の録画では、事前の録画予約を行う必要がなく、録画したいチャネルに対してクライアントからの接続があれば自動的に録画が開始されます。 また、そのチャネルに対する接続がなくなったタイミングで録画も終了するため、録画の停止を忘れることもありません。

さらに、クライアント単位で録画をブロックすることもできるため、たとえば録画の同意が取れないクライアントがいる場合でも、そのチャネルに参加しつつ、そのクライアントの録画のみをブロックすることが可能です。

Sora で生成される録画ファイルは WebM 形式です。また、録画ファイルは Sora に接続しているクライアントごとに個別に生成されます。それぞれの録画ファイルを合成する必要がある場合は、専用の録画合成ツール「Recording Composition Tool Hisui」をオープンソースとして公開していますのでご利用ください。

また、長時間の録画を行う場合は、録画ファイルを分割して出力することもできます。
・ 1 つのファイルとして録画する
・ 1 つのファイルと、指定した時間ごとに分割したファイルとして録画する
・ 分割したファイルとして録画する
いずれのパターンも可能です。

クラスター機能

※ この機能は実験的機能として提供中です。

Sora はクラスター機能を保有しています。Sora そのものはダウンしにくい製品ですが、クラウドやハードウェアに障害があった場合を想定し、複数の Sora でクラスターを組めるようになっています。また、Sora のクラスター機能では、障害が起きたノードを自動的に無効にし、障害から復旧したタイミングで自動的に再度クラスターに参加させることが可能です。

Sora では 2024 年 6 月の Sora 2024.1.0 でクラスター機能を大幅にアップデートしました。クラスターのリレー機能を追加するとともに、クラスター構成時に有用な機能を強化したことで、スケールアウトできる可用性の高い製品として提供しています。

クラスター機能の詳細説明を見る

シグナリング機能

Sora は WebRTC クライアントとの接続を確立するためのシグナリング機能を内蔵しています。
Sora ではシグナリングに WebSocket の他、DataChannel も利用しています。最初に WebRTC クライアントとの接続を確立する際は、基本的に WebSocket を利用し、その後シグナリングを WebSocket から DataChannel に切り替えることも可能です。

1. WebSocket のシグナリング
Sora では、最初に WebRTC クライアントとの接続を確立する際は、基本的に WebSocket を利用してシグナリングを行います。
2. WebSocket と DataChannel ハイブリッドのシグナリング
Sora では、安定した接続を維持するために、WebRTC の接続が確立したら、その後はシグナリングを WebSocket から DataChannel へ切り替えることができます。WebSocket のみでシグナリングを行う場合、WebRTC クライアントと Sora の間の通信が切断された際に早く気付けるという強みがある一方で、Sora ではシグナリング以外の様々なデータのやり取りにも WebSocket を利用しているため、不安定な回線などではパケットが混雑して詰まってしまい、通信が終了してしまう可能性があります。
DataChannel は WebSocket とは異なり、シグナリングやその他のデータを並列で運搬することができるため、パケットが詰まりにくく、より安定した接続が維持できます。ただし、その一方で DataChannel は WebSocket と比べて、WebRTC クライアントと Sora の間の通信が切断されたことを検知できるまでに時間がかかります。
そのため、たとえばオンライン会議の参加者が「会議から退出した」などの理由で接続が終了した場合にでもすぐに気付けるよう、最初の接続の確立に利用した WebSocket を、そのまま切断検知用として残しておくことができます。
安定した接続の維持と、切断時の素早い検知がともに実現できるため、当社ではこの WebSocket と DataChannel ハイブリッドのシグナリングを推奨しています。
3. DataChannel のみのシグナリング
Sora では、WebRTC の接続が確立したら、その後はシグナリングを DataChannel のみに切り替えることも可能です。最初の接続以外では WebSocket を一切使用しなくすることで、より安定した接続の維持が期待できます。
一方で、DataChannel のみのシグナリングは、WebRTC クライントと Sora の間の通信が切断されたことを検知できるまでに時間がかるため、DataChannel のみのシグナリングは、切断の検知が必ずしも重要ではない場合にのみおすすめしています。

シグナリング機能の詳細は ドキュメントをご参照ください。

メッセージング機能

WebRTC では、その機能の一つとして DataChannel があり、リアルタイムにデータの送受信を行うことができます。Sora のメッセージング機能はこの DataChannel を利用し、そこに独自の仕様を追加して実現しています。

Sora の メッセージング機能では、「ラベル」と「方向」の 2 つの要素を利用します。「ラベル」は、# で始まる文字列で、メッセージにこのラベルを付けることにより、特定のメッセージのみを送受信することができます。「方向」は、sendrecv / sendonly / recvonly のいずれかで、それぞれ (送信 + 受信) / (送信のみ) / (受信のみ) を指定します。

メッセージング機能の詳細は ドキュメント をご参照ください。

転送フィルター機能

Sora では特定のクライアントに対してのみ音声や映像を配信する、もしくは特定のクライアントに対してのみ配信しない、といったフィルターを設定することができます。音声や映像の配信を特定のクライアントのみに限定することで、クライアントやサーバーの負荷を減らすことができます。また、特定のクライアントには接続直後に音声や映像を配信せず、何らかの必要な確認やアクションを取った後に初めて配信するといった設定ができるようになります。

転送フィルターは、クライアント単位以外にチャネル単位でも設定できます。詳細は ドキュメント をご参照ください。

TURN 機能

Sora は TURN 機能を内蔵しています。そのため WebRTC による通信が NAT を越えられない環境でも、TURN サーバーを別に用意していただく必要がありません。

TURN 機能の詳細は ドキュメント をご参照ください。

4K 配信

Sora は 4K 配信に対応しています。WebRTC での映像の配信では、ブラウザによる 4K 配信に必要な高ビットレートの制限や、高いビットレートでの配信時の再送制御の影響により、4K から解像度が引き下げられてしまう場合があります。
Sora では、クライアントに対して、ビットレートの上限値を引き上げるように通知することで、最大 15Mbps という高いビットレートの映像の配信を可能にしています。また、高いビットレートの映像を配信する場合でも、解像度が下がらないような再送制御の仕組みも搭載しています。
また、WebRTC Native Client Momo を合わせてご利用いただくことで、4K 配信を手軽に検証していただくことが可能です。

E2EE 対応

※ この機能は実験的機能として提供中です。

Sora では、Sora を利用する際に、E2EE (End-to-End Encryption) をブラウザで実現するためのライブラリを、オープンソースライセンス Apache License 2.0 として公開しています。
E2EE の鍵合意やメッセージ暗号には Signal で利用されている Signal プロトコル を採用しています。また、音声や映像の暗号には Google Duo で利用されている SFrame を採用しています。
詳細は ドキュメント および WebRTC SFU Sora 向け E2EE ライブラリ をご確認ください。

IPv6 対応

Sora は、IPv6 のみの環境や IPv4 と IPv6 の混在する環境でも WebRTC による通信やウェブフックの送信が可能です。

IPv6 対応の詳細は ドキュメント をご参照ください。

クライアント SDK

Sora では、クライアント SDK を、オープンソースライセンス Apache License 2.0 として公開しています。
Sora の SDK は、WebRTC の複雑な接続処理を代行する API を提供します。これを使うことで、最小限のソースコードで Sora を利用するアプリケーションを実装できます。
以下の各 SDK は最新の WebRTC に追従しています。詳細はそれぞれの URL をご確認ください。

※ SDK は、Sora をご利用中のお客様であっても、サポートの対象外とさせていただいています。お問い合わせをいただく場合は、Discord コミュニティをご利用いただくようお願いしています。

JavaScript SDK
iOS SDK
Android SDK
Unity SDK
C++ SDK
Python SDK
C SDK

ウェブフック機能

WebRTC を使ってサービスを提供する事業者にとって、配信者や視聴者を認証したり、利用時間を制限したりといった管理は必要不可欠です。 Sora は、アプリケーションと連携するためのウェブフックを提供し、認証や接続・切断などの判断をアプリケーション側に任せる仕組みを採用しています。

認証ウェブフック
Sora 自体はクライアントの接続可否を判断する機能を持っていません。その代わり、外部のシステムに接続の可否を問い合わせるための認証ウェブフックを用意しています。

外部のサーバーに問い合わせて接続の可否を判断する場合

認証ウェブフック機能の詳細は ドキュメント をご参照ください。
セッションウェブフック
Sora では、セッションの状態を把握するためのセッションウェブフックを用意しています。セッションとは、チャネルに参加しているクライアントの集まりのことで、チャネルに誰も接続していなければセッションは存在していない状態であり、チャネルにクライアントが接続していれば、セッションが存在している状態となります。
セッションウェブフックを利用すれば、誰も接続していないチャネルに新しくクライアントが接続した状態 (セッションの生成) や、そのチャネルに参加しているクライアントがいなくなった状態 (セッションの破棄) を検知することができます。また、ある特定のチャネルでは、セッションが生成されたタイミングで自動的に録画を開始することもできます。
セッションウェブフック機能の詳細は ドキュメント をご参照ください。
イベントウェブフック
Sora は、外部のシステムにシグナリングの接続や切断、録画の開始や終了といった様々なイベントを通知するためのイベントウェブフックを用意しています。
イベントウェブフック機能の詳細は ドキュメント をご参照ください。

フルスクラッチ開発

Sora は時雨堂がフルスクラッチで開発したパッケージ製品です。また、WebRTC 関連のライブラリも全て自社で開発をしています。
2014 年から途切れることなく開発・機能追加を行っており、WebRTC に関する知識やノウハウ、最新情報への追従の速さについては世界でもトップクラスであると自負しています。

詳細なドキュメント

Sora では、ドキュメントにも力を入れています。自社でフルスクラッチで開発しているからこそ実現できる詳細なドキュメントを強みの一つとしています。 導入事例 でご紹介している多くのお客様からも、Sora の導入を決めた理由の一つとして高い評価をいただいています。

Sora のドキュメントは こちら からどなたでもご確認いただけます。

メーカーサポート

ドキュメントと合わせて、Sora では、自社でフルスクラッチで開発しているからこそ実現できる迅速で確実なサポートを強みの一つとしています。 導入事例 でご紹介している多くのお客様からも、Sora の導入を決めた理由として高い評価をいただいています。

最新情報への追従
目には見えにくい部分ですが、WebRTC を使ったサービスを安定して提供し続けて行くには、Chrome や Firefox、Safari といったブラウザの最新情報をいち早くキャッチし、迅速に対応することが極めて重要です。
Sora では常にブラウザの更新情報に注目し、製品のアップデートや適切なサポートサービスに反映させています。
アップデート
Sora のライセンスを契約中のお客様には無料でアップデートを提供しています。
  • 機能追加や改善を目的としたメジャーアップデートは、半年に一度 (6月と12月) を目安に行います。
  • 問題の修正を目的としたバグフィックスアップデートは、必要に合わせて適宜行います。

その他の特長

外部ツールとの連携
Sora の RTP 転送 API を使用することで、WebRTC で配信されている音声や映像の RTP パケットを転送できます。
この転送されてきた RTP パケットを利用することで、たとえば、FFmpeg のような外部のツールで RTP パケットを受信して、HLS や RTMP 等での配信に使用することが可能です。
再送制御
Sora では映像の遅延や欠落に対して、きめ細かな再送制御ロジックを組み合わせて実行します。
これにより回線が不安定な場合にも、映像の送受信を円滑に行い、快適なコミュニケーションを実現します。
前方誤り訂正
Sora では映像の重要なフレームの欠落に対して、前方誤り訂正を利用し、再送をすることなく欠落を回復します。
これにより、回線が不安定な場合でも映像を安定的に配信することを実現しています。
不安定レベルの通知
配信者のネットワーク環境が不安定な場合は、配信している映像が乱れたり音声が途切れたりするなどの問題が起こります。このような問題が起こった場合に、配信者は視聴者から指摘されるまで問題に気付かない可能性があります。
Sora は、配信者の端末から受け取る映像パケットにより、配信者のネットワーク回線がどの程度不安定かを判断し、配信者自身に通知する機能を搭載しています。不安定の度合いは 0 から 3 までの 4 段階で通知されます。数字が小さいほど安定しており、0 が一番安定、3 が一番不安定です。配信者はその不安定レベルを参考にしてビットレートを調整することで、安定した配信を行うことができます。
負荷の削減
Sora ではサイマルキャスト機能やスポットライト機能を利用する際に、誰も視聴していないストリームは復号処理を行わないことでサーバーの負荷を減らすことができます。また、クライアントの負荷を減らすために、特定のクライアントからの配信は受信しないように設定することが可能です。