About pimaso

How it works

Live video goes straight from your phone to each camera. Every tile opens its own connection and pulls the picture directly, across your local network. Nothing relays it, and nothing else has to be running for it to work.

Everything a DVR does is a separate conversation, with the imaso server. Recording, snapshots, timelapses, the recorded library, motion history and the machine’s own health all come from the Raspberry Pi, over the same interface imaso’s web app uses. No feature was added to the server for this app — it sends the requests the browser already sends.

Those two halves are kept apart on purpose, and the payoff is the one thing worth taking from this page: when the Pi is off, the video does not notice. The camera list is cached on the phone, encrypted and credentials included, so the grid comes back after a restart even if the server never does. The controls that need the DVR grey out and say why; the picture carries on.

Without a server

You are never made to sign in. The app opens straight to the cameras, and signing in is something you do only if you have a server to sign in to. Settings → Cameras → Add a camera manually takes a name, address, RTSP port, credentials and the two stream paths, and that camera plays immediately.

A camera added this way survives every later sync with a server, and it is the only way to use the app before the first sync has ever succeeded — worth knowing if the Pi has been down since you installed it.

What such a camera does not get is anything that needs the DVR: no recording, snapshots or timelapses, no recorded playback, no motion events or alerts, and no Talk. Those controls are disabled with the reason attached rather than failing when pressed.

How video is decoded

Video is decoded by Media3 / ExoPlayer, Android’s own playback stack, handing H.264 to the phone’s hardware decoder. It is light enough per instance to keep a six-up grid on hardware decode, which is the constraint the whole app is built around.

It is also strict about RTSP: a camera whose handshake or session description does not follow the specification closely can be refused where a more forgiving player would have coped. Cameras vary enormously here, so it is worth knowing that this is the failure you may meet, and that it looks like one tile staying black while the rest play.

Accounts and roles

A viewer account can watch every camera. Signing in as one is enough for a working grid, fullscreen, recordings, snapshots and motion history. Two things differ from an admin account, and both are worth knowing before choosing.

Live view is streamed through the server instead of dialled directly. imaso withholds camera passwords from any account whose role is not admin — it treats a camera password as a capability, not as data. Without one the phone cannot dial a camera, so it plays the same stream relayed by the Pi. That works out of the box, and costs three things: a camera mounted sideways is shown sideways, live view stops when the Pi does, and the Pi has to repackage the video for every phone watching.

DVR commands are refused. imaso gates every mutating route on the admin role. A viewer can browse recordings, snapshots, timelapses and motion history and play clips back, but cannot start a recording, capture a snapshot or run a timelapse. This one has no workaround in the app — it is enforced on the server.

Cameras → Camera passwords on this phone removes all three costs: fetch them once with an admin login (which is used and immediately signed back out, never stored), or set one shared RTSP login for every camera. Both are kept encrypted in the Android Keystore and never sent anywhere. Note what that means — afterwards the phone holds working camera credentials for good, whichever role it is signed in as. Right for a household phone an admin sets up in person; wrong for handing someone limited access.

Motion alerts

When a camera sees something, the phone plays a two-tone doorbell chime and says the camera’s name — or plays a voice clip recorded for that camera, if there is one. The pitches are hashed from the camera’s name the same way imaso’s web app does it, so a camera sounds identical on the phone and in the browser and you learn which is which by ear.

Which cameras alert is the server’s setting, not the phone’s. pimaso reads imaso’s two per-camera flags — chime, and speak — and writes neither: one place to configure, and every client behaves the same. Settings → Motion alerts lists exactly which cameras will make which noise, and the switch there silences this phone without touching anyone else’s.

Two limits worth stating plainly. Alerts need the server, because motion is detected on the cameras but collected by the Pi — unlike live view there is no offline path to it. And they sound only while the app is running: background push would need a notification service this app deliberately does not include.

Two-way audio

Hold (or tap) Talk to speak through a camera’s speaker — on the grid tile, in fullscreen, and on a camera’s own page. The mode follows the DVR’s own setting, so the phone and the browser behave the same way for the same camera.

This is the one feature where the server is in the media path. Everything else is either RTSP straight from the phone to the camera, or a small request to the server — so everything else survives the Pi being off, and Talk does not. It needs the streaming relay running on the Pi, an admin account, a route to the relay’s WebRTC port, and microphone permission, which is requested on first press and never at launch.

Scope

What it does

The live grid, fullscreen on a camera’s full-resolution stream, camera and settings management, syncing with a server, and the encrypted offline cache. With a server reachable, it adds recording on demand, snapshots, timelapse capture and video export, recorded playback with a day coverage bar, the snapshot library, motion history and motion alerts, the server’s own health, restarting the streaming relay, and two-way audio. Listening to a camera and two-finger zoom work either way.

What it does not do, by choice

There is no multi-camera collage, no PTZ control, and no remote or internet access — the app reaches your local network and nothing beyond it, which is the whole security model and not an omission to be fixed later.

The interface is dark-only and in English only. Neither of those is the same thing as the camera names or the spoken motion alerts, which appear in whatever language your server holds them in.

How it is built

Every third-party component and its licence is listed on the Third-Party Licenses page.