Unity Render Streamingは、Unityが描画した映像と音声をWebRTCでブラウザへ送り、ブラウザ側のマウス・キーボード・タッチ入力をUnityへ返すUnity公式パッケージです。重いHDRPのシーンをGPU搭載マシンで描画し、iPadや社給ノートPCのブラウザから操作する、いわゆるクラウドレンダリング(ピクセルストリーミング)を自前で組めます。
ただし2026年10月時点で、パッケージは2024年12月の3.1.0-exp.9から更新が止まり、依存するWebRTCパッケージも非推奨になりました。公式チュートリアルどおりに進めると、web appのダウンロードでも失敗します。この記事では、その回避を含めたブラウザ接続までの手順、Unity 6で使う場合のWebRTCパッケージとの関係、本番で動かすときの起動オプションと同時接続数の上限、Furioos終了後のホスティング料金までを、リポジトリのソースと公式ドキュメントで確かめた範囲で整理します。
まとめ
- 実体はUnityパッケージ
com.unity.renderstreaming。最新は3.1.0-exp.9(CHANGELOG上は2024年12月13日)で、実験版(exp)のまま正式版は出ていない。 - 3.1.0-exp.9ではRender Streaming Wizardの「Download latest version web app」が404で失敗する。3.1.0-exp.7のリリースページからバイナリを取るか、WebAppをnpmでビルドして起動する。
- 依存先の
com.unity.webrtcは2025年に3.0.0が正式版になり最小Unityが6000.0へ上がったが、2026年8月18日にREADMEへ「deprecated(非推奨)」と追記された。Render Streaming側は3.0.0-pre.8を指定したままで、Unity 6での動作保証は明記されていない。 - 公式FAQの目安は、デスクトップPC1台で720p映像を約5台まで。それ以上はSFUが必要で、simulcastにも対応していない。
- ビルドしたアプリは
-batchmodeと-nographicsでは動かない。GPUと画面出力を持つ環境で起動する。 - Unity公式のマネージド配信Furioosは提供を終えている。移行先はVagon Streams(Tesla T4で0.025米ドル/分から)、PureWeb Reality(年契約で月額750米ドルから)、ZeroLight OmniStream(3米ドル/時から)か、自前のGPUインスタンス。
Unity Render Streamingの仕組みと現行バージョン
パッケージの実体と更新状況
開発はGitHubのUnity-Technologies/UnityRenderStreamingで行われています。タグ3.1.0-exp.9の package.json と CHANGELOG の記載は次のとおりです。
| 項目 | 値 |
|---|---|
| パッケージ名 | com.unity.renderstreaming |
| 最新版 | 3.1.0-exp.9 |
| リリース日 | CHANGELOG 2024-12-13/レジストリ公開 2024-12-17 |
| 最小Unity | 2020.3 |
| 依存: WebRTC | com.unity.webrtc 3.0.0-pre.8 |
| 依存: Input System | com.unity.inputsystem 1.5.1 |
| 3.1系の初版 | 3.1.0-exp.1(2021-06-15) |
exp.9の変更はWebRTCパッケージを3.0.0-pre.8へ上げたことと、APIドキュメントの改善だけでした。GitHubのコミット履歴では、このリリース後にmainブランチへ入った変更は2025年10月23日の絵文字アセット削除(プルリクエスト#1037)だけです。確認時点のGitHub表示では、未解決のIssueは107件、開いているPull Requestは7件です。3.1系は5年以上expが外れていないため、採用するならパッケージの版を固定し、Unityエディタの更新とセットで検証する運用が前提になります。
映像・音声・入力が流れる経路
通信はWebRTCのP2Pです。UnityアプリとブラウザがSDP(Offer/Answer)とICE Candidateを交換して接続を張り、確立後は映像・音声・入力データがピア間を直接流れます。交換を仲介するのがシグナリングサーバー(リポジトリのWebApp)で、Unity側の既定のシグナリングURLは ws://127.0.0.1、方式はWebSocketです(HTTPポーリングも選べ、既定の間隔は5000ミリ秒)。
NAT越えに使うICEサーバーの既定値は、Googleの公開STUN stun:stun.l.google.com:19302 だけでTURNは含まれません。社内ネットワークのようにUDPや対称型NATでP2Pが張れない相手へ配信するなら、TURNサーバーを用意してProject SettingsのRender Streamingパネルに登録します。ここを既定のまま本番に出すと「開発機では映るのに顧客環境では映らない」という典型的な失敗になります。STUNとTURNの役割の違いはWebRTCとは?P2Pの仕組み・ICE/STUN/TURNからSFU選定・実装・運用判断まで実装者向けに解説で詳しく扱っています。
クラウドレンダリングの2つの型|レンダーファームとピクセルストリーミング
「クラウドレンダリング」は、性質の違う2つの技術を指す言葉です。検索結果の上位に並ぶのはほとんどがレンダーファームの事業者で、Render Streamingとは用途が重なりません。
| 観点 | バッチ型(レンダーファーム) | リアルタイム型(ピクセルストリーミング) |
|---|---|---|
| 代表例 | Blender・Mayaの分散レンダリング | Unity Render Streaming、Unreal Pixel Streaming |
| 成果物 | 連番画像・動画ファイル | 操作できる映像ストリーム |
| 課金の軸 | レンダリングのノード時間 | セッション中のGPU占有時間 |
| 規模と費用 | ジョブが終われば止まる | 同時接続数に比例して増える |
リアルタイム型は、ユーザーがセッションを開いている間ずっとGPUインスタンスを占有します。後述のとおり1台で捌ける人数も限られます。GPU利用料は、稼働させたインスタンスごとの「時間単価×稼働時間」の合計です。必要な台数は同時接続数から見積もり、待機中の稼働、通信料、運用費を別に積みます。Unreal Engine側ではUE 5.5からWebRTC層を作り直したPixel Streaming 2が入り、移行期間として旧Pixel Streamingプラグインと両方が同梱されています(Epic公式のPixel Streaming 2概要)。
Unity 6で使う場合の注意|WebRTC 3.0.0との関係
Render Streamingの対応表(Documentation~/index.md)が明記するエディタは2020.3/2021.3/2022.3/2023.1で、Unity 6は載っていません。同じリポジトリのFAQは「2020.3以上」とだけ書いており、公式の記述は揃っていません。
状況を変えたのは依存先の com.unity.webrtc です。2025年9月12日付(CHANGELOG)の3.0.0で正式版になり、Unityのパッケージレジストリ上の最小Unityが6000.0へ上がりました。3.0.0-pre.8との違いは次のとおりです(com.unity.webrtcのrequirementsと同梱のLICENSEで確認)。
| 項目 | 3.0.0-pre.8 | 3.0.0 |
|---|---|---|
| 対応エディタ(ドキュメント) | 2020.3/2021.3/2022.3/2023.1 | 6000.3 |
| 最小Unity(レジストリ) | 2020.3 | 6000.0 |
| Linux | Ubuntu 16.04/18.04/20.04 | Ubuntu 22.04/24.04 |
| macOS | IntelとApple Silicon | Apple Siliconのみ |
| ライセンス | Apache License 2.0 | Unity Companion License |
さらに2026年8月18日、com.unity.webrtcのREADMEの冒頭に「com.unity.webrtc is deprecated.」(非推奨)という注記が追加されました(プルリクエスト#1124)。2026年10月11日時点で、Unityのパッケージレジストリ上の版に非推奨の印は付いておらず、Render Streaming本体のREADMEにも同様の注記はありません。それでも配信の土台が非推奨になった以上、今後の不具合修正や新しいUnityへの追随は期待しにくいと見ておくべきです。Unity 6000.4のPackage Managerで非推奨の警告が表示されたという利用者の報告もあります(Issue #1123)。
Render Streaming 3.1.0-exp.9をそのまま入れると、依存は3.0.0-pre.8で解決されます。Unity 6で正式版のWebRTCを使いたい場合は、プロジェクトの Packages/manifest.json に3.0.0を直接書くと、直接指定した版が優先されます。
{
"dependencies": {
"com.unity.renderstreaming": "3.1.0-exp.9",
"com.unity.webrtc": "3.0.0"
}
}
この組み合わせはRender Streaming側のpackage.jsonが指定する版ではないため、公式に検証された構成ではありません。3.0.0のCHANGELOGに機能やAPIの変更は無く(最小Unityの引き上げ、Android向けlibwebrtcの16KBページサイズ対応、AndroidでVideoStreamTrackが配信を開始できない不具合の修正など)、差し替えの影響は小さいと読めますが、採用前に対象プラットフォームで実機確認してください。Unity 2022.3以前のプロジェクトは3.0.0を入れられないので、pre.8のまま使います。Unity 6系の版ごとの違いはUnity 6.3 LTS(6000.3)の新機能と6.2からの変更点|サポート期限・対応OS・移行の注意点にまとめています。
導入手順|インストールからブラウザ接続まで
対応プラットフォームとブラウザ
| 区分 | 対応 | 非対応 |
|---|---|---|
| 配信側 | Windows x64・Linux・macOS・iOS・Android ARM64 | UWP・WebGL・Android ARMv7 |
| ブラウザ(Windows) | Chrome・Edge(Chromium)・Firefox | WebRTC非対応ブラウザ |
| ブラウザ(Mac・iOS) | Safari・Chrome(Macのみ) | iOSのhttp接続 |
| HWエンコード | NVCODEC(Win・Linux)/VideoToolbox(Mac・iOS)/MediaCodec(Android) | Windows・OpenGL CoreのNVCODEC |
WebGLビルドが非対応なのは、Render Streamingが「サーバーで動くUnityアプリの映像をブラウザへ送る」技術だからです。ブラウザ側に必要なのはWebRTC対応だけで、Unityのビルドをブラウザで動かすわけではありません。軽い3DをWebで見せるだけならWebGLで足ります。違いはWebGLとは?仕組み・できること・対応ブラウザとUnityビルドまで解説を参照してください。
パッケージのインストールとRender Streaming Wizard
Package Managerの「+」から Add package by name を選び(Unity 2020.3では Add package from git URL)、次の名前を入力します。
com.unity.renderstreaming
インストールが終わるとRender Streaming Wizardが自動で開きます。Fix Allを押すと、Input Systemのバックエンド切り替えなど必要なプロジェクト設定がまとめて適用され、エディタの再起動を求められることがあります。設定はProject Settingsの「Render Streaming」パネルに設定アセットとして保存されます。既定で有効なAutomatic Streamingは、再生と同時に画面全体(Screen)を画面解像度で配信し、音声とブラウザ入力の受け口も自動で用意します。
web appの入手|Wizardのダウンロードが404になる場合
公式チュートリアルは、Wizardの「Download latest version web app」でシグナリングサーバーの実行ファイルを取る手順です。ところが3.1.0-exp.9では、このボタンが失敗します。Editor/WebAppDownloader.cs はパッケージの版番号でGitHubリリースのURLを組み立て、失敗すると予備の版3.1.0-exp.8で再試行しますが、exp.9のリリースに置かれた資産はパッケージのtgz1点だけで、exp.8はリリース自体がありません。結果として「Failed downloading web server from: …/releases/download/3.1.0-exp.8/webserver」の404エラーで止まります(Issue #1029で2024年12月から未解決)。
回避策は2つあります。1つ目は、3.1.0-exp.7のリリースページから直接ダウンロードする方法です。webserver.exe(Windows)、webserver(Linux)、webserver_mac(macOS)の3点が置かれており、exp.7のweb appでも動くという報告がIssueに複数あります。2つ目は、リポジトリのWebAppフォルダをNode.jsでビルドする方法です。タグ3.1.0-exp.9のソースで、Node.js v26.5.0(macOS)を使って次の手順で起動でき、トップページと受信用ページ(receiver・bidirectional・multiplay)がすべて応答しました。
git clone --branch 3.1.0-exp.9 https://github.com/Unity-Technologies/UnityRenderStreaming
cd UnityRenderStreaming/WebApp
npm install
npm run build
npm run start -- -p 8080
起動オプションは環境変数 PORT・SECURE・TYPE・MODE でも渡せるので、コンテナに載せるときは引数より扱いやすい方法です。ソースから起動する場合、ポートを変えたらUnity側のシグナリングURLも ws://127.0.0.1:8080 のように合わせます。
シグナリングサーバーの起動とブラウザ接続
実行ファイル版は既定でポート80を使います。主なオプションは次のとおりです。
.\webserver # Windows PowerShell用。Linuxは ./webserver、macOSは ./webserver_mac
.\webserver -p 8080 # ポートを変更(80がIISなどに取られているとき)
.\webserver -s -p 443 # httpsで起動(server.cert と server.key が必要)
.\webserver -t http # シグナリングをHTTPポーリングに変更
.\webserver -m private # 同じ ConnectionId のピア同士だけを接続
サーバーを起動したらUnityエディタで再生し、ブラウザで http://127.0.0.1 を開きます。Receiver Sampleを選んでPlayを押すと、ゲームビューがブラウザに映り、マウスやキーボードの入力がUnityへ届きます。httpsで起動した場合は、Unity側のシグナリングURLも wss:// か https:// に変えないとつながりません。
サンプルシーンの導入と動作確認
自分のシーンで映らないときに原因を切り分けるには、公式サンプルを先に動かすのが早道です。Package Managerで com.unity.renderstreaming を選び、Samplesの「Example」をImportします。Example/Menu/Menu.scene を開いて再生すると、各サンプルを選ぶメニューと、シグナリング方式・ホストアドレス・コーデック・配信解像度を実行中に切り替える画面が出ます。
| サンプル | 内容 |
|---|---|
| Broadcast | 映像と音声を複数の相手へ配信 |
| Receiver | 別のUnityからの映像を受信して表示 |
| Bidirectional | 双方向に映像を送受信 |
| Multiplay | 映像配信を使ったマルチプレイ |
| RenderPipeline | HDRP・URPでの配信 |
| Web Browser Input | ブラウザからの入力でUnityを操作 |
ほかにAR FoundationとGyroscopeのサンプルがあります。ビルドして試す場合は、Build SettingsのScenes in BuildでMenuシーンを先頭に置きます。
空のシーンに手動で組む手順
Automatic Streamingに頼らず配信するカメラや解像度を決めたいときは、コンポーネントを自分で置きます。Project SettingsのRender StreamingでCreate New Settings Assetを作り、Automatic Streamingをオフにしてから、次の順に設定します。
- Main CameraにSignaling Managerを追加する。
- 同じオブジェクトにBroadcastを追加し、Signaling ManagerのHandlerに割り当てる。
- Video Stream Senderを追加し、BroadcastのStreamsに登録してソースのカメラを指定する。
- ブラウザで操作させるならInput Receiverも追加してBroadcastに登録する。
Video Stream Senderの既定値は1280×720・30fps・ビットレート上限1000kbpsです。上限1000kbpsのままだと動きの多いシーンでブロックノイズが目立つので、後述のスクリプトかInspectorで引き上げます(Inspectorで設定できる範囲は0〜10000kbps)。
つながらないときの切り分け
Safari・iOSのHTTPS要件と証明書の制約
SafariとiOS Safariは、httpではWebRTCを使えません。iPadやiPhoneを対象にするなら、webserverをhttpsで起動し、Unity側のURLもwssにするのが必須条件です。さらにiOS Safariは自己署名証明書のサーバーに対してWebSocketシグナリングが通らないため、検証段階では正規の証明書を使うか、シグナリングをHTTPポーリング(-t http)に切り替えて確かめます。
映像未表示・Unity初期化失敗の確認項目
公式FAQが挙げる原因は、ブラウザが古い、ファイアウォールがUDPを止めている、のどちらかです。ブラウザのコンソールとUnityのコンソールの両方を先に確認します。Unity側の初期化が失敗する場合は、使っているGraphics APIがcom.unity.webrtcの要件を満たしているか、ハードウェアエンコーダを有効にしたのにNVCodec非対応のGPUを使っていないか、ドライバが古くないかを疑います。NVCodecに必要なNVIDIAドライバは、WebRTCパッケージのドキュメントでWindowsが456.71以上、Linuxが455.27以上です。ブラウザ上のUnity UIが反応しない場合は、配信中のアプリにフォーカスが当たっているかを確認します。
サンプルのピンク表示・黒画面の原因と対処
Exampleを取り込んだ直後にマテリアルがピンク色になるのは、サンプルのシェーダーとプロジェクトのレンダーパイプラインが合っていないためです。URPのプロジェクトなら Window > Rendering > Render Pipeline Converter でBuilt-inのマテリアルを変換します。RenderPipelineサンプルはURPかHDRPのパッケージが入っていることが前提です。ブラウザ側が真っ黒のままなら、Video Stream Senderにカメラが割り当てられているか、Broadcastに登録されているかを見直します。
本番配置の設計|ビルド済みアプリのサーバー起動条件
batchmodeでは動かない前提と起動引数
コマンドライン引数のドキュメントは、-batchmode と -nographics がRender Streamingでは動かないと警告しています。描画結果をエンコードして送る仕組みなので、GPUと画面出力を持つ環境でアプリを起動する必要があります。ヘッドレスのサーバーでバッチ実行する一般的なUnityサーバーの作り方は使えません。
配置先ごとに変わるシグナリング先やTURNの認証情報は、Windows・macOS・Linuxのビルドなら起動引数で上書きできます(モバイルは非対応)。
MyApp.exe -signalingType websocket -signalingUrl ws://10.0.0.5:8080 ^
-iceServerUrl turn:turn.example.com:3478?transport=udp ^
-iceServerUsername user -iceServerCredentialType password -iceServerCredential pass
rem 同じ内容をJSONファイルで渡す(このブロックはWindowsのcmd.exe用)
MyApp.exe -importJson config.json
Run On Awakeで引数が効かない不具合と回避コード
手動で置いたSignaling ManagerのRun On Awakeを有効(既定)にしていると、上の起動引数が無視されます。タグ3.1.0-exp.9のSignalingManager.csを読むと、Awake()がProject Settingsの値からシグナリングとRTCConfigurationを先に作って内部の起動処理へ渡しており、起動処理の中で引数を評価しても、渡されたオブジェクトが優先されて使われません。Issue #1012で報告され、修正のプルリクエスト(#1036)は2026年10月時点でマージされていません。Automatic Streamingは引数なしでRun()を呼ぶため、この不具合を受けません。
回避するには、Signaling ManagerのRun On Awakeをオフにし、自前のスクリプトから引数なしの Run() を呼びます。ソースの流れでは、引数なしで呼ぶと起動引数を評価した後の設定からシグナリングが作られます(Evaluate command line argumentsは有効のまま)。Unity実機での検証ではないため、自分のビルドで、指定したシグナリング先とICE設定がログに反映されるかを確認してから本番に使ってください。
using Unity.RenderStreaming;
using UnityEngine;
// Signaling Manager の Run On Awake はオフにしておく
// StreamingBootstrap.csとして保存し、シーン内の有効なGameObjectに追加する
// InspectorでsignalingManagerとvideoStreamSenderに対象コンポーネントを割り当てる
public class StreamingBootstrap : MonoBehaviour
{
[SerializeField] SignalingManager signalingManager;
[SerializeField] VideoStreamSender videoStreamSender;
void Start()
{
// 配信開始前に解像度とビットレート(kbps)を決める
videoStreamSender.SetTextureSize(new Vector2Int(1920, 1080));
videoStreamSender.SetBitrate(2000, 6000);
// 引数なしの Run は起動引数を評価してからシグナリングを作る
signalingManager.Run();
}
}
SetBitrate は最小値が最大値を超えると例外になり、SetCodec は配信開始後に呼ぶと例外になります。コーデックを固定したい場合も、このStartの中で Run() より前に設定します。
配信マシン1台の接続人数とエンコード上限
公式FAQは「新しいデスクトップPCなら720pの映像を約5台まで送れるが、それ以上はSFUの配信サーバーが必要」と書き、simulcastにも対応していないと明記しています。ハードウェアエンコードには同時エンコード数の上限もあり、WebRTCパッケージのドキュメントには「GeForceでは一般に同時2トラックまで、サーバー向けGPUでは通常4トラック」という古い説明が残っています。現行のNVIDIAのVideo Encode and Decode Support Matrixでは、GeForce RTX 4090・5090の同時セッション上限が12、データセンター向けのTesla T4・L4は制限なしです。いずれもエンコードのセッション数で、快適に捌ける接続人数とは別の指標なので、採用するGPUで実測して台数を決めてください。
つまりRender Streamingは、多数の視聴者へ同じ映像を一斉に配る用途には向きません。1人か少人数が操作するセッションを、人数分のインスタンスで供給する設計になります。多人数への配信が目的なら、SFUを持つ配信基盤(100ms.liveとは?WebRTC・HLSのライブ動画SDKの料金と上限、導入手順【2026年9月】で扱うようなSDK)か、一方向のライブ配信を検討します。
ホスティングの選択肢|Furioos終了後の候補と料金
Unityはかつて、ビルドをアップロードするだけで配信できるマネージドサービスFurioosを提供していましたが、すでに終了しています。パッケージ側の連携も3.1.0-exp.7(CHANGELOG上は2023年8月9日)で「Removed Furioos Integration」として削除済みで、2026年10月時点ではfurioos.comも応答しません。Furioosを前提にした解説は使えません。
もう1つ押さえておくべきなのが、公式FAQの「GCPのようなクラウドにUnityをレンダリングサーバーとしてデプロイできるか」への回答です。Unityは「レンダリングサーバーとしての利用はサポートしていない」と答えています。クラウドで常時稼働させる構成は、動くかどうかとは別に公式サポートの対象外で、トラブルは自力で切り分ける前提になります。そのうえで現実的な選択肢は次の4つです(料金は2026年10月11日に各社の公式ページで確認)。
| 選択肢 | 料金の目安 | 課金の軸 |
|---|---|---|
| 自前GPUインスタンス | クラウドのGPU単価次第 | インスタンス稼働時間 |
| Vagon Streams | Tesla T4で0.025〜0.035米ドル/分+地域ごとの維持費0.67米ドル/日 | 分単位の利用量 |
| PureWeb Reality | CORE:年契約で月額750米ドルから | 稼働時間か利用者のストリーミング時間 |
| ZeroLight OmniStream | 3米ドル/時から(前払いクレジット) | 実際に配信した時間 |
Vagon Streamsは利用料とは別にBasic(無料)・Pro(月額99.99米ドル)・Enterprise(月額249米ドル)のプランがあります。PureWeb RealityはUnreal EngineとUnityのプラグインを用意したフルマネージド型、OmniStreamは基準のハードウェアで1クレジット=1時間、未使用分は12か月で失効します。選定の分かれ目は同時接続のピークが読めるかです。常時稼働の台数を固定できる場合は自前構築の運用費も含めて比較し、展示会やキャンペーンのようにピークが跳ねる場合は、商用サービスの同時接続枠、待機料金、最低契約額を含めた見積もりと比較します。
Render Streamingを採用すべきでない場面もはっきりしています。数十人以上が同じ映像を見るイベント用途はSFU無しでは破綻します。軽量な3Dを見せるだけならWebGLで足ります。長期保守が前提でパッケージの不具合を自分で直す余力が無い案件は、本体の更新が止まり依存のWebRTCパッケージも非推奨になった現状を踏まえ、Unreal Pixel Streaming 2や上の商用基盤を含めて比較し直す価値があります。逆に、GPUを積めない端末へ高品質な3Dを届けたい、少人数がインタラクティブに操作する、という条件がそろうなら、公式パッケージで導入が速い点が効きます。Unityで配信まで含めたアプリを組む場合は、ゲームアプリ開発の支援もご相談いただけます。
よくある質問
Unity Render Streamingの最新バージョンは?
3.1.0-exp.9です。CHANGELOG上のリリース日は2024年12月13日で、2026年10月時点で後続の版は出ていません。中身はWebRTCパッケージを3.0.0-pre.8へ上げた更新とAPIドキュメントの改善です。
Unity 6で使えますか?
公式の対応表にUnity 6は載っておらず、動作保証は明記されていません。依存先のcom.unity.webrtcは3.0.0でUnity 6000.0以上が必要になったので、Unity 6ではmanifest.jsonで3.0.0を直接指定する選択肢がありますが、Render Streaming側が検証した組み合わせではないため、対象プラットフォームでの実機確認が前提です。com.unity.webrtc自体も2026年8月にREADMEで非推奨とされています。
WebGLビルドでRender Streamingは使えますか?
使えません。公式FAQはUWPとWebGLを非対応と明記しています。Unityアプリは配信する側のマシンで動き、ブラウザはWebRTCで映像を受け取るだけです。
ソースコードやサンプルはGitHubのどこにありますか?
Unity-Technologies/UnityRenderStreaming に、パッケージ本体(com.unity.renderstreaming)、シグナリング用のWebApp、HDRP用のプロジェクトテンプレートがまとまっています。サンプルはパッケージに同梱されており、Package ManagerのSamplesからImportします。不具合報告と要望もこのリポジトリのIssuesが窓口です。
同時に何人まで接続できますか?
公式FAQの目安は、デスクトップPC1台から720p映像を約5台までで、それ以上はSFUの配信サーバーが必要です。simulcastには対応しておらず、NVIDIA GPUのハードウェアエンコードにも同時トラック数の上限があります。