The API Gateway’s Cameras task = JpegGetLive uses the same underlying mechanism you asked about earlier in this topic. (RecorderCommandService JpegGetAt ao.)
After discussing this with a developer, here are the key points:
-
High load on the Recording Server (RS):
Generating even a single snapshot consumes significant RS resources. If every RS produces one snapshot per second, the number of cameras a single RS can support will be greatly reduced.
-
API Gateway behavior:
The API Gateway itself performs very little processing; it simply forwards the request to the RS. However, this can create high bandwidth usage if everything is routed through a single API Gateway.
It is possible to install and use multiple API Gateways to distribute the bandwidth usage.
-
Minimizing RS load:
The lowest impact on the RS is achieved by requesting the raw live video stream and decoding it on the client side.- With the ImageServer protocol, you can obtain the raw live video.
- By default, cameras using H.264 (or similar) produce one keyframe per second. This means you can extract that keyframe to obtain one still image per second—unless the camera’s settings are changed by the user.
- Alternatively: Using the MIP SDK (MIP .NET Framework library), the decoding is done client‑side, which offloads work from the RS.
-
Performance testing:
Milestone has not conducted testing on performance or load when making many frequent Cameras task=JpegGetLive requests through the API Gateway.