PotoP VMS Studio

The client asks the operating system for its displays and the graphics driver for details, so each monitor shows manufacturer, model, serial, resolution, refresh rate, connector and the GPU that drives it, plus temperature and VRAM where the driver reports them. Each physical screen is matched by hardware identity, not by position, and is given a permanent code such as M1. Renames and codes are stored on that client and survive reboots and re-plugging. A monitor that is unplugged stays listed until you delete it, so a saved wall still points to the same screen.

The editor runs in the browser and saves the multi-layout to the server, so the same recipe is shared with desktop clients. The browser lists its own screens through the Window Management API, which needs a secure HTTPS connection and the user's permission. Each entry shows a monitor code, and codes that are not on this browser are shown as not present. Choosing a layout for a code adds it to the recipe. Projecting opens one browser window per matching screen and places it there, each running the live layout.

Multi-layouts are stored on the server as a list of monitor codes with the layout for each. This overview draws every recipe as a small picture of its screens and shows how many of them exist on the browser you use. Launch Projection opens a window on each matching screen and starts the live layouts there. Edit and Delete change the stored recipe for all clients. Access follows the same user and group rights as the rest of the system, and a wall can be attached to users or groups so it opens for them automatically.

The browser can tell which physical screen each window sits on through the Window Management API, which requires HTTPS and a one-time permission prompt. Identify opens a borderless window on every detected display and draws the monitor code and name in large type, then closes it after a few seconds. The code comes from a registry kept in this browser, so renames survive and an unplugged monitor stays listed until you delete it. The details panel reports resolution, position, scale and colour depth as the browser sees them.

While the AI pipeline watched the live stream, it stored each detection with its class, confidence, bounding box and a thumbnail in the analytics database. Playback reads those rows for the moment being shown and draws the box over the video in the browser, so nothing is burned into the recording. The side list is fed by the same rows and shows class, time and confidence. Clicking an entry seeks the recording to that instant. The tracker also counts how many sightings belong to one object, which helps separate one parked car from many passing ones.

Inspect takes the frame under the playhead and sends it to the server, which runs the detector on it and cuts out the object with its mask. The Identify button passes that crop to a vision language model configured in the AI settings, running locally or through a provider you choose, and shows its description. Colour comes from the crop itself. Search this type and colour then queries the analytics database for detections of the same class and colour across the recordings. The description is a model's best guess, and it says so when the view is poor.

The server walks the recorded segments for the chosen range, decrypting them in memory, and samples frames. A background-subtraction gate skips empty frames, so the object detector and tracker only run where something moves. Each tracked object becomes a tube of cropped frames with its original timestamps. Tubes are rescheduled to play at the same time over one shared background, and ffmpeg renders the result as an MP4 with each object's real time burned in. The job runs in the background with progress polling and can be cancelled. Clicking an object jumps the timeline to its original moment.

The server cuts the requested time range from the recorded segments with ffmpeg, decrypting encrypted recordings in memory if you ask. Timestamp, camera name and watermark are burned into the picture. If you enable encryption, the MP4 is encrypted with AES-256 using a key derived from your password by PBKDF2, and a signature file is written beside it. The password is never stored, so nothing can recover it. The result stays on the server, downloads to your computer, or both, depending on the destination you choose.

The player runs on any computer without a PotoP server. You choose the encrypted video and its signature file, and enter the password. It first checks the signature with an HMAC to prove the file is unchanged, then derives the key from the password with PBKDF2 and decrypts with AES-256. The clear video exists only in memory while it plays. From there you can drag the green handles to trim a selection, save a still picture, or export a plain MP4 copy. A browser-based variant ships inside export folders with launchers for Linux, Windows and macOS.

Each camera has its own recording settings stored on the server, and the recorder applies them as soon as you save. Triggers can be continuous, a weekly schedule, or events such as motion, person, plate, an alarm input or a macro, with pre-event and post-event buffers so the moment before the trigger is kept. Segments are cut at a set length and can be encrypted with AES-256 after they are closed. Retention removes old segments by age or by maximum size. Start, stop and detection events can raise notifications through system events, email, Telegram or a webhook.

The primary detector runs at a configured frame rate with its own confidence, overlap threshold, maximum detections and class filter. A tracker, ByteTrack in this view, links detections across frames into stable object IDs, which drives counting and dwell time. Secondary stages are gated by class: plate recognition starts only when a car, truck, bus or motorcycle is found, and pose or segmentation only when their trigger class appears. That keeps the load low, because the heavier models see a small crop and not the whole frame.

A pose model runs on the person crop found by the primary detector and returns body keypoints with a confidence for each one. The server stores the skeleton and the browser draws it over the image, with the joint table beside it. Fall detection looks at how those keypoints move and are arranged over time, and a sensitivity setting adjusts its thresholds. When it triggers, the event is stored and can raise an alert or start a macro. The live table below polls the database, so you see the same rows that reach the alarm system.

A segmentation model runs on the objects found by the primary detector and returns a pixel mask for each one. The server sends these to the browser as mask images, and the preview paints them over the frame. The tracker keeps an object ID, so the table can show how long each object has been in view. When an object stays still longer than the stationary threshold, the lifecycle logic marks it as abandoned and the row turns red. Lifecycle events, such as appeared or left, are logged for later search.

You draw polygons and lines directly on a live picture, and the server saves them in the camera's normalised coordinates, so they stay correct at any resolution. The tracker follows object IDs, and a crossing is detected when a tracked object's position moves from one side of the line to the other, giving the direction A to B or B to A. Zones raise entry and dwell events. Each event goes to the analytics database with a timestamp and track ID, where counters, reports, alarms and macros can use it.

Motion detection has two sources. The camera's own detection arrives as ONVIF motion events, and server analysis compares video frames with a background model on the server, using CPU or GPU. The mask is a grid of blocks you paint on the picture, and blocks marked as ignored are excluded from the comparison, so leaves or road traffic do not trigger. Sensitivity, minimum area, sampling rate and downscale can be tuned. The mask is saved with the camera and applied by the server as soon as you save.

You draw blocks on a live frame, and the server saves them with the camera. Depending on the switches, the server blurs or covers those areas in the live stream, in snapshots and in recordings. For live and recordings it does this on the server, before the video is stored or sent out, and for recordings the masked area is permanently lost from the stored video, which the page warns about. Colour and blur strength are adjustable. The masks are pushed to the running pipeline on save, so the change applies without restarting the camera.

Each person or vehicle crop is turned into a 256-value appearance vector by a small re-identification model running on OpenVINO, and stored in the analytics database. Searching embeds the query picture the same way and compares it with the stored vectors by cosine similarity, using an in-memory index so the result is exact and quick. Because it matches overall appearance and not a face, it works on people seen from behind or at low resolution. Selecting a result loads that track's sighting history and route, and Follow in Playback opens the recordings.

When a tracked object crosses a configured line, the server records the event with its direction, camera, line and time. This screen reads those events live in the Recent list. The history report groups them into buckets per hour or per day, with in, out and total columns, and can add dwell time and occupancy where those are configured. Occupancy limits raise an alert when breached. The CSV button exports the report for spreadsheets, which is how staffing and occupancy studies are usually done.

The server counts detections per camera and hour from the analytics data, including plates and watchlist hits. Those figures are given to a language model, here a small Llama model served locally by Ollama, which writes the briefing in plain language. If no model is available, a plain statistical summary is shown instead. The anomaly detector uses no AI model: it learns a typical count for each hour of the day, separately for weekdays and weekends, and flags an hour far above that baseline. It stays quiet until enough history exists.

A floor plan is a canvas with an optional background image, drawn building elements and icons, saved on the server with the rest of the system configuration. Each icon is bound to a real object such as a camera, a light, a door output or an intercom, and the server pushes that object's state to every open client, so the icon colour changes when the device changes. Desktop, browser and phone clients all read the same plan definition and draw it themselves, which is why one plan looks the same everywhere. Editing needs the visualization permissions.

The New Plan page holds a set of built-in generators. You pick a building type, answer a few parameters such as the number of consultation rooms and how much equipment to place, and a preview is computed on the spot. On Create, the generator writes walls, rooms, doors and icons into a normal plan on the server. Nothing is locked afterwards: the result is an ordinary plan you edit like a hand-drawn one, and an existing plan can be cloned instead, with or without its building elements.

Templates are code-driven generators that lay out rooms, walls and icons from a few parameters, here the number of server rows and the equipment level. The icons are created unbound, with the right type and label for each room, so the installer only has to link each one to a real camera, sensor or output afterwards. Because the output is stored as a normal plan, it can be renamed, moved, extended or cloned like any other. Different building types simply use different generators behind the same form.

The icon editor has a camera tab with a compass preview. You drag a handle to aim, side handles for the width and a square handle for the range, or type values and use lens presets. The preview shows exactly what the plan will draw after OK, while the ring and guide lines exist only in the editor. The same tab chooses which camera and which stream (main or sub) the icon uses and what a click does, such as opening a preview. All values are saved with the icon.

The dialog shown is the light icon editor, where each state (off, on, dimmed, fault, offline) gets its own colour and optional input and output status dots. A light icon is bound through a device plugin, such as the Philips Hue integration or generic I/O, and the server keeps its state in sync with the real fixture. Automatic switching from intercom or sensor inputs is done by the server-side macro engine, not by the plan itself. Plugin-reported problems, such as no connection, get their own colour on the icon.

An intercom icon is bound to an intercom plugin, in the dialog the Commend ICX integration, and the server listens to that station's call events. Each event maps to an icon state such as idle, calling, ringing, in call, on hold, emergency or line fault, and every state has its own colour that the editor previews. The state is pushed to all connected clients, so the plan reflects the real station within moments. Actions on the icon, such as calling or opening a door, are sent through the same plugin back to the device.

Every icon action can be marked as locked with a PIN. When an operator clicks such an icon, the client asks for the PIN before it sends the command to the server, so a stray click cannot switch an output or open a door. PINs can be permanent or temporary and are set per icon in the editor. The lock is an extra safeguard on top of the normal permission checks, which the server still enforces for whoever is signed in.

The Building Elements panel lists drawable objects such as walls, doors, windows, stairs, elevators, roads, plants, fences, pools and signs, and you can add your own. Elements are vector shapes stored in the same plan as the device icons, with position, size and layer order, so they scale cleanly at any zoom. A plan can therefore be drawn entirely inside the product, or drawn over an uploaded PNG, JPG, BMP or GIF background such as an architect's drawing.

Every desktop and browser client registers with the server under a unique ID and keeps reporting in, so the page can show what is online, its user, GPU, monitor count and last-seen time. An administrator can pre-register a client by its ID or remove one. Assigning a joystick binds a device record to that client. Network joysticks send small UDP or HTTP frames and stay disabled when first seen, so nobody on the LAN can steer cameras until an administrator enables them. IP joystick controllers connect over VISCA-over-IP: the server listens on a port and behaves like a camera, and forwards commands to the real camera's PTZ interface.

A device group is a named set of cameras on a server. User groups are linked to device groups, and when a user asks for cameras the server returns only those that belong to a device group linked to one of the user's groups. Statistics show the camera count, how many user groups and how many users have access. Because the rule is evaluated by the server and not the client, a camera added to a group is visible to the right people at once, and the built-in administrator always sees everything.

The picker lists all user groups with a short description of what each is allowed to do, and a search field narrows the list. Adding a group stores a link between that user group and the device group on the server. From then on, every member of that group gets the group's cameras in live view, playback and layouts, and no others through this link. Linking and unlinking is one step and takes effect for signed-in users without a restart.

Administrators choose whether client actions and server-side changes are recorded, the minimum severity, which categories to keep, and how many days to retain. A background sweep removes older rows on a schedule, and Apply retention now runs it on demand. Authentication and security events are always kept at their own severity. The trail can be downloaded as CSV or PDF, and a scheduled job can mail the report weekly or as chosen, using the mail server configured in the event settings.

The PDF is generated on the server from the same audit rows the Reports tab shows, using a standard Python PDF library rather than a screenshot. It contains the product header and logo, who generated the report and when, the active filters, a paginated table with a repeating header row, and a page footer. Very large result sets are capped, and the report says so explicitly, for example showing 5000 of the total. The scheduled e-mail report attaches this same file.

The macro editor is a visual node graph that runs on the server. A System Event node fires when the health monitor raises a matching event, such as a certificate about to expire, high disk or GPU usage or a low device battery, and passes the event text and value on its output ports. Wired into a Telegram Send node, it posts a message through the Telegram bot API. The graph is checked with Validate, can be simulated, and while it is live the editor shows the values passing through each node.

The screen shows the Telegram Send node of the macro editor: bot token, chat ID, a message template with placeholders for time and value, a Test button and a minimum interval between sends so repeated events do not flood the chat. The server posts to the Telegram bot API when the node receives a rising edge. E-mail alerts use the SMTP server configured under event settings. Events themselves come from the server's health monitor and the camera event feeds.

The server defines around 144 permissions, each with a module and an action level such as use or edit. The group dialog lists them in sections, with a filter box, all/use/edit shortcuts and presets that tick a typical set. The server checks the relevant permission on every API call and live channel, so a user without PTZ or recording rights is refused even when calling the API directly. Denied attempts are written to the audit trail with the permission name.

Instead of granting rights user by user, an administrator moves users between ready-made groups such as Operators, Viewers and editor or user pairs for layouts, macros, maps, PTZ, devices and more. A user's effective rights are the union of the rights of all groups they are in, plus their layouts and the cameras of the device groups linked to those groups. Changing a group changes every member at once, which keeps roles consistent across many accounts.

The Resources tab of a group sets numeric ceilings, with zero meaning unlimited: cameras and simultaneous streams a member may open, export length, size and count per day, how many layouts, macros and bookmarks they can create, and API requests per hour and tokens. The server enforces them when a request is made, for example refusing a stream beyond the cap. Individual user settings can override the group value, so a shared installation stays predictable under load.

The Security tab of a group defines concurrent sessions, session timeout, mandatory two-factor authentication, minimum password length, complexity, expiry, reuse blocking, failed-attempt lockout and its duration, plus audit level and log retention. The server enforces the policy at sign-in and on password changes, where passwords are stored as salted bcrypt hashes, not in readable form. Sign-in timing is equalised so an unknown user name cannot be told from a wrong password.

The user's Permissions tab shows the same matrix as a group, with two colours: blue boxes are direct permissions that can be changed here, purple ones come from the user's groups and are read-only in this view. The server combines both sets when it checks a request. Direct permissions are useful for one-off exceptions, and the counter shows how many of the total are active and how many come from groups. Clear All Direct removes exceptions without touching group rights.

The Security tab manages a user's second factor, which is a time-based one-time password (TOTP) compatible with common authenticator apps, together with one-time backup codes. It also shows account state such as lock, failed attempts and last login, and lets an administrator unlock or reset. Active sessions are listed with IP and browser and can be ended one by one or all together. API tokens are separate credentials with a name and expiry, so scripts and integrations do not need the user's password, and they can be revoked at any time.

The Activity tab reads two things from the server for one user: the active sessions, with IP address, client string and last activity, and the latest security events from the audit trail. Refused actions, such as a denied permission or a camera the user may not see, are logged at the moment the server rejects the request, together with the permission or resource name. Sessions show the kind of client, for example a browser or a script using the API, which helps separate normal use from unexpected access.

The server can generate a certificate authority or import an existing one. The CA certificate and its private key are stored on the server, with the key file readable only by the service account and optionally protected by a password, and only signed certificates leave the machine. The tab also downloads the CA certificate, backs it up and restores it, installs it into the system trust store, revokes certificates by serial number and builds a revocation list (CRL). A RADIUS server certificate for 802.1X can be issued from the same CA.

A new key pair is generated and a certificate is signed by the stored CA for the given name, DNS and IP entries, with a chosen validity and key type. The result is offered as PEM (certificate, key and CA) or as a PKCS#12 bundle. Ticking the server option installs the certificate as the server's own, trusts the CA for the desktop client, retires the old self-signed one and restarts the service, so browsers stop showing warnings once they trust the CA.

You list cameras by hand or import a CSV with address, vendor, credentials and ports. For each row the server issues a device certificate from the CA, and pushes the certificate and CA to the camera through that vendor's own web API, then switches on HTTPS. There are also actions to deactivate HTTPS and to test it. The server must reach the cameras on the network, and credentials are used only for the run. The result is one pass instead of logging in to every camera.

For one camera, the server signs a device certificate, uploads it with the vendor's API, can push the CA, activate HTTPS, disable plain HTTP and test the secure connection. The second section connects to another PotoP host over SSH, copies the certificate, key and CA file to the destination directory and can restart a service. Both operations run on the server, so it must be able to reach the target, and they need administrator rights.

The panel shows the certificate currently loaded for the web client with subject, issuer, validity, key type and size, signature algorithm and SHA-256 fingerprint, and can export it as PEM. The mobile section serves the CA certificate for download, or as a QR code that a phone or tablet can scan, so the device can trust the server once and stop warning. Installation instructions and scripts are provided for Linux, macOS and Windows.

Before the password is sent, the sign-in page contacts the chosen server over HTTPS and checks the certificate against the browser's trust store. If the chain is valid and matches, the green Safe Connection message appears, otherwise the user sees a warning. That check is done by the browser's own TLS stack, so it cannot be faked by the page. The credentials are then sent to the verified server over the encrypted connection.

The RAID panel in the server admin settings is a drawing engine that lays out disks, stripes and parity for the chosen level. In simulation mode you pick a level and disk count and it renders a synthetic array, so nothing real is touched. On a live server the same view is filled from the actual controller: software RAID through mdadm, or hardware controllers through their vendor command-line tools. Fault tolerance and usable capacity are calculated from the level and disk count, and the diagram shows how parity rotates across members, so installers can plan before building an array.

The same RAID monitor can draw nested levels. Here a simulated RAID 60 of sixteen disks is shown as four RAID 6 groups, with striping across the groups on top. The panel works out fault tolerance per group, so each group survives two failed disks, and usable capacity as eight of sixteen disks. The what-if slider below feeds that capacity into the recording time calculator, which divides it by the measured camera bitrate. Planning is done on the server data without changing any disks.

The RAID Management dialog runs in the desktop client but acts on the server you are logged into. An administrator re-enters their password to obtain a short-lived admin token. Creating an array builds a plan: the server lists detected disks and prepares the exact command as an argument list, never a shell string, and shows it as a preview. Nothing runs at plan time. Apply executes only that stored plan through a fixed allowlist of RAID tools, and dangerous actions ask you to type the target's identity first. Software RAID uses mdadm.

Grow and maintenance actions follow the same plan-then-apply flow as array creation. The client sends the request, the server validates every device name and builds the exact mdadm command for adding disks, expanding, changing chunk size or converting level, and returns it for review. Scrub check and repair start the kernel's consistency scan on the array. Minimum and maximum resync speed are the standard Linux software RAID limits, so a rebuild can be slowed while cameras are recording. Applying needs the admin token and, for risky steps, identity confirmation.

The Configuration tab sets how failure is detected and how the standby stays current. The monitor probes each server at the probe interval, and a server is declared failed only after the configured number of consecutive failed probes. Required services are always monitored, while optional ones such as VoIP or analytics only count if ticked. Backup interval, number of snapshots kept and a bandwidth cap control the replication agent on the failover node. Alerts can go out by e-mail (SMTP), Telegram or desktop notification.

During a backup cycle the failover node requests a manifest of the live server's files and databases, then fetches only what changed since the previous snapshot. Unchanged files are linked from the previous copy, which is why the panel can show thousands of files with only a handful fetched. Progress in files and megabytes is written to a status record that the client shows live. The finished export is rotated into a snapshot folder, and the standby's database line reads Syncing while data is being applied.

A takeover happens automatically when the failure threshold is reached, or manually with Force Takeover. The standby then serves the failed server's cameras, the failed server is marked offline, and the banner and top status line turn red. When the original server answers its probes again, Failback moves the cameras home. The Configuration tab can also do this automatically after the server has been healthy for a set number of minutes. Clients keep working because users and sessions were already mirrored to the standby.

The Event Log tab records each step of the redundancy process as it happens, with a local time stamp: a forced replication cycle, the takeover request, the start of the takeover worker, camera migration, the number of streams stopped on the failed server and the final result. The entries come from the server's takeover sequence and are kept for the session, with a Clear button. Because every transition is written in order, an operator can check afterwards what the system did and copy it into an incident report.

The Training tab holds the dataset, augmentation and image-source controls that feed a training run. A dataset is a folder of images with labels, filled from uploaded files, a webcam, a video file or an RTSP stream. Augmentation settings such as mosaic, flips, scale, rotation and colour shifts are applied on the fly while training. Validation split and random seed keep runs reproducible. The dialog shown appears when Start Training is pressed with no dataset selected. Conversion to ONNX and accelerator formats is a separate tab.

Action recognition works in two stages. First a pose model runs over your video or images and extracts body keypoints for each person, saved with the label you choose, such as walking or falling. Then a small sequence classifier, an LSTM by default, is trained on windows of consecutive frames of those keypoints, using PyTorch on the selected device. After training, precision, recall and F1 are calculated per class on held-out validation data. The result can be exported with an inference snippet for use in analytics.

The plate tab trains a character-sequence recognition network of the LPRNet type, which reads a cropped plate image and decodes characters with CTC. You pick a country charset and input size, then collect plate crops from recordings, image folders, URL lists or public datasets. The label editor lets you correct unlabeled plates, with optional OCR suggestions. Test on Frame runs the current model on one image. Finished models are exported, and can be compiled into a bundle for Axelera Metis accelerators and installed into the live recognition cascade.

The annotation tab is a labelling tool inside the Training Studio. You define object classes, browse the dataset's images and draw bounding boxes or polygons with the mouse. Each annotation is stored with its class and coordinates in the dataset folder, in the format the trainers read. Auto-Annotate runs an existing detection model over the image and proposes labels for you to accept or fix. The statistics panel counts total annotations and boxes per class, so you can see which classes lack examples.

Inventory questions are answered directly from the server's database, without a language model. Typing list cameras runs a lookup on the server and returns names, IP addresses, manufacturers and whether the camera is on and recording, drawn as a text table in the Result Board. The same engine covers plans, servers, layouts and macros. The chat only presents the result, so the answer reflects the live configuration, and it respects the permissions of the signed-in user.

Requests that lack a detail, such as a camera advanced query, start a short dialog on the server. The assistant lists the valid choices from the current configuration, here every camera with its address, and waits for the answer. You can answer with the letter, the name or the IP address. Back returns to the previous question and Cancel ends the dialog. The picker is generated from live data, so it only offers cameras that exist.

Database and backup questions are answered by direct server functions. The db status command reads the live PostgreSQL connection and reports type, version, size, table count, connection pool and host, with the password masked. The backups command lists the configuration backups stored on the server with date and size. The LLM switch enables an optional language model that runs locally through Ollama, so free-form questions can be handled without sending data to a cloud service.

The verbosity dialog changes how the chat formats server answers. The four levels range from single-line counts to full output including raw values. Timestamps, status icons and ASCII tables can be switched on or off, along with a compact spacing mode and a limit on items shown in lists. The settings apply on the client when replies are rendered, so different operators can use different levels against the same server. The panel behind the dialog is the categorised help list of example commands.