> For the complete documentation index, see [llms.txt](https://docs.roboflow.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.roboflow.com/deployment/ja/self-hosted/inference-server/configuration/video-configuration.md). # 動画設定 管理対象の動画ワーカーの上限を設定し、self-hosted Inference でサーバー側の動画ソースを構成します。 ビデオワーカーは、それらを実行するサーバー上で構成します。これらの設定は統合ストリームマネージャーを対象とし、管理対象の Serverless Video Streaming API やローカルの Python InferencePipeline には制限を設定しません。 参照 [セキュリティ設定の移行](/deployment/ja/self-hosted/inference-server/configuration/security-migration.md#release-status) バージョンの適用範囲について。 ## 管理対象パイプラインの制限 `STREAM_MANAGER_MAX_ACTIVE_PIPELINES` の既定値は `8` また、稼働中および待機中のワーカーを含む管理対象パイプラインプロセスの合計を上限化します。実効上限は、設定値と `STREAM_API_PRELOADED_PROCESSES`のいずれか大きい方となるため、事前読み込み済みワーカー数を下回ることはありません。
変数デフォルト動作
STREAM_MANAGER_MAX_ACTIVE_PIPELINES8管理対象パイプラインプロセスを制限し、必要に応じて事前読み込み数まで引き上げます。
STREAM_API_PRELOADED_PROCESSESコアライブラリでは 0。イメージが上書きできる場合がありますウォームなアイドルワーカーの目標数を設定します。
STREAM_MANAGER_MAX_RAM_MB未設定計測値および推定RAM使用量に基づいて、新しいパイプライン割り当てを任意で拒否します。
プロセス上限に達すると、マネージャーはアイドルワーカーを再利用できますが、別のプロセスの生成は拒否します。バックグラウンドのウォームプールもこの上限に従い、目標アイドル数に達していなくても、稼働中のワーカーはスロットを1つ消費します。 ### 容量を設定 サーバー起動時に、容量設定を環境ファイル経由で渡します: ```dotenv STREAM_MANAGER_MAX_ACTIVE_PIPELINES=16 STREAM_API_PRELOADED_PROCESSES=2 ``` ```bash inference server start --env-file inference.env ``` モデルとハードウェアに合う正の上限を選び、増やす前に未使用のパイプラインを終了してください。これはプロセス上限であり、ユーザーごとのクォータ、リクエストレート制限、またはRAM/GPUメモリのハード上限ではありません。 ## サーバー側のビデオ参照 このセクションのルールは、次の runtime-hardening ビルドに適用されます: [移行ガイド](/deployment/ja/self-hosted/inference-server/configuration/security-migration.md#video-source-validation)。標準の stream manager および enterprise stream request スキーマは、提供されたメディア参照がビデオバックエンドに到達する前に検証します。 サポートされる入力は次のとおりです: * 整数のカメラインデックス。例: `0`、および数値の CSI 参照。例: `csi://0`. * 絶対パス、または明示的な相対パス。例: `/video.mp4`, `./video.mp4`, `../video.mp4`、または Windows のドライブパス。 * 次を使用したエンコード済みURL: `http`, `https`, `rtsp`, `rtsps`, `rtspt`, `rtspst`, `rtmp`, `rtmps`, `udp`, `srt`, `rtp`, `tcp`、または `file`. * リクエストスキーマで許可されている場合の、サポートされる参照の一覧。 選択したイメージは、その伝送方式用のデコーダーを提供している必要があり、パスはサーバーコンテナ内から読み取り可能でなければなりません。この検証はカメラのネットワーク宛先を制限するものではありません。イメージURLの制御は別のポリシーです。 ### 既存の参照を更新 書き込み `video.mp4` として `./video.mp4`。URL内の空白と引用符はエンコードし、次を含むローカルパスは名前を変更してください `!`, `=`、または引用符。サポートされていないスキームと生の GStreamer 記述は、既定で拒否されます。 ### 生の GStreamer パイプラインを使用 生の起動構文を必要とする信頼済みワークロードの場合は、次を設定します: ```dotenv ALLOW_UNSAFE_GSTREAMER_PIPELINES=True ``` これによりメディア参照の検証がバイパスされ、インストール済みプラグインの機能を含む生のパイプライン解釈が復元されます。サポートされる RTSP および RTMP の URL にはこの明示的な有効化は不要であり、欠落している GStreamer プラグインはインストールされません。 ### クライアント側のビデオソース これらのチェックは、サーバーのストリームリクエストスキーマに送信される参照に適用されます。SDK によってローカルで開かれたファイル名は変更しません `VideoFileSource` また、直接のローカル Python メディア使用も変更しません。 参照 [Workflows によるビデオ処理](https://docs.roboflow.com/workflows/deploy/video-processing) ビデオをどこで開くかを選ぶため、および [サーバーのセキュリティ](/deployment/ja/self-hosted/inference-server/configuration/security.md) パイプラインを管理できる人について。