Eight streams running a person detector at 5 FPS ask something different from eight streams running that detector at 24 FPS. Add a classifier after detection and the amount of work can change with the number of people in view. Even counting the model stages can mislead you if two tasks reuse the same detector output.

CosmoEdge is an open-source edge video analytics engine. Its published v1.1 RK3576 tests make these differences visible. One mixed workload passed through eight channels. A person-detection run targeting 24 FPS first failed its throughput requirement at seven. The useful question is how those conclusions were obtained, and what each number actually measures.

Define one channel before multiplying it

The mixed workload assigns two tasks to every channel:

• Person detection, with one detector stage.
• No-safety-helmet analysis, with a detector followed by a classifier.

Both tasks target 5 FPS. The model contract records a 640 × 640 detector input and 224 × 224 person crops for helmet classification.

Figure 1. Logical tasks, runtime reuse, and measurement points in the inspected source. Detector reuse requires the same algorithm and channel.

At eight channels, that is sixteen task bindings and three logical model stages per channel. Multiplying 8 × 2 × 5 gives a target of 80 task-frame updates per second. It does not give the number of accelerator invocations.

There is a concrete reason. In the recorded engine source, detector placement reuses the existing detector when the algorithm and channel match. The detector runs on its input frames, then distributes the result to task queues with task-specific confidence filtering. Its rate budget uses the highest requested task FPS on that channel. Two matching 5 FPS bindings therefore contribute 5 FPS to that detector budget, rather than 10.

Classification scales differently. The classifier path collects eligible targets, skips filtered or out-of-area targets, and classifies the remaining crops. The downstream workload depends on how many targets survive. A quiet entrance and a shift change can stress the same configuration differently.

Follow the clocks through the pipeline

A camera’s frame rate, a task’s processing rate, and an event rate are three different clocks.

The test input runs at 24 FPS. The mixed tasks request 5 FPS. Rate-controlled frame selection happens on the processing path; frames deliberately skipped there should not be read as queue-overload losses. Meanwhile, video access and decoding still have work to do, and opening a preview adds another consumer.

The benchmark obtains CV throughput from queue counters. For each action, it divides the queue’s processed-item count by its reported interval. That counter advances when an item is removed for processing. It then takes the slowest effective frame-processing action for each task/channel binding. The sampler explicitly handles a subtle trap: a shared detector’s counter can contain aggregate work and appear in several task records. Adding those counters would overstate throughput.

Event Report is excluded from this FPS floor. That makes sense: a healthy helmet task might process frames continuously and produce no violation event for an hour. Treating its alarm rate as inference throughput would make the quietest scene look like a failure.

This also explains why a task reporting 5 FPS is not enough to establish how quickly an operator receives an alarm. Frame processing, temporal rules, capture, and downstream delivery need separate observations.

Increase load with a declared pass condition

For the short runs, the published protocol adds one channel per step, holds it for 30 seconds, and samples roughly every three seconds. The report uses the second half of each step as its steady window.

The processing-FPS gate is 80% of the requested rate. For a 5 FPS task, the floor is 4 FPS; for a 24 FPS task, it is 19.2 FPS. The remaining gates cover missing telemetry, discard rate, and the reported node-duration metrics: no missing task telemetry, average discard at most 5%, detector duration at most 150 ms, and critical-path duration at most 200 ms when available.

That 80% threshold deserves attention. A configuration can pass while delivering less than its configured target. If an application needs 24 processed frames per second on every channel, its acceptance threshold should say so.

The setup was an RK3576 EVB using RKNN inference and Rockchip MPP/RGA media. Each channel replayed the same 15-second H.264 1920 × 1080, 24 FPS clip locally, with preview disabled. These conditions apply to the curves below.

Figure 2. Recorded processing rates at each load step. Dashed amber lines show the 80% FPS gates; gray dotted lines mark the targets. The panels use different vertical scales.

Read the last passing step carefully

The canonical RK3576 records contain all eight steps of the mixed run. Every step passes. At eight channels, the minimum reported rates are 5.08 FPS for person detection and 5.07 FPS for helmet analysis, with zero reported missing telemetry and discard.

Eight was the highest configured step. The result establishes a lower bound of eight passing channels for this workload. There is no ninth-channel failure in that run from which to infer a maximum.

The 24 FPS person-only run provides a different kind of result. It reports 24.23 FPS at five channels, 21.55 at six, and 18.95 at seven. Six passes the 19.2 FPS floor. Seven falls below it and is marked FAIL.

The run continued to eight, where it reports 16.46 FPS and STOP, with a discard-protection reason. The first failed report gate and the point where execution stopped are different rows. Keeping both matters: reporting only the final stop would hide where the declared throughput requirement was first missed.

This is why “six channels” and “at least eight channels” can both be correct for the same platform. The task mix, requested rates, and acceptance threshold are part of the answer.

What the latency fields actually contain

At eight channels in the mixed run, the report gives 24.0 ms for detector duration. Its critical-path fields are 25.7 ms for person detection and 45.1 ms for helmet analysis.

The latency reducer builds those values from node-duration telemetry. For the critical path it adds selected node mean durations. The step evaluator averages the sampled values per binding, then takes the largest binding average.

So 45.1 ms is a summary of processing time in the selected nodes. It is neither a P95 nor a capture-to-event stopwatch measurement. Queue waiting and a rule that requires a condition to persist can make an event arrive much later.

Those fields are still useful. In the 24 FPS run, the detector-duration summary rises from 24.0 ms at one channel to 47.3 ms at six and 55.2 ms at seven, alongside falling processing FPS. That shows degradation as load rises. Identifying its exact cause would require further profiling of scheduling, media work, and inference.

Hold a chosen workload over time

A staircase test helps locate a throughput boundary. A longer run asks whether a chosen configuration continues operating.

The separate 72-hour RK3576 observation held eight channels and sixteen mixed-task bindings at 5 FPS per task. It collected 4,316 of 4,320 expected minute samples, with a minimum processing rate of 5.00 FPS and an average of 5.098 FPS. Observed discard and missing-binding counts were zero.

Sampling coverage belongs beside the FPS result. Otherwise, a stable average could hide a gap in observation. Here the largest reported gap was about 60.06 seconds, close to the one-minute sampling interval.

This run used a different recorded source revision and kept scheduled restarts disabled. It adds sustained-processing evidence for its fixed configuration. Camera reconnection and restart recovery remain separate tests for the actual installation.

Turn the result into a deployment decision

For an existing IP camera that supplies a compatible stream, start by writing down the resolution, codec, task mix, requested rates, and acceptable delay. Include the busiest useful clip, not only the cleanest demo scene.

Then repeat the load steps with your models and settings. Keep per-task results so one fast task cannot conceal a slow one. Record the first failed requirement as well as the eventual stop, and run the intended operating load for longer with the previews and output integrations people will actually use.

Visual orchestration is useful at this point. CosmoEdge’s pipeline view makes the detection, filtering, classification, and rule chain inspectable. Moving a filter or changing which targets reach the classifier changes the workload; save that configuration with the result and rerun the test.

A useful capacity answer includes the workload and the curve behind it. For these records: at least eight mixed-task channels at the 5 FPS setting passed, while the 24 FPS person-only run first missed its 80% throughput requirement at seven. That is enough detail to start an engineering discussion about a deployment.

To try a workload of your own, start with the CosmoEdge repository and quickstart.