#1 Improv, #2 Worldview Timeline, #3 Camera Map, #4 Morse, #5 AIS Watch, article Finding pilots without emitting RF -- Combat Search and Rescue (CSAR) RF flashlight from space, on X Watch Agadez grow (be built), then handed back, to now. Northern Niger. Keep on eye on it!

Marshall Frith

Projects

A Camera That Needs a Password Can Never Be Handed to ATAK Directly

Maps 35,944 public cameras and re-publishes any of them as a stream ATAK, VLC or a recorder can open. The format ATAK uses for video has nowhere to put a username, which decides almost everything else about how it works.

Every state highway agency publishes its traffic cameras. So do wildfire lookout networks, the National Park Service, and a handful of city transport departments. This collects 35,944 of them onto one map, lets you lasso a stretch of road or a fire perimeter, and exports the selection to ATAK as a data package with a marker and a working video feed for each camera.

Try the browser preview — Arlington and Northern Virginia, 785 cameras, no install. Your browser fetches each picture straight from the agency that publishes it, so which camera you opened never reaches my server.

Clustered traffic cameras already plotted across Arlington and Northern Virginia, the largest cluster sitting on Washington DC.

The constraint that shaped it

ATAK stores a video feed as an alias: a set of fields, not a URL. Address, port, path, protocol.

There is no username field and no password field. An RTSP URL can carry a username and password ahead of the host. Anything building the alias from that URL reaches for the usual host-only parser, which returns only the host and silently drops the credentials with it. The phone opens an unauthenticated URL and gets a 401.

So a camera that needs credentials can never be exported as a direct link. It has to be relayed by something that holds the password. That is not a workaround, and it turns out to be the better design twice over: the password stays on your machine instead of travelling to a phone in a plaintext file, and the phone only has to reach your machine rather than the camera's own network — which is what lets a camera on your home LAN work from cellular.

The bug that cost the most

The rule "can ATAK play this itself?" ended up written out in four places. A fix taught two of them about credentials and left the other two alone.

A camera needing a password is RTSP, so the relay classified it as "plays unaided", left it out of its config, and wrote # nothing to bridge — while the exporter, now smarter, wrote an alias pointing at the relay. The phone was handed a path the relay had never been told to serve.

Nothing raised an error. The camera appeared on the map, in the right place, with a video entry attached, and simply never loaded. Two agreeing sites and two stale ones is worse than four stale ones: with four, the feature plainly doesn't work. With a partial fix, the two halves point at each other and the result looks healthy.

The rule lives in one function now, and a test fails the build if anyone re-inlines it.

Why the preview can show you cameras it cannot really give you

776 of the 785 cameras in the preview are RTSP. No browser opens RTSP — not Chrome, not Safari, not Firefox, and no web page can add the ability.

They play anyway, because these particular agencies also publish a browser-friendly copy of the same camera. It is a re-encode, a few seconds behind, and it exists only for as long as they choose to keep publishing it. What it is not is something you can hand to another program. You cannot point ATAK, VLC, OBS or a recorder at a web page.

That gap is the whole reason the desktop app exists: it opens the RTSP feed itself and re-publishes it as a stream your own tools can open.

Things measured rather than assumed

The relay used to re-encode every camera on the way past. Measured against one camera: it consumed 1080p at 0.935 Mbit/s and emitted 720p at 2.018 Mbit/s — 2.16× the bytes for a quarter of the pixels. Roughly half the traffic was manufactured by libx264 -preset ultrafast forcing keyframes every second against a camera GOP of two. Switching to stream-copy cut bandwidth 53% and raised the picture to 1080p.

Probing one dead camera measures the camera, not the host — a bug in that reasoning cost Maryland 316 cameras and California 2,142 before anyone noticed they were fine.

And every ffprobe test against a camera on the local network failed identically, which looked like a consistent finding until the control failed the same way. macOS grants local-network permission per binary; the tool was blocked, not the camera. A raw-socket RTSP DESCRIBE with digest auth answered the question in one request, and confirms username, password and path together.

What it does besides export

A wall of up to 16 live feeds arranged the way the road runs, so you can watch a queue travel across the screen. Recording to MP4 or MOV, scheduled or on demand. A change detector for wildfire lookouts that rings a camera whose view just moved. An emergency-light detector built on red/blue anti-phase, because the first version measured the codec's keyframe rhythm and reported every camera as flashing at exactly 1.0 Hz.

Local-first: it runs on your machine, holds no account, and phones nothing home.

Looking for the code?

It is not published. These are personal builds, and what is here is the write-up rather than the repository.

The browser version is here, running the same work on your own machine: try it.

If you want to read the source or run the full desktop tool, ask. Say what you are doing with it and I will usually send it over.

Ask for the code

Comments

Plain text only. Held for review before it appears.