Stream-density: support per-stream input FPS and per-stream pass/fail threshold (heterogeneous use cases)

[jcork-intel]

Summary

benchmark-stream-density currently evaluates every stream in a use case against a single shared throughput target and assumes a uniform input frame rate across all streams. Many real-world multi-camera use cases are heterogeneous — different cameras run at different frame rates and have different acceptable-throughput bars. This requests per-stream (per-camera / per-workload) input FPS and pass/fail threshold, so the stream-density threshold reflects each stream's own requirement.

Motivation

Several of the Automated Self-Checkout (ASC) and Loss Prevention use cases are inherently multi-camera with mixed frame rates. Example — ASC Age Verification:

• an object / basket camera at 15 fps (target ~14.95 fps), plus
• a face / age camera that in a real deployment is a CCTV-style feed at roughly 5 fps (a face isn't a fast-moving target, and operators won't ingest it at 15 fps).

Today both streams are forced to the same input FPS and the same target threshold. This (a) doesn't model the real deployment, and (b) under-reports density — holding the face camera to 15 fps caps the lane lower than it would be in practice.

Current behavior

• Input frame rate is applied uniformly across streams.

• The stop criterion compares every stream's measured FPS to one shared target_fps (in stream_density.py, run_pipeline_iterations):

  all_streams_meet_target = all(fps >= target_fps for fps in stream_fps_dict.values())

  There is no per-stream target, and no per-stream input rate.

Requested behavior

• Per-stream input FPS, sourced from the camera/workload config (e.g. camera_to_workload_*.json).

• Per-stream throughput threshold; "pass" = every stream meets its own threshold:

  all_streams_meet_target = all(
      fps >= targets[stream_id] for stream_id, fps in stream_fps_dict.items()
  )

  where targets is derived per stream and defaults to the global target_fps when a per-stream value isn't specified (backward compatible).

• Preserve the combined-pipeline / multi-stream-unit semantics (streams that increment together stay together).

Example (illustrative) — ASC Age Verification

camera	workload	input fps	target fps
cam1	face detect → age/gender	5	~5
cam2	object detect → classify	15	14.95

Benefit

• Models real heterogeneous deployments instead of a uniform-FPS assumption.
• Produces a more representative (and typically higher) stream-density number for published benchmarks.

Notes

• The multi-value --target_fps argument already exists (benchmark.py --target_fps 14.95 8.5 …, mapped 1:1 to --container_names), so some plumbing may be reusable — this request extends it to per-stream within a single use case, plus a per-stream input FPS.
• Threshold logic lives here in performance-tools; the input-FPS side also touches the consuming repo's camera/workload config (e.g. loss-prevention).

[jcork-intel]

@avinash-palleti --> I believe this is the one we discussed the other night.

[avinash-palleti]

Yes @jcork-intel, this is same one.
But with the permutations that are possible with lossprevention this will become complex. I mean we have both camera and workload configurable and this will lead to n*n combinations. FPS threshold is per workload or per input camera?
We will explore possibilities and come back on this.