JSI · Physical Security Engineering · Project EGA
Three measured runs on the trailer machine, with every camera live. How many cameras fit, what happens when you push the frame rate, and the second limit we were not watching until it stopped the machine.
Nine paired cameras run comfortably at 55% of the machine.
That is nine cameras annotated by EGA and nine recorded by GeoVision, on one trailer computer. A camera only counts if it reaches both: EGA draws the detection box, and the recorder is the path to the monitoring centre. A camera in one but not the other reaches no operator at all.
We tried raising the frame rate and it does not scale. Nine cameras at the current settings is a good place to sit.
Of the whole machine, with all nine annotated and all nine recorded.
About a sixth of one of the machine's four processor cores.
18% more frames cost 28 points of processor. It does not scale.
Fixed, not growing. Memory turned out to be a real limit too.
Three runs on the machine in the trailer, every camera live and publishing, sampled every ten seconds.
| Run | Cameras | Frame rate | Processor | Clock | |
|---|---|---|---|---|---|
| A | 7 | 11 fps | 44% | 2261 MHz | comfortable |
| B | 9 | 11 fps | 55% | 2140 MHz | comfortable |
| C | 9 | 13 fps | 83% | 1675 MHz | no headroom |
| Nine cameras at 11 fps | Mean | p95 |
|---|---|---|
| EGA — drawing the boxes on nine streams | 27.0% | 29.0% |
| GeoVision — recording nine streams | 16.8% | 19.5% |
| Everything else | 8.4% | 11.9% |
| Total | 55.3% | 70.0% |
Each paired camera costs about 4.4% of the machine. Activity barely changes it: with people crossing, EGA measured 27.2% against 27.0% idle. The work is decoding, drawing and re-encoding every frame, and that happens whether the scene is empty or not.
We raised all nine cameras from 11 to 13 frames per second — 18% more frames. It cost 28 points of processor, taking the machine from 55% to 83%, with peaks touching 100%.
The processor slows itself down as it gets busy. It held 2140 MHz at 11 fps and only 1675 MHz at 13 fps. Every frame then took more processor time, which raised the load further, which lowered the clock again. Correcting for the clock, EGA itself scaled below the frame increase, as it should. The machine, as a whole, did not.
The lesson matters more than the number: this machine does not degrade smoothly. Estimating in a straight line works while there is room and stops working near the top. We projected 60% for this run and measured 83%. That is now known by measurement rather than assumed, which is why we would not go beyond about twelve cameras without testing first.
The cameras run at D1, which is 704 by 480 pixels. The next size up available on the stream EGA uses is 720p, at 1280 by 720. That is 2.7 times as many pixels, and the work scales with pixels almost exactly — we confirmed it: the PTZ camera, which runs at 720p because it cannot go lower, cost 2.72 times what a D1 camera cost on the same machine against a 2.73 ratio in pixels.
| Format | Pixels | Against D1 | Available on EGA's stream? |
|---|---|---|---|
| 720p | 921,600 | 2.73× | Yes |
| D1 — in use today | 337,920 | 1.00× | Yes |
| VGA | 307,200 | 0.91× | Yes — saves almost nothing |
| CIF | 84,480 | 0.25× | Only on the other stream |
Moving all nine cameras to 720p is not possible. It would take EGA from 27% to roughly 62% and the recorder from 17% to roughly 38% — about 109% of a machine that only has 100%.
Moving them one at a time is possible. Each camera raised from D1 to 720p costs about 7 points of the machine — roughly four and a half for EGA and two and a half for the recorder. Starting from 55%, arithmetic says three or four cameras could be raised before reaching a sensible ceiling.
“Three or four” is a straight-line estimate, and a straight-line estimate is exactly what failed on the frame-rate test above: we projected 60% and measured 83%. The same slowdown would apply here. The honest answer is that one or two cameras at 720p is safe, and anything beyond that should be measured before it is promised. Memory adds a second reason for caution — a 720p frame is 2.7 times the bytes of a D1 one, and committed memory is already at 75%.
So the useful question is not “can we raise them all?” but “which one or two actually need the extra detail?” That is a decision about what each camera is watching, not a capacity calculation.
This processor contains a dedicated video engine — Intel calls it Quick Sync. It is not the graphics chip doing general work: it is fixed-purpose silicon that compresses and decompresses video without using the processor cores at all. Using it where we can is the single biggest reason nine cameras fit on a machine this small.
Compression is on the hardware, and we verified it directly rather than assuming: all nine encoder processes have Intel's hardware video library loaded. It is also self-proving — the software is told to use the hardware encoder explicitly, and if the hardware were unavailable it would fail to start rather than quietly fall back.
| Step | Cost, 9 cameras | Runs on | Why |
|---|---|---|---|
| Decompress each camera's video | 12.3% | processor | The library we read the cameras with does not ask for the hardware. This is the largest single thing we are leaving on the table. |
| Draw the detection box | included above | processor | The box position arrives from the camera with each event, so the picture has to be in ordinary memory to draw on it. This one is structural, not an oversight. |
| Convert the picture format before compressing | part of 13.2% | processor | We hand the compressor a picture in the wrong colour format, so it converts it in software before passing it to the hardware. |
| Compress the annotated video | 13.2% | hardware | Already done. |
Roughly half of EGA's cost is compression, which is already on the hardware, and half is decompression and drawing, which are not. Meanwhile the video engine itself is barely busy: we measured its decode unit at about 6% and the rest of it idle, while the processor was the thing running out.
The video engine can decompress as well as compress, so the obvious question was whether moving that 12.3% onto the hardware would free the processor. The hardware does the job — we confirmed the video engine was genuinely being used, not silently ignored. It is simply more expensive than doing it in software.
On a single camera the difference is invisible. It is under two thousandths of a second per picture, which does not move any figure you would see on screen. That is why we measured processor time per picture rather than watching the overall load — a difference that small only becomes visible once it is multiplied by nine cameras and eleven pictures a second.
| Picture size | Software | Hardware | Difference |
|---|---|---|---|
| D1 — the eight ordinary cameras | 1.88 ms | 3.56 ms | 1.9× worse |
| 720p — the PTZ | 6.25 ms | 8.05 ms | 1.3× worse |
Across nine cameras at eleven pictures a second, that works out to roughly four points of the machine spent rather than saved — EGA would go from 27% to about 31%. Not a disaster, but the opposite of the point.
The hardware decompresses into the graphics chip's own memory. Our software then has to draw a box on that picture, and it can only draw on a picture held in ordinary memory — so every frame has to be copied back out of the graphics chip and converted into the colour format our drawing code understands. For pictures this small, that return trip costs more than simply decompressing them on the processor in the first place.
The measurements show that plainly: the penalty shrinks as the picture grows — 1.9 times worse at D1, 1.3 times at 720p — because the decompression saved grows faster than the copy back. The break-even point is above any size we use.
So this door is closed, and closed cheaply: an afternoon of measurement rather than a rebuild that would have delivered nothing. The only way to genuinely remove that cost would be to decompress, draw and compress entirely inside the video engine so the picture never comes back at all — a rebuild of how EGA draws, and not something to start before the unattended-operation work is done.
Earlier this week the machine ran out of memory and half the camera feeds stopped without any visible warning. Task Manager showed memory at 52%, which looked comfortable — but that is not the figure that matters. The relevant one, committed memory, was at its ceiling, because the machine had no paging file configured at all.
| With nine cameras running | Measured |
|---|---|
| Committed memory, during the runs above | 12.6 of 16.7 GB — 75% |
| Physical memory available | 8.8 GB |
| GeoVision, across 55 processes | 4.4 GB |
| EGA, across 11 processes | 1.75 GB — 195 MB per camera |
| Ceiling after the fix | 23.7 GB — same load, 53% |
Note the trap in the first two rows: 8.8 GB of physical memory free while committed memory sits at 75%. A machine can look idle by one measure and be at its ceiling by the other.
Memory does not grow over time. Across a 30-minute run at full load EGA's memory moved by 4 MB, and across a 9.5-hour overnight run it did not grow at all. This is a fixed cost, not a leak — which matters, because a trailer runs for months without anyone looking at it.
This has since been fixed. An 8 GB paging file was configured and the machine restarted, which raised the ceiling from 16.7 GB to 23.7 GB. The same load that filled 75% of the old ceiling now fills 53% of the new one, and the spare capacity went from 4.2 GB to 11 GB.
Four things published here before were wrong. All four are corrected above.
| What it said | What is true |
|---|---|
| Per-camera costs, in the original figures | They were about 25% too high. Our measuring script divided by the intended sampling interval instead of the time that actually elapsed. We caught it because the individual programs summed to more than the whole machine, which is impossible. |
| “The cameras do not offer CIF; the option is closed” | They do offer it — on every camera, including the PTZ. It is simply not available on the particular stream EGA uses today. Using it would mean reassigning streams between EGA and the site's other AI system. |
| “Whether the recorder carries every camera is a policy decision” | It is not. The recorder is how alarms reach the monitoring centre. A camera not in it reaches nobody, whatever is stored on the camera's own card. |
| Processor use, presented as the constraint | Memory was the limit that actually stopped the machine, while the processor was comfortable at 44%. The report measured only one of the two. |