---
title: "Use cases"
description: "Problems Tatolab helps with, each with an example of streams that solve it, what you'd write yourself, and what isn't built yet."
type: "docs-page"
url: "https://tatolab.com/docs/use-cases"
site: "Tatolab"
section: "Use cases"
---

# Use cases

> Problems Tatolab helps with, each with an example of streams that solve it, what you'd write yourself, and what isn't built yet.

These pages start from a problem, not from a feature list. Each shows streams that solve it, with code you can run, says which parts you'd write yourself, and lists the limits that matter for that job.

| Problem | Where it comes up |
|---|---|
| [An agent should see what's happening now](https://tatolab.com/docs/use-cases/agents) | Operations, support, monitoring: anywhere a person checks a screen to answer a question |
| [Several programs need the same camera](https://tatolab.com/docs/use-cases/video-analytics) | Security and operations cameras, labs, studios: a detector, a recorder and a dashboard on one camera |
| [One camera, many destinations](https://tatolab.com/docs/use-cases/streaming) | Streamers, teachers, small productions: a look applied once, then a call, OBS and a recording |
| [Several sources, one record](https://tatolab.com/docs/use-cases/research) | Research labs: video, audio and instrument readings recorded together and lined up afterwards |

## What they have in common

- **Streams share instead of copying.** The stream that owns a device exposes its output; everything else reads it from streams of its own, which start, stop and change independently. A recorder, a detector or a dashboard can come and go without touching the camera.
- **Your nodes can use any package.** Each one runs in its own process with your project's packages, so a model, a driver or an HTTP client is one `uv add` away, and one failing node doesn't take the rest down.
- **Everything is visible.** `tatolab graph` shows what's running and what's been dropped, each stream keeps a [JSON Lines log](https://tatolab.com/docs/run/logs), and an agent can see the same things.

## What you'll write yourself

Tatolab ships the parts with deadlines: cameras the operating system sees, microphones and speakers, windows, hardware H.264 and H.265, Opus and MP4 recording, and a virtual camera on Linux. Integrations are nodes you write with the library you already use:

- IP cameras over RTSP, and anything with a vendor SDK
- Alerts, webhooks and dashboards
- Message queues and databases
- RTMP, SRT and NDI

[Write a node](https://tatolab.com/docs/build/nodes) covers sources driven by a timer or by their own thread, which is the shape most integrations take.

## Limits that apply everywhere

- **Platforms.** Linux on x86_64 with a Vulkan GPU, tested on NVIDIA, and Apple silicon Macs with macOS 15 or later.
- **Cameras.** On Linux, `CameraSource` reads uncompressed video only, so most USB 2.0 webcams run at 5 to 10 frames per second in HD; there are no exposure, focus or frame-rate settings yet. See [Built-in nodes](https://tatolab.com/docs/reference/built-in-nodes#camerasource).
- **Failures.** A Python node that crashes stays down, and shows as failed in `tatolab graph`, until its stream loads again; the rest of the stream keeps running. Watch for outputs that go quiet.
- **Recordings.** A kept stream starts its recording over each time it reloads, so record from a separate stream. See [Recordings and restarts](https://tatolab.com/docs/build/recording#recordings-and-restarts).
- **Not a control system.** Tatolab isn't hard real-time, isn't a safety system, and has no certifications.