zgaetano/rainbow-dragon
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions
rainbow-dragon/docs/research/arri-cap-protocol.md

5.5 KiB
Raw Permalink Blame History

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.