Blog.shiguredo.jp
Blog.shiguredo.jp
Write rieview✍️ Rezension schreiben✍️ Get Badge!🏷️ Abzeichen holen!🏷️ Edit entry⚙️ Eintrag bearbeiten⚙️ News📰 Neuigkeiten📰
Tags:
60313 Frankfurt am Main, DE Germany, EU Europe, latitude: 50.1169, longitude: 8.6837
2025 年 6 月 25 日に WebRTC SFU Sora 2025.1.0 をリリースしました。今回はスケールアップとスケールアウトを中心に改善しました。また、アプリ側で実現するのが面倒な仕組みを Sora 側で完結できるような機能も追加しています。
Sora では 1 台で多くのクライアントへ配信できるよう、いわば複数のワーカーを配置して配信を少しずつ分担させるような仕組みになっています。
これまではこのワーカーの数を事前に予測して設定しておく必要がありました。そのため、予測よりも接続が大幅に少ないような場合は、本来必要のないワーカーのリソースを使ってしまうという課題がありました。
今回のリリースからは、ワーカーの数を事前に設定することなく、今現在の接続数に応じて動的にスケールする仕組みを追加しました。これにより、リソースの無駄を最小化し、効率的に運用できるようになります。
Sora は、分散合意アルゴリズムである Raft をベースにした分散システムとして動作します。これにより、複数台の Sora でクラスター構成を組んだ場合、どの Sora に繋いでも同じチャネルへ接続することが可能です。
これまでは複数のノード間で配信をリレーする場合、一つのノードだけがリレーを担当する仕組みになっていました。この方法では配信先のノードが増えるにつれてその担当ノードの負荷が高まるため、サーバーのスペックを上げる必要があり、コスト面で課題がありました。
今回 Plumtree と呼ばれる以下の図のような仕組みを導入して複数の Sora でツリー構造を実現することにより、リレーを行う際に特定のノードだけに負荷がかかることなく、複数のノードで負荷を分散できるようになりました。これにより、Sora の耐障害性がさらに向上しています。
Sora では、認証ウェブフックを並列で処理しているため、これまで 1 チャネルあたりの接続数の厳密な制限は、お客様のシステム側で行っていただく必要がありました。今回のリリースでは、Sora 側で厳密な接続制限を行える仕組みを追加しました。
この接続制限は「認証成功後」に適用される仕組みであり、これまで認証時に接続制限を行っていたシステムでも、Sora 側での制御へ容易に切り替えられるようになっています。接続制限を有効にした場合、お客様のシステム側では認証が成功しても、接続数の上限を超えている場合は Sora 側での制御により接続が失敗します。
たとえば、接続数の上限まで残り 1 接続というチャネルに、以下の図のようにクライアント A とクライアント B の両方がほぼ同時に接続を試みたとします。
このとき、クライアント A とクライアント B の認証要求は並列で処理されるため、お客様のシステム側では二人とも認証が許可される可能性があります。しかし、今回の Sora で追加した厳密な接続制限機能により、その後 Sora 側でクライアント A のみが接続許可となり、クライアント B の接続は拒否されます。
なお、Sora によってクライアント B の接続が拒否された場合、そのことを Sora はシステムにウェブフックで通知します。
また、この接続制限は、複数台の Sora でクラスターを構築している場合でも、厳密に適用されます。
クライアントが不安定な回線によって切断され、再接続した際に「切断前の自分」がセッション内に残ってしまう場合があります。
Sora では、クライアントまたはアプリ側で自由に設定できる「クライアント ID」を接続ごとに付与できるようになっています。また、このクライアント ID は同じ値を複数の接続で共有できる仕組みになっています。 もともとは、PC とモバイルの両方からログインしている際に、同一人物かどうかを識別する目的で実装された機能です。
しかし近年、ウェブサービスでもよく見られるように、一人のユーザーが同時に複数接続する「複数ログイン」を防ぎたいという要望が増えてきたことから、今回、Sora 側で「後勝ち」の接続制御ができるようになりました。
この仕組みは非常にシンプルで、同一のクライアント ID を持つ接続がすでに存在する場合、既存の接続を切断し、新たな接続を受け入れるというものです。
さらに、ミーティングツールなどでよく求められる「画面共有は常に一つだけ」といった要件も、この仕組みを活用することで Sora の機能だけで実現することができます。
WebRTC SFU Sora では、これまで帯域推定機能はクライアント側の実装に依存していました。今回、Sora に libwebrtc 互換の帯域推定機能を搭載したことで、Sora 側でも帯域推定ができるようになりました。
帯域推定とは、簡単に言えば WebRTC クライアントがどの程度の帯域を利用できるかを推定し、それに基づいてクライアントから WebRTC SFU へ映像を送る際に、どのくらいのビットレートで送信すべきかを判断する仕組みです。 当然ながら、自身の回線が 1 Mbps しか利用できないのに 5 Mbps で映像を送信したら、配信は破綻してしまいます。
これは視聴側でも同様です。Sora には「サイマルキャスト」と呼ばれる、複数の画質を視聴側で選択できる仕組みがあります。 この機能を利用する際、視聴側のクライアントが帯域推定を行うことで、自身の環境でどの画質を選択すれば問題なく視聴できるかを判断できるようになります。
今回の対応では、帯域推定機能の実装に加えて、視聴側クライアントへの「推定結果の通知」も実現しました。
さらに、次回のリリースでは、どの画質を選択すればいいかを Sora が自動で判断する仕組みを提供できる予定です。
今回、Sora を初めてリリースした 2015 年から約 10 年間提供してきた「レガシーストリーム機能」を廃止しました。
レガシーストリーム機能は、片方向かつ 1:N の配信のみを実現する仕組みで、WebRTC が登場した当初は、この方式しか存在しませんでした。
現在では「マルチストリーム」と呼ばれる、より柔軟に、かつ双方向の配信も実現できる仕組みが提供できるようになったため、レガシーストリーム機能を廃止することにしました。
2025 年 12 月リリース予定の Sora に向けて、Sora はより便利に利用できるような仕組みを追加して行きます。
サイマルキャストを利用する場合、視聴側で画質を切り替えるには API を利用する必要があります。
今後はこれに自動で画質を切り替える仕組みを追加する予定です。 手動切替と自動切替のどちらでも選択できるようにする計画です。
この仕組みを導入することで、回線が一時的に不安定になった際には低画質の映像に切り替わり、回線が安定すれば自動的に高画質に戻すといったことが自動でできるようになります。
Sora では、これまで HTTP API ベースでコントロールを行うことを前提としていました。 しかし、データチャネルを利用して API を実行したいという要望が増えたため、一部の API をデータチャネル経由で RPC (Remote Procedure Call) として実行できる仕組みを今後追加していく予定です。
この仕組みは、データチャネルの上で JSON-RPC 2.0 を利用し実装する予定で、試験的に一部の API を実装したところ、利用者側の自由度が上がり便利なことが分かりました。たとえば、Push API をクライアントから実行することで個別にメッセージを送信したり、ホストが悪意のあるクライアントを切断したりすることが可能です。
今後はさらに、ユーザー単位で利用できる API の権限を付与できる仕組みも導入する予定です。たとえば、特定のユーザーのみが切断 API を RPC 経由で実行できるといったようにする予定です。
7.7.2025 09:11WebRTC SFU Sora 2025.1.0 リリースノート時雨堂では Python から WebRTC を利用できるようにする Sora Python SDK を OSS として公開しています。今回、以下のとおり多くの機能を含んだ 2025.1.0 をリリースしました。
今回一番の変更は、映像コーデックを設定できる仕組みを追加したことです。例えば H.264 は NVIDIA のエンコーダーを利用する、AV1 は Intel VPL を利用するといったことが指定できるようになります。エンコーダーやデコーダーをコーデックタイプごとに指定できます。
今回 AMD AMF に対応したことで、主なハードウェアアクセラレーターには対応できたかと思います。ハードウェアアクセラレーターを利用することで CPU リソースを抑えて高ビットレートの映像が配信できるようになります。
エンコード済みの音声や映像のバイナリデータを「好きなバイナリデータに置き換えられる」仕組みです。主に End to End Encryption で利用されます。
好きなバイナリデータに置き換えられるということは、後ろの 20 バイトにメタデータを含めるといったこともできるので、その他にも独自のタイムスタンプを埋め込んだり、独自のメタデータを埋め込んだりと、いろいろな場面で利用されていたりします。
リソース不足で映像ビットレートを下げる必要に迫られた際、解像度とフレームレートのどちらを維持するかを指定できるようにする仕組みです。例えば解像度を維持をする場合は、フレームレートを優先的に下げていきます。
PyPI に登録してあるため uv add sora_sdk でインストールできます。あとはドキュメントのチュートリアルを読んで映像を配信してみてください。
時雨堂では WebRTC SFU Sora を無料で試せる Sora Labo というサービスを提供していますので、気軽に Sora Python SDK を検証できます。
先日、Rust で書いた MP4 ライブラリを OSS として Apache License 2.0 にて公開しました。
![]("https://cdn-images-1.medium.com/fit/c/400/400/0*jDxaNoBwmyfUY-1h")
以前公開した C++ のMP4 ライブラリは、 Go で書かれた MP4 ライブラリを参考に開発しましたが、今回は MP4 関連の ISO の仕様書を購入し、しっかり仕様を読み込んで開発を行いました。
これまで、自社製品であるWebRTC SFU Sora（以下 Sora）では、録画ファイルの出力形式として WebM のみを採用していました。これは、 MP4ファイルが壊れやすいという特性があり、サーバー上で録画することを考慮した場合、WebM 一択だったためです。
ところが、OBS が Hybrid MP4 という壊れにくい MP4 形式を考え出し、公開しました。
これにより、Sora の録画機能として MP4 形式の採用が可能であると判断したのがスタートです。
Sora は Erlang/OTP という言語で書かれていますが、マイナーな言語なため、MP4 ライブラリはありません。一から書き起こす必要があります。
MP4 ライブラリは ISO の仕様によって厳密に決められているため、今回は ISO の仕様書を購入し、仕様に沿った MP4 を出力することに決めました。現時点で、すでに無事 Sora の MP4 出力対応は実現できており、12 月リリースの Sora で MP4 への対応を予定しています。
録画合成ツール Hisui の対応
時雨堂では、 Sora 専用の「録画合成ツール Hisui (以下 Hisui) 」を OSS として公開していますが、現状は MP4 の出力のみで、入力には対応していません。
この Hisui は C++ で書かれており、元々、より安全な Rust で書き直そうと考えてはいました。今回、Sora 向けの MP4 ライブラリを開発したこともあり、同じタイミングで一気に Hisui 向けの MP4 ライブラリも Rust で書き直すことにしました。
つまり、Rust で書き直し、MP4 の入力に対応できるようにした新しい Hisui を作る予定で、こちらは来年年明けぐらいにはリリースできればと考えています。
今回、この一連の流れの中で公開したのが Rust で書かれた MP4 ライブラリとなります。
Rust は WebAssembly との相性が良いのも強みです。今回 Rust 版の MP4 を公開するにあたり、MP4 ライブラリを WebAssembly 化して、MP4 の簡易的な解析結果を提供することにしました。MP4 ファイルをアップロードすると、解析結果が JSON 形式で出力されます。
Rust で MP4 ！と言われてもピンとこない人でも、ブラウザで MP4 が解析できる！ってなると試してくれます。さらに完全にローカルで動くため、ファイル容量が大きくても困ることはありません。
MP4 ライブラリ (WebAssembly) と WebCodecs を利用して、ブラウザで MP4 を読み込んで変換する仕組みをサンプルとして追加する予定です。
29.9.2024 15:00Rust の MP4 ライブラリを公開しました2024 年 8 月に、時雨堂の自社サービスである Sora Cloud を DataPacket というベアメタルクラウドサービスから Akamai Connected Cloud (以降 Linode) へ移行しました。
自社製品である WebRTC SFU Sora でスケールアウトが実現できるようになったためです。
Sora Cloud は時雨堂が開発しているパッケージソフトウェアである WebRTC SFU Sora (以降 Sora) のクラウド版です。
この Sora が Raft ベースの分散システムに対応し、スケールアウトを実現できるようになりました。そのため、DataPacket のベアメタルサーバーで高スペックのマシンを利用する必要がなくなり、低スペックなサーバーをたくさん並べることで、好きなだけスケールできるようになりました。
条件として、転送量が安いことが第一でした。
もともと Sora Cloud は転送量や利用時間による課金ではなく、転送量に制限がないサービスとして提供したいという思いがありました。DataPacket では「帯域課金」という仕組みがあったため、Sora Cloud との相性が良いサービスとして採用しました。
Linode は転送料金が 1 TB あたり月 5 ドルと格安です。GCP は 100 TB 以上の利用では 1 TB あたり月 85 ドルですので、それと比べるともう破格です。
さらに Linode はインスタンスに転送量が付いてきます。例えば一番安い Nanode と呼ばれる 1 C / 1 G の月 5 ドルのインスタンスには転送量が 1 TB 付いてきます。これらの付いてくる転送量は、時雨堂のアカウント全体で合計されてプールされます。
そのため、Sora Cloud 以外でも、利用するクラウドは全て Linode に集約することで転送量のプールを増やすことができ、ある程度の転送量を確保できます。もしオーバーしたとしても 1 TB あたり月 5 ドルということで、DataPacket で実現していたサービスプランを Linode でも問題なく継続できると判断しました。
Linode の Premium CPU は EPYC 7003 シリーズを利用しており、 DataPacket と変わらないスペックが利用できるのもありがたいです。
時雨堂ではサービスは全て Ansible を利用しているのですが、Linode ではAnsible Collection を提供してくれています。
![]("https://blog.shiguredo.jp/content/images/2025/01/0-x6jypaxd4yrah7lq.png")
また、良いタイミングで Placement Groups がリリースされたのも大きかったです。
コンピューティング インスタンスをグループに割り当てると、それらは別々のホスト（物理マシン）に配置されますが、同じリージョンに保持されます。これにより、高可用性のための分散モデルがサポートされます。
簡単に言えば、インスタンスが同一の物理マシンに配置されなくなる仕組みです。Sora は分散システムなので、この仕組みを利用することでサービスの可用性が上がります。
結果として、全体でコストが 1/5 になりました。DataPacket の時よりスケールアウトが気軽にできるため、サービスを運用する際の安心感もあります。インスタンスを増やすだけでスケールできるようになるのは本当に楽です。
もともとは Sora Cloud はベアメタルサーバーを利用した高コストなサービスと割り切っていたのですが、Linode への移行によりコストを抑えてサービスが提供できるようになりました。
現在 Postgres は SaaS を利用していますが、Linode での Postgres サービスがリリースされたら切り替えてさらにコストダウンを行う予定です。
Linode の S3 互換オブジェクトストレージも 1 TB の転送量がついて 250 GB で月 5 ドルと格安なのもあり、ログ保存先として利用していく予定です。
また、Sora Cloud では 2025 年に Inbound (クライアントから Sora への通信) の利用帯域は課金対象に含めないという変更を予定しています。これは DataPacket と異なり、Linode では Inbound の転送量が無料なためです。
29.9.2024 15:00Sora Cloud を Akamai Connected Cloud へ移行しましたWebRTC SFU Sora (以下 Sora) をリリースしてから昨年の 12 月で 9 年目に入りました。ここ最近は OBS を利用した WebRTC の配信に対応したり、より便利な録画機能を提供したりしています。
今回は 2024 年に提供を予定している機能を紹介していきます。今年の大きなアピールポイントは「クラスターリレー機能」と「マルチコーデック対応」の 2 つです。
現在の Sora のクラスター機能は耐障害性を目的としたものです。特定のクラスターノードに障害が発生しても、再接続すれば別のノードに接続でき、サービスが継続できます。
ただ、ある同一のチャネル (一般的にルームと呼ばれる概念と同じモノです) に参加するクライアントは特定のクラスターノードにしか接続できないという課題がありました。そのため、「どのクラスターノードに接続しても同一のチャネルに参加できる」ようにすることでチャネルのスケールアウトを実現したいと考えていました。
Redis などのデータベースを用意すれば、どのクライアントがどのノードに接続しているかなどの情報を共有することもできますが、Sora はパッケージ製品ということもあり、できるだけ他のプロダクトには依存せず、ノード間の同期についても Sora だけで完結できることを意識していました。
そのため、 2023 年の夏からクラスターの仕組みそのものを大幅に書き換えてきました（ただし互換性を維持しつつローリングアップデートができる仕組みは維持しています）。
始めに、安定したクラスターの分散のために Raft を利用することにし、RabbitMQ が公開している Raft ライブラリ Ra を採用しました。
そして 昨年 12 月リリースの Sora で、まずはチャネル情報の同期を実現しました。この段階で、「それぞれのクライアントはどのチャネルに参加するのか」、「そのチャネルに参加するにはどのノードに接続すればいいのか」の情報をクラスター内部で同期できるようになりました。
現時点の仕様では、以下の図のようにある特定のチャネル (Channel ID = egg) に参加したいクライアントが、そのチャネルを担当するノード (Sora 3) とは別のノードに接続した場合、そのチャネルを担当するノードにリダイレクトされるような挙動になっています。
そして 2024 年 6 月にリリース予定の Sora で実現するのが、クラスターリレー機能です。各ノード間どうしで双方向にリレーができるため、どのノードに接続してもそのまま特定のチャネルに参加できるようになります。
前述のとおり、現状は特定のチャネルは特定のノードにしか接続できない仕様ですが、どのノードにも接続できるようになることで、同じライセンス料金でも 1 つのチャネルあたりの最大同時接続数が増やせるというメリットが生まれます。
リレー機能を搭載することで、サービスを止めずに好きなだけスケールアウトできる WebRTC SFU が誕生します。もちろんスケールインもできます。
クラスターを利用するお客様向けに、合計接続数維持機能も提供する予定です。
Sora のライセンスでは「最大同時接続数」によってライセンスが異なります。具体的には、同じ時間に Sora に接続している WebRTC クライアントが最大でどの程度になるかというお客様の想定に基づいて 100 接続単位でライセンスを提供しています。
今のクラスターでは、特定のノードがハードウェア障害などで利用できなくなった場合、クラスター全体の合計接続数が減ってしまいます。例えば 3 ノード構成で 1 ノードあたり最大 100 同時接続だった場合、クラスター全体の合計接続数は 300 ですが、もし 1 ノードに障害が発生したらサービス全体での同時接続数は 200 に減ってしまいます。
合計接続数維持機能は、障害が発生しているノードの接続数を残りのノードが代わりに引き受けられるようにする仕組みです。
つまり先の例で言えば、 1 ノードに障害が発生したとしても、残りの 2 ノードで最大 300 接続を維持できるようにします。
障害が発生したノードが復旧したとしても、すでに他のノードに接続しているクライアントを切断したりはしません。100 をオーバーしている場合は、新規の接続をそのノード以外に促します。
リレー機能の実現に伴い、ノードアフィニティ機能も追加します。ノードアフィニティ (= 寄せ) とは、同一チャネルのクライアントはできるだけ同じノードに接続させるという仕組みです。
WebRTC SFU は低遅延であることが強みです。別ノードに分散させること自体は悪くないのですが、遅延という観点では同一ノードに寄せた方がより遅延は抑えられます。つまり、どのノードに接続しても同一のチャネルに参加はできるものの、基本的には最初から同一のチャネルに参加するクライアントを特定のノードに寄せることで、より低遅延を実現します。
アフィニティ機能はチャネル単位またはコネクション単位で指定できます。
デフォルトは有効ですが、アフィニティ(寄せ) を行わない設定もできるようにします。
クラスター構成の中でも特に 5 台 や 10 台といった大規模な構成のお客様向けに、スケールアウト/スケールインを手軽に行えるよう、テンポラリーノードという仕組みを追加します。
常に起動させておくノードとは異なり、たとえば同時接続数が多い時のみ一時的に起動させるノードをテンポラリーノードに設定しておけば、それらはクラスター構成を維持するためのノードとは認識されません。必要な情報は同期されますが、クラスターへの登録は一時的なものとして扱われます。
テンポラリーノードは起動するだけでクラスターへ一時的に登録され、テンポラリーノードを終了するだけでクラスターから削除されます。常に起動させておくノードとは異なり、必要に合わせて気軽に起動させたり終了させたりすることが可能です。
ここからは、2 つ目の大きなアピールポイントとなるマルチコーデック対応について紹介していきます。
マルチコーデック機能は昨今のブラウザが実現している仕組みです。簡単に言えば、 1 つの接続で複数のコーデックが利用できる仕組みです。
このマルチコーデック機能により、Sora のサイマルキャストで複数コーデックを利用できるようになります。
たとえば、配信者は 1 接続で H.265 (HEVC) と H.264 との両方で配信できるようになります。以下の図のように、iPhone アプリで視聴するユーザーは H265 を、PC や Android の Chrome で視聴するユーザーは H.264 をといったように、視聴者は自身の環境に合わせてコーデックを選択できます。
さらに、配信者の回線が不安定などの理由で H.265 による配信が停止した場合は、それまで H.265 で視聴していたユーザーも、途中で切断することなく H.264 での視聴に自動で切り替わります。
他にもサイマルキャストマルチコーデックを利用して、解像度 1080p の映像は H.264 で配信し、360p の映像は AV1 で配信するといったこともできるため、ユーザーの多様な端末や通信環境に合わせた配信が実現できます。
それ以外の機能について紹介していきます。
今まで Sora の録画機能で出力できるファイル形式は WebM のみでしたが、MP4 にも対応予定です。これは H.265 (HEVC) の録画へ対応するためというのが一番の理由です。
HEVC の録画は WebM では想定されていないこともあり、MP4 での出力に対応する必要があります。
Windows 11 の最新版ではプラグインなしで HEVC が利用できることや、Chromium (Chrome/Edge) でも WebRTC HEVC 対応が進んでいます。
2023 年は OBS が WebRTC での配信ができる WHIP に対応しました。そして OBS 30.1.0 では WHIP が AV1 に対応しました。
また、OBS 31 では H.265 (HEVC) への対応も予定されています。こちらについてはすでに Sora でも対応済です。
WHIP とは別に、WHEP を利用した WebRTC の音声と映像を OBS のソースとして利用できる仕組みが現在 Pull-Request として提案されていて、マージされると考えられるため、Sora でも対応していきます。
![]("https://cdn-images-1.medium.com/fit/c/400/400/0*tI6Ygkw5zvN-Xi6J")
WHEP を利用することで、複数の WebRTC 配信を OBS で合成することができるようになります。合成した映像を SFU に WHIP で配信することで、リアルタイムな映像の合成と配信が実現できます。
また、OBS では WHIP/WHEP のサイマルキャストや TURN 、統計などへの対応も予定しており、時雨堂でも貢献できればと考えています。
クラスター構成によりスケールアウトを実現するというのはリアルタイム配信にとって非常に重要です。
片方向配信のスケールアウトであればそんなに難しくはないのですが、実は WebRTC のような双方向配信でのスケールアウトはかなり難しいのが正直なところです。そのため、今回のリレー機能は自分たちにとってもチャレンジングな念願の機能と言えます。
スケールアウトする WebRTC SFU を提供できるようになることはとても楽しみです。
また、サイマルキャストマルチコーデックは、視聴者の多様な環境に合わせた柔軟な配信を実現できる画期的な仕組みということもあり、こちらも提供できることが楽しみです。
WebRTC SFU Sora は簡単にスケールアウト、スケールアップを実現でき、かつ最新の技術を利用できる安定した製品として提供していきます。
8.4.2024 15:00WebRTC SFU Sora 2024 年ロードマップWebRTC SFU Sora のクラウド版である Sora Cloud では、 Sora の強みの一つである録画機能が利用できます。また時雨堂が OSS として公開している録画合成ツール Hisui も、クラウド版 Hisui Cloud として提供しています。
クラウド版の映像配信サービスで録画というと、「1 分いくら」というイメージがあると思います。実際、 1 分 2 円程度で録画サービスを提供していることが多いです。また、録画したファイルの置き場の費用がかかる場合もあります。
映像を合成する場合も同様に、合成時間や合成するファイル自体の合計時間などによって費用が発生します。合成は CPU リソースを消費するので、費用がかかるのは当たり前と言えばそのとおりですが、安くても 1 分 2 円程度で提供されることが多いようです。
Sora Cloud ではこの録画と合成を追加料金なしで利用できるようにしました。
Sora の録画機能では、配信している音声と映像を WebM ファイルにします。変換などをせずに録画をするため、サーバー側の負荷が低いです。
Sora Cloud でもこの録画機能を提供しています。先述のとおり追加料金は発生せず、どれだけ利用しても Sora Cloud の基本料金、および同時接続数と帯域利用による従量料金以外はかかりません。
録画ファイルのアップロード先は、Sora Cloud をご利用いただくお客様の S3 または S3 オブジェクトストレージに保存します。アップロードにかかる追加料金もありません。
例えば 4 拠点双方向の映像を 30 日連続で録画したとしても追加料金はなしです。もし 1 分 2 円の有料サービスの場合は 30 日 * 24 時間 * 60 分 * 4 拠点 * 2 円で 345,600 円かかります。Sora Cloud の場合は 0 円です。
追加料金なしを実現するため、アップロードの帯域制限を行っています。S3 や S3 互換オブジェクトストレージへのアップロードに利用する帯域を 100 Mbps 程度に抑えることがあります。基本的には制限なしですが、あまりにも頻繁な録画ファイルのアップロードが発生する場合は制限をかけるようにしています。
制限を気にせずにアップロードしたいお客様がいれば、今後月額固定の有料サービスとして提供することも検討しています。
時雨堂では Sora が出力する個別の録画ファイルを合成し、1 つのファイルとして出力する Hisui という録画合成ツールを OSS として提供しており、これのクラウド版を Hisui Cloud として Sora Cloud のお客様に提供しています。
この Hisui Cloud による合成機能も、Sora Cloud の場合は 0 円で利用できます。
追加料金なしを実現するため、合成処理を行うサーバーの数を制限しています。そのため、合成処理のジョブが多くなりすぎると処理されるまでの時間がかるようになっています。
合成処理を急ぎで希望するお客様がいれば、優先的に合成処理を行うサービスを有料で提供する予定です。こちらの料金はまだ検討中です。
Sora Cloud では録画と合成を気軽に使ってもらいたいため、一定の制限を設定することで追加料金なしのサービスを実現しています。
今後も録画や合成についてより使いやすくしていくので、興味がある方は是非 Sora Cloud を使ってみてください。
