For the complete documentation index, see llms.txt. This page is also available as Markdown.

Video Configuration

Set limits for managed video workers and configure server-side video sources in self-hosted Inference.

Configure video workers on the server that runs them. These settings cover the integrated stream manager; they do not set limits on the managed Serverless Video Streaming API or a local Python InferencePipeline.

See Security Configuration Migration for version scope.

Managed pipeline limits

STREAM_MANAGER_MAX_ACTIVE_PIPELINES defaults to 8 and caps the total managed pipeline processes, including busy and idle workers. The effective cap is the larger of the configured value and STREAM_API_PRELOADED_PROCESSES, so it cannot fall below the number of preloaded workers.

Variable
Default
Behavior

STREAM_MANAGER_MAX_ACTIVE_PIPELINES

8

Limits managed pipeline processes, raised to the preload count when needed.

STREAM_API_PRELOADED_PROCESSES

0 in the core library; images may override it

Sets the target number of warm idle workers.

STREAM_MANAGER_MAX_RAM_MB

Unset

Optionally rejects new pipeline allocation based on measured and estimated RAM use.

At the process cap, the manager can reuse an idle worker but refuses to spawn another process. The background warm pool also respects the cap; a busy worker consumes a slot even when the target idle count has not been reached.

Set capacity

Pass capacity settings through an environment file when starting the server:

STREAM_MANAGER_MAX_ACTIVE_PIPELINES=16
STREAM_API_PRELOADED_PROCESSES=2
inference server start --env-file inference.env

Choose a positive cap that fits your model and hardware, and terminate unused pipelines before increasing it. This is a process limit, not a per-user quota, a request rate limit, or a hard RAM or GPU memory limit.

Server-side video references

The rules in this section apply to the pending runtime-hardening build in the migration guide. Standard stream manager and enterprise stream request schemas validate the supplied media reference before it reaches the video backend.

Supported inputs are:

  • Integer camera indices, such as 0, and numeric CSI references, such as csi://0.

  • Absolute or explicit relative paths, such as /video.mp4, ./video.mp4, ../video.mp4, or Windows drive paths.

  • Encoded URLs using http, https, rtsp, rtsps, rtspt, rtspst, rtmp, rtmps, udp, srt, rtp, tcp, or file.

  • Lists of supported references where the request schema permits them.

The chosen image must provide a decoder for the transport, and paths must be readable inside the server container. This validation does not restrict camera network destinations; image URL controls are a separate policy.

Update existing references

Write video.mp4 as ./video.mp4. Encode whitespace and quotes in URLs, and rename local paths containing !, =, or quotes; unsupported schemes and raw GStreamer descriptions are rejected by default.

Use raw GStreamer pipelines

For trusted workloads that require raw launch syntax, set:

This bypasses the media-reference validation and restores raw pipeline interpretation, including the capabilities of installed plugins. Supported RTSP and RTMP URLs do not need this opt-in, and it does not install missing GStreamer plugins.

Client-side video sources

These checks apply to references sent to the server's stream request schemas. They do not rename files opened locally by SDK VideoFileSource or change direct local Python media use.

See Video processing with Workflows for choosing where video is opened, and server security for who can manage pipelines.

Last updated

Was this helpful?