Feature request: wider field of view for the camera stream - DAT delivers ~53 deg horizontal vs ~88 deg native capture on the same hardware

[daniel-lewis-field-nine]

Summary

The DAT camera stream is a fixed 9:16 portrait crop that discards roughly half of the horizontal field of view the same glasses capture natively. We measured it: ~53° horizontal through DAT vs ~88° horizontal through native (hardware button) capture, same unit, same scene, same distance. We'd like a way to stream the sensor's full (or fuller) horizontal field, and we believe this is achievable with zero additional bandwidth.

Measurements

Method: Ray-Ban Meta (Gen 2, Wayfarer) on a wearer 36 inches from a wall, tape measure across the wall at lens height, FOV computed from the wall span visible in the recorded frame (2*atan((w/2)/d)), with the tape's foot markers as scale ground truth and lens distortion handled by integrating the tape's local scale across the frame. Full-resolution frames: dat-fov-measurements.

Capture	Resolution	Aspect	Horizontal FOV
DAT stream, VideoQuality.HIGH	720×1280	9:16	52.7°
DAT stream, VideoQuality.MEDIUM	504×896	9:16	54.1° (same crop, only resolution differs)
Native capture (capture button)	1552×2080	3:4	~87.7°

Vertical FOV through DAT is ~83° — nearly the full sensor height. The stream therefore keeps the sensor's vertical field and crops away the sides - the missing ~35° of width is exactly where our users' content is.

Environment: mwdat 0.6.0 (also verified against 0.8.0's API surface), glasses firmware 126.0.0.207.412, Meta AI app 280.1.0.36.162, Android 14 (Pixel 9a), Developer Mode.

Why it matters

We build a healthcare app: providers wear the glasses to record therapy sessions for fidelity review. At a typical working distance of 3 feet, 53° of horizontal FOV covers about 36 inches of scene — essentially one person. The native 88° covers ~69 inches: the client, the materials, and the provider's hands. The stream crops out the edge activity our clinicians need before it ever reaches us.

What we checked before filing

• StreamConfiguration exposes only videoQuality, frameRate, compressVideo on every released SDK version (0.2.1 through 0.8.0) — no FOV/crop/aspect parameter.
• Both VideoQuality levels deliver the same crop (measured above), so quality settings are not a workaround.
• No changelog entry from 0.1.0 to 0.8.0 mentions FOV or crop changes.
• meta-wearables-dat-ios#143 confirms orientation/aspect is not configurable by design.
• No existing issue on either DAT repo requests a wider stream FOV.

Request

Any of these would solve it — in our order of preference:

1. A crop/FOV option on StreamConfiguration (e.g. fieldOfView = WIDE | DEFAULT) that delivers the sensor's wider view scaled into the existing stream resolutions. Same pixel count, same bitrate, same Bluetooth budget — just a wider source crop before the scaler. (This matters on Android, which we understand does not get the 0.8.0 Wi-Fi transport — Enabling the 0.8 WiFi transport on Android (CameraAccess sample) + recovering a DISCONNECTED link — camera fails randomly while LiveKit audio stays healthy (DAT 0.8.0) #138 — so solutions requiring larger frames won't reach us.)
2. A VideoQuality profile with the sensor's native 3:4 aspect at an existing pixel budget (e.g. 960×1280).
3. Matching the native-capture crop in the streaming pipeline outright.

Happy to provide the measurement clips, run test builds, or measure release candidates on our hardware.

[hiSandog]

Exposing aspect ratio/crop as a stream capability would let applications choose between the current portrait detail and a wider view without assuming every hardware generation supports the same sensor mode. Keeping bandwidth constant is plausible by redistributing the pixel budget, but the API should report the actual delivered resolution/FOV so callers can make that tradeoff explicitly. A capability query plus graceful fallback would avoid breaking existing devices that only expose the current crop.