What libobsbot can drive today, and what's pending. A model becomes
supported once it has a confirmed VID:PID, a descriptor dump, and at
least one decoded control with a per-method pcap under
doc/protocol/<model>/. See the
sourcing rule for how protocol evidence is
admitted.
Got an OBSBOT camera that isn't listed below? The fastest path to support is to record a USB packet capture while OBSBOT's own software talks to it.
Submit a new-hardware request →
USB 3564:fefb, bcdDevice = 5.10, XU GUID
{9a1e7291-6843-4683-6d92-39bc7906ee49} (entity 2, 7 controls).
See protocol notes.
| Control | Path | Status | Evidence |
|---|---|---|---|
| brightness, contrast, saturation, hue, sharpness, gain, backlight compensation | standard UVC ProcessingUnit |
working end-to-end | UVC 1.5 §A.9.5 (no per-method pcap required) |
| WB temperature, WB auto | standard UVC ProcessingUnit |
working end-to-end | UVC 1.5 §A.9.5 |
| anti-flicker (mains-frequency rejection) | standard UVC ProcessingUnit (Power Line Frequency) |
working end-to-end | UVC 1.5 §4.2.2.3.6 |
| zoom, focus, pan/tilt | standard UVC CameraTerminal |
working end-to-end (pan/tilt centred against live camera) | UVC 1.5 §A.9.4 |
| autofocus on/off | standard UVC CameraTerminal (Focus Auto) |
working end-to-end | UVC 1.5 §4.2.2.1.8 |
| auto-exposure mode + AE lock | standard UVC CameraTerminal (AE Mode) |
working end-to-end (Manual / Auto verified; Shutter / Aperture Priority accepted but Meet 2-dependent) | UVC 1.5 §4.2.2.1.2 |
| manual exposure time | standard UVC CameraTerminal (Exposure Time Absolute) |
working end-to-end (paired with AE lock for full manual control) | UVC 1.5 §4.2.2.1.4 |
| HDR (WDR) | XU selector 0x06, control id 0x01 |
decoded + verified on hardware | setWdr.md |
| media mode | XU selector 0x06, control id 0x00 |
decoded | setMediaMode.md |
| FOV preset | XU selector 0x06, control id 0x04 |
decoded | setFov.md |
| face AE | XU selector 0x06, control id 0x03 |
decoded | setFaceAE.md |
| face focus | XU selector 0x02 RPC frame (cmd_set 0x02, cmd_id 0x36) |
set decoded + verified; frame synthesised at runtime via CRC-16/USB | setFaceFocus.md |
| auto-framing sub-mode | XU selector 0x06, control id 0x0d |
decoded + verified on hardware | setAutoFraming.md |
| AI master mode | XU selector 0x06, control id 0x16 |
decoded + verified on hardware (set + get via status blob offset 0x18) | setAiMode.md |
| XU status blob (WDR, face-AE, AI mode readback) | XU selector 0x06 GET_CUR |
decoded by toggle-and-diff against live hardware | statusBlob.md |
| firmware / serial read | XU selector 0x02 RPC frame |
decoded; frames synthesised at runtime from learned device MAC | getStatus.md |
| selector-0x02 RPC framing (CRC) | XU selector 0x02 |
CRC-16/USB over buf[0..u16_le(buf[4..6])], plus an inner CRC over the payload section when buf[1] & 0x60 != 0; recovered from libdev.so disassembly |
crc-investigation.md |
| device MAC learning | XU selector 0x02 RPC (cmd_set 0x0D, cmd_id 0x08, sub-cmd 0x18) |
learned at Devices::open; the only RPC frame that doesn't need a MAC, used to bootstrap subsequent sends on any unit |
getStatus.md (pair 0) |
| hot-plug events | polling /sys/class/video4linux on a 2 s interval |
working end-to-end; Devices::events emits DeviceAdded / DeviceRemoved |
n/a (Linux-only for now) |
| periodic status snapshots | per-Device poller thread (default 2.5 s, Cadence::Fast = 25 ms) |
samples PU brightness/contrast/saturation + CT pan/tilt/zoom into Event::Status |
n/a |
| audio AGC | XU selector 0x06, control id 0x17 |
set decoded + verified; no getter (camera doesn't echo state into the status blob, and the SDK's get path uses a separate RPC we haven't captured) | setAudioAgc.md |
| mirror / horizontal flip | XU selector 0x06, control id 0x14 |
set decoded from cameraSetImageFlipHorizonU |
recovered from libdev.so |
| portrait orientation | XU selector 0x06, control id 0x0c |
set decoded from cameraSetVerticalModeU |
recovered from libdev.so |
| status LED | XU selector 0x06, control id 0x18 |
set decoded from cameraSetLedCtrlU |
recovered from libdev.so |
| virtual background (enable / mode / colour / mask level) | XU selector 0x06, control ids 0x05 / 0x06 / 0x10 / 0x11 |
set decoded from cameraSetBg{Enable,Mode,Color}U + cameraSetMaskLevelU; MediaBgMode and MediaBgColor enum values match SDK header |
recovered from libdev.so |
| auto-suspend (timer + disable-without-stream + mic during sleep) | XU selector 0x06, control ids 0x0b / 0x12 / 0x13 |
set decoded from cameraSetSuspendTimeU / cameraSetDisableSleepWithoutStreamU / cameraSetMicrophoneDuringSleepU |
recovered from libdev.so |
| physical-button mode | XU selector 0x06, control id 0x07 |
set decoded from cameraSetButtonModeU (raw u8; firmware-defined values) |
recovered from libdev.so |
| firmware version (read) | XU selector 0x02 RPC (cmd 0x08 / 0x04) |
Device::firmware returns a parsed FirmwareVersion with Ord support |
firmwareUpgrade.md |
| firmware upgrade (write) | XU selector 0x02 RPC + bulk transport (TBD) |
requires a pcap of the SDK upgrading a Meet 2 + a firmware binary; scoped in firmwareUpgrade.md | - |
mirror / flip (SDK cameraSetMirrorFlipR) |
XU selector 0x02 RPC (libdev magic 0x29000b00010000) |
distinct from the XU mode-register horizontal flip above; this is the RPC-routed variant only Tail Air uses. Wire format pending a targeted pcap if/when needed | - |
Other OBSBOT cameras have not been touched. Patches accepted; the quickest contribution is just a pcap of OBSBOT's own software driving the camera. File a new-hardware issue with the capture attached and we'll do the protocol-decode work.
| Model | Status |
|---|---|
| OBSBOT Tiny / Tiny 2 / Tiny 2 Lite / Tiny 4K / Tiny SE | no pcap, no decode |
| OBSBOT Meet / Meet 4K / Meet SE | no pcap, no decode |
| OBSBOT Tail Air | no pcap, no decode |
| OBSBOT Talent / ME / Marker | no pcap, no decode |
| Anything not listed | file an issue |
descriptors.txt under
doc/protocol/<model>/..md next to each pcap explaining which bytes
are which, derived only from the capture and public sources.crates/libobsbot-core/src/devices/<model>.rs
with a golden-byte test asserting the payload matches the pcap.The current Meet 2 entries in the table above are the worked example. Steps 1–3 can come from a user-submitted issue; step 4 is the follow-up PR.