# ARRI CAP (Camera Access Protocol) — verified findings

Sources:
- `gambithunt/arri-camera-control` (GitHub) — contains ARRI's CAP v1.12 spec (June 2024,
  covers ALEXA 35 1.3.0 / Mini LF / SXT) reformatted as markdown, plus Node + Swift clients
- ARRI public CAP feature-list PDF (arri.com, v1.11, 2026-03)
- Cyanview integration docs (field-verified default password, camera menu path)

## Verdict

Our v1 driver's REST paths are fiction. Real protocol: **CAP — binary over TCP, port 5055,
big-endian**. No REST/WebSocket/JSON on camera. Full spec behind ARRI Partner (CAP) Program;
enough is public to build the real driver.

## Transport — VERIFIED

- TCP port **5055** (spec). ⚠️ One client repo defaults 7777 — trust spec, confirm on hardware.
- Frame: `[length U16][msgType U8][msgId U16][cmdCode U16][payload]`, length includes 7-byte header.
- msgType: 0x01 COMMAND, 0x02 REPLY (same msgId), 0x03 EVENT (subscription push).
- Strings: U16 length + UTF-8.
- Keep-alive: `Live` (0x0080) every 1 s or connection drops.
- Discovery: Bonjour/mDNS (service type string unconfirmed — INFERRED).

## Handshake — VERIFIED (order); MD5 concat order INFERRED

1. TCP connect → camera sends `Welcome` (0x0087) w/ protocol version + result
   (`Result_OK` / `Result_TooManyClients`)
2. → `RequestPwdChallenge` (0x0081) → challenge
3. → `Password` (0x0082) = MD5(challenge concat password) — **test both concat orders**;
   default camera password `arri` (Cyanview, field practice)
4. → `ClientName` (0x0083)
5. Normal traffic.

Result codes: OK=0, NO_SUCH_COMMAND=1, NOT_ALLOWED=2, NO_SUCH_VARIABLES=3, WRONG_PASSWD=4,
WRONG_TYPE=6, NOT_AUTHORIZED=7, TOO_MANY_CLIENTS=8, PROTOCOL_ERROR=9.

## Commands we need — VERIFIED

| Command | Code |
|---|---|
| Live (keep-alive) | 0x0080 |
| RequestPwdChallenge / Password / ClientName | 0x0081 / 0x0082 / 0x0083 |
| RequestVariables (subscribe) / Un-Request | 0x0084 / 0x0085 |
| SetVariable / GetVariable | 0x0086 / 0x0090 |
| Welcome | 0x0087 |
| GetFrameGrab | 0x0088 |
| Set3DLutFile / Set3DLutData / Set3DLutDataEx | 0x008a / 0x008c / 0x00F5 |
| SaveLookFile / LoadLookFile / AddLookFile / InstallLookFile | 0x008d / 0x00b1 / 0x00F0 / 0x00b2 |
| RecordStart / RecordStop | 0x00a0 / 0x00a1 |
| GetClipList (ALE metadata) | 0x00a4 |

## Variables we need — VERIFIED

| Purpose | ID | Type | Notes |
|---|---|---|---|
| Camera state | 0x0040 | U16 bitfield | RECORDING=0x0001, STDBY_READY=0x0004, IDLE=0x0080... |
| **CDL values** | **0x0050** | BLOB 10×F32 | slope×3 offset×3 power×3 sat (order INFERRED from ASC convention) |
| Color temperature | 0x0051 | U32 | Kelvin |
| Tint | 0x0052 | F32 | |
| Exposure index | 0x0053 | U32 | ASA |
| Reel / clip number | 0x005C / 0x005D | U16 | clip names via GetClipList |
| Sensor FPS | 0x0061 | F32 | |
| Timecode | 0x0078 | U32 BCD | HHMMSSFF |
| Look filename | 0x0041 | string | read-only |
| Look intensity (A35) | 0x00A9 | F32 | 0–1 |

Live status: `RequestVariables` once → EVENT frames on change (preferred over polling).

## Look control summary

- **Native CDL: yes** — SetVariable 0x0050, 10 floats, live-tweakable. Perfect for our CDL-split flow.
- **3D LUT: yes** — Set3DLutData/Ex + SaveLookFile; ALF4 on ALEXA 35 (ALF2 Mini LF);
  file-transfer chunk framing NOT publicly documented (spec sections mangled) — INFERRED,
  needs partner spec or hardware sniffing.
- Look intensity + parametric looks (A35, mesh points 0x00AB).

## Driver rework plan

1. Replace REST client with TCP binary CAP client (frame codec fully testable).
2. Handshake state machine incl. MD5 challenge (both concat orders behind a flag).
3. Subscribe to state/metadata variables; EVENT-driven CameraState.
4. Look push: CDL via SetVariable 0x0050 always; LUT via Set3DLutData behind a
   "verified-on-hardware" flag until chunk framing confirmed.
5. capabilities: supportsNativeCDL=true; lut3dSizes stays [17,33,65] but LUT push marked
   experimental.

# Sony VENICE 2 — verified findings

Sources: `sethdotfm/MultiVENICETool` (Python, archived), Cyanview + Bit Part integration docs.

## Verdict

**Closed protocol.** No public REST API; our /cna/v1 paths are fiction.

- VERIFIED: camera serves authenticated web remote at `http://<ip>/rmt.html`
  (HTTP Basic, port 80, enable via Technical > Network > Setting = LAN, auth user/pass).
  MultiVENICETool drives it via headless browser (DOM clicks e.g. BUTTON_REC_BUTTON) —
  i.e. even open-source tooling could not find a clean wire API.
- VERIFIED (Cyanview capability list, wire format proprietary): IP control exists for
  iris, ISO/gain, shutter, ND, WB (temp+tint+AWB), REC start/stop, tally, TC, scene files —
  spoken natively by partner products (Cyanview RCP, Pomfort, ARRI NIA-1). Protocol
  undocumented publicly.
- Look/LUT/CDL push over IP: **unknown/likely partner-only.** Monitor LUT selection exists
  on camera; no public evidence of live LUT upload over IP.

## Driver posture (revised)

- Keep SonyDriver as **capability-minimal**: metadata/rec-state via whatever transport is
  verified on hardware later; look push marked unsupported until partner docs or packet
  capture prove otherwise. supportsNativeCDL=false; lut3dSizes=[] (was [17,33] — WRONG,
  downgraded pending verification).
- Practical on-set path for Venice today: grade via SDI-chain LUT box (our DeckLink output
  or Teradek/BoxIO), not camera-internal. This matches Livegrade's own Venice story.
- Escalation options: Sony partner SDK; packet-capture rmt.html backend traffic on real
  camera; monitor Sony's newer BURANO/FX-line REST APIs for convergence.