JSI · Physical Security Engineering · Project EGA
Watchtower currently gets its live pictures from GeoVision's mobile server, which costs the trailer machine 18–20% of its processor while a client is watching. The gateway already holds every camera stream. Could it serve them instead, and would that be cheaper?
The bandwidth comparison on this page is wrong, and so is its conclusion. It used 1.3 MB per minute per camera for GV-Mobile Server. Measured directly on 16 September, Mobile Server sends each camera at 640×480 and 15 frames a second — 1.0–2.1 Mbps, 7–16 MB per minute, at night — and keeps sending a still logo at 1.4 Mbps on empty channels. The same evening the cellular link carried 3 Mbps (about 23 MB per minute) without losing a frame, not the 7–8 MB per minute given below. The gateway's live view, built since, served all nine cameras in 1.87 Mbps in total. WebRTC and HLS on the streaming server, mentioned below, have since been switched off as part of closing it to the internet. Measurements and the test portal are on the status page; the rest of this page is kept as written.
Yes on processor, and by a wide margin — but the obvious way of doing it would not fit down the cellular link.
The processor cost disappears because the gateway has already done the expensive work. The bandwidth cost multiplies by seven, against a link that is already close to its ceiling during a viewing session. There is a way round that, and it is not difficult, but it has to be built deliberately rather than assumed.
Watchtower receives MJPEG — a stream of individual JPEG photographs, about fifteen a second, one connection per camera. For every one of those pictures the mobile server has to decode the camera's compressed video and then compress the result again as a JPEG, separately for every camera and every watching client.
That is the 18–20%. It is not overhead — it is the actual work of converting video into photographs, over and over, in software.
The gateway publishes every annotated camera into a small streaming server that runs beside it, and that server already speaks the protocols a phone or browser can play directly — WebRTC and low-latency HLS are both enabled today, alongside the RTSP the recorder uses.
Serving Watchtower from there means forwarding video that is already compressed. No decoding, no re-compressing, nothing per-client beyond moving packets. The compression that did happen was done once, by the graphics chip, for the recorder's benefit — and it is reused rather than repeated.
The whole gateway — nine cameras decoded, annotated and re-compressed — costs 27% of the machine. Adding a viewer to a stream that already exists costs a fraction of one camera's share. The 18–20% would essentially go away, and it would stop scaling with the number of people watching.
Compressed video is far larger than the small JPEGs the mobile server is sending. Both figures below are measured, not estimated — the first from Watchtower's own bandwidth testing, the second from a recording of the gateway's live output.
| Per camera, while someone is watching | Bandwidth |
|---|---|
| MJPEG from the mobile server, as measured (wrong — 7–16 MB/min measured 16 Sep) | |
| The gateway's video as it stands today | 8.97 MB/min |
| — about seven times as much — | |
| Six cameras at once | 54 MB/min |
| Nine cameras at once | 81 MB/min |
| What the cellular link has been measured to carry (wrong — 3 Mbps sustained, 16 Sep) | |
The simple version does not fit. Pointing Watchtower straight at the gateway's existing streams would ask the trailer's cellular connection for roughly seven times what it can carry. It would not merely be slow — it would saturate the link the monitoring centre depends on.
The gateway compresses using the processor's dedicated video hardware, which is why nine cameras cost so little. Producing a second, much smaller version of each camera for Watchtower uses that same hardware — and it only has to exist while somebody is actually watching.
| Piece | Why |
|---|---|
| A second, low-bitrate version per camera | At around 200–300 kbps it would use less bandwidth than the MJPEG it replaces, while looking better, because compressed video is far more efficient than a sequence of photographs. |
| Produced only on demand | The streaming server can start a stream when the first viewer connects and stop it when the last one leaves. Watchtower usage is measured at roughly five visits of five minutes a month — so this costs nothing at all for more than 99% of the time. |
| Delivered over WebRTC | Already enabled, plays in a browser with no plugin, and arrives in well under a second rather than the several seconds HLS would add. |
That combination removes the processor cost, reduces the bandwidth below what is used today, and stops both from growing with the number of viewers.
| Clients would see the detection boxes | The gateway's streams are the annotated ones. Whether showing a client where the system detected somebody is a feature or a liability is a business decision, not a technical one — but it would not be optional without producing a second, unannotated stream. |
| It replaces live video only | The mobile server also carries recorded playback, camera control and events. Anything Watchtower uses beyond live pictures would still need it. |
| The streaming server has no password | None at all, today. It is only safe because it sits behind a network nobody should reach — and we already found 204 addresses from the public internet probing its port over eleven days. None got a stream, because they would have to guess the exact name. Exposing it to clients means adding authentication first, not afterwards. |
None of the three requires committing to the change, and together they replace the two assumptions this page still rests on.