Five Obstacles — Connecting a Camera with Claude Code

Read in Other Languages
Loading…

Five Obstacles — Connecting a Camera with Claude Code

Taking a camera plugged into one computer and putting it inside the streaming software on another. On paper, five minutes of work.

El Turco | Analyst

I had two machines. A ThinkPad — a 2015 model, two cores, eight gigabytes — with an Akaso camera plugged into it. And a MacBook running OBS. Both on the same Tailscale network.

The job was clear: carry the camera's image across the network and into OBS.

Five obstacles appeared. Each one sat in a different layer.

The first attempt was the most direct: capture the camera, compress it, throw it across with UDP.

The packets left. Nothing arrived.

UDP is the traffic that firewalls and virtual networks like least. Rather than hunt for where it was being dropped, we changed roads: TCP. SSH was already working over TCP, so that path was known to be open.

We switched to TCP, opened a port, added a firewall rule. Connection refused.

The reason was subtle. When I connected over SSH, the account had administrator rights — but the session was not elevated. In Windows, those two things are not the same. The firewall rule had silently failed.

Instead of fighting the wall, we bypassed it entirely: an SSH tunnel. We pushed the video through a channel that already worked.

The tunnel was up, ffmpeg started, and died after four seconds.

The error was explicit: real-time buffer too full, frame dropped.

Because nobody had told it otherwise, the camera had fallen back to its default: 3840×2160. Compressing 4K in real time is not the work of a two-core processor from 2015.

The fix had two parts. We pinned the resolution to 1920×1080. And we moved the compression off the processor and into Intel Quick Sync — the hardware encoder built into the graphics chip.

The camera could produce H.264 by itself. So, we thought, let's pass it through untouched. Zero processor load.

The other end couldn't decode it. The log repeated one line: non-existing PPS 0 referenced.

The camera wasn't placing the headers that describe the picture — SPS and PPS — at the start of the stream. A video stream without headers is a text without an alphabet.

We took it as MJPEG and re-encoded with Quick Sync. One step more, but the headers were where they belonged.

Everything worked. The picture arrived. Then it disappeared.

I checked: the process I had started was gone. The error log was empty. It hadn't crashed — it had been killed.

The cause was SSH itself. On Windows, an SSH session binds the processes it starts to a job object; when the session closes, the children go with it. The moment I disconnected, I was disconnecting the camera.

We turned the stream into a scheduled task. It no longer depends on a session — it lives on its own, and restarts itself after every disconnection.

The picture arrived. Sitting at my desk, I saw myself on my own screen — but that image had left the laptop beside me, travelled through an encrypted tunnel, and come back.

And here was the real finding: a two-core laptop, ten years old, compresses 1080p30 video while its processor sits almost idle. Thanks to Quick Sync. I had thought the machine was weak. What was weak were my settings.

Not one of the five obstacles was a hardware limitation. All five were configuration, protocol, and operating-system behaviour.

Had I bought a new and powerful machine, every one of those five would have appeared exactly the same.

Building a system is not buying powerful parts. It is finding out, one at a time, why the parts refuse to talk to each other.

⚙️ Technical details — machines, numbers, commands

ThinkPad T470 — i5-6300U · 2C/4T · 8 GB · Intel HD 520 · Windows 10 Pro
Kamera — Akaso (UVC, MJPEG 1920×1080 @30)
Kodlayıcı — Intel Quick Sync (h264_qsv)
Taşıma — MPEG-TS over TCP, SSH reverse tunnel (Tailscale)
Kalıcılık — Windows Scheduled Task

Series
Loading…