For camera vendors

Two doors, and you never match our release cadence.

We define one canonical command vocabulary and refuse to let vendor shapes cross the bus. That refusal is the invitation: implement the vocabulary once, in your own language, on your own schedule, and your camera behaves like a first-class citizen here.

Write the driver

A driver is a .so plugin against a stable C ABI. Six functions, one header, about 200 lines for a complete one. It needs neither our language nor our build system, and it keeps working across our releases.

$ cc -O2 -shared -fPIC -I /path/to/cam_abi.h/dir my_driver.c -o libcam_acme.so # then name it in the config the hub already reads:"camctl": { "drivers": ["/opt/acme/libcam_acme.so"] }

The compile line as the driver runbook states it. Six entry points: reboot, get_info, set_enc, set_image, ptz, get_state.

Or speak the native dialect

Answer the canonical vocabulary over REST — POST /v1/<cmd>, self-describing through /v1/help — and no driver is needed at all. The camera is supported the moment it ships.

$ curl -s http://reference-camera:8600/v1/helpCommands (POST /v1/<command>, JSON body, Authorization: Bearer <token>): help [/<cmd>] this index; /v1/help/<cmd> details one command (GET ok) login mint a session token (8 concurrent, 3600 s lease) logout void the calling token get_info identity: model, firmware, name get_state everything readable in one call: ptz caps + enc + image set_enc change bitrate_kbps / fps on one stream set_image day_night, back_light, anti_flicker, exposure, white_balance, rotation, mirroring (canonical values) ptz continuous move; the caller owns the press/release pair reboot reseed state, void tokens, drop RTSP sessions

The reference camera's own /v1/help, excerpted. There is a JSON form of the same index, so a driver can validate the surface at startup.

The reference camera is the lint

We ship a synthetic camera that accepts only canonical vocabulary. Test against it and the verdict is unambiguous: if your driver fails there, it is still speaking vendor. Nothing about your firmware has to change to find that out.

The ABI header and a complete demo driver are published documents

rebootreseed state, drop sessions

get_infoidentity: model, firmware, name

set_encbitrate / fps on one stream

set_imageday/night, exposure, white balance — canonical values

ptzcontinuous move; the caller owns the press/release pair

get_stateeverything readable in one call

CCTV_ABI_VERSION 1 · CCTV_V1_N_OPS 6 · src/include/cam_abi.h

Why bother, honestly

Because the work is small, it is yours to keep, and it does not tie you to us. There is no per-unit fee to try, no toolchain to adopt and no certification to buy before you can test. What a listing or a certification programme eventually looks like is a conversation, and we would rather have it after your driver already works.

Start a driver conversation