GET /api/cameras/{id}/live-view/frame returning image/jpeg — binary data that sits outside the typed SDK surface. This recipe is the “get frames” pattern.
When to use
- Showing a preview in your UI (a
<canvas>or<img>that updates ~15fps) - Feeding frames to ML inference
- Recording a timelapse from the live view feed
- Any case where you want the camera’s viewfinder, not a captured photo
Prerequisites
The camera must be connected inremote or remote-transfer mode, and live view must be enabled + started:
TypeScript
Complete recipe
Usage — write frames to disk
Usage — render to a <canvas> in the browser
Usage — render to an <img> (simpler, no ImageBitmap)
Python
Complete recipe
Usage — write frames to disk
Usage — stream to ML inference
Swift
Complete recipe
Usage — SwiftUI preview
Performance notes
- Don’t go below ~50ms interval. The server encodes JPEGs on every request; hammering it harder than camera can produce frames wastes CPU.
- 15fps (66ms) is a good default. The camera’s live view is typically capped around 15-30fps internally.
- Back-pressure is free. Each recipe is a pull-based generator — if your consumer is slow, frames simply aren’t fetched, they don’t pile up in memory.
- Keep-alive matters. All three recipes reuse a single HTTP client (
fetchpool,httpx.AsyncClient,URLSession.shared) so TCP connections are reused — significantly faster than a fresh connection per frame.
Starting live view before polling
Live view must be enabled + started on the camera first. Easiest full flow:start auto-enables live view if it’s off, but being explicit reads better.

