Servers have a real cost, nobody is denying that, but I think the people who bought the game should have an option/alternative in case the servers are down.

I was really hoping we'd see some competition to Github, but no, this is competition for the likes of the Conductor App. Disappointed, I must say. I am tired of using and waiting for alternatives of, Github.

The diff view in particular makes me rage. CodeMirror has a demo where they render a million lines. Github starts dying when rendering a couple thousand. There are options like Codeberg but the experience is unfortunately even worse.

Thinking out loud here, but you could make an application that's always running, always has screen sharing permissions, then exposes a lightweight HTTP endpoint on 127.0.0.1 that when read from, gives the latest frame to your agent as a PNG file.

Edit: Hmm, not sure that'd be sufficient, since you'd want to click-around as well.

Maybe a full-on macOS accessibility MCP server? Somebody should build that!

EZVIZ is another ban-evading arm of HIKVision, easily available in Europe and has RTSP (confirmed) with alleged support of ONVIF as well.

I would have very much loved to use the built-in capabilities instead of patching ffmpeg to add a vfs layer and spend a ton of time figuring out the build pipeline once you add all the codecs and hwaccels. I do hope to be able to change this in the future, I've identified several bugs that I intend to submit patches for.

Including the building blocks of said proprietary app: https://github.com/steelbrain/XMLKit & https://github.com/steelbrain/IPCamKit

- Client makes request to server (which opens a bidirectional network socket)

- Server uses that bidirectional socket, spawns a local patched ffmpeg with vfs-like characteristics

- ffmpeg (using client-server bidrection socket) does input/output operations, treating client filesystem as if it was local

Thus client doesn't need to open any ports, or expose its filesystem in a traditional mounting manner, and one server can handle filesystems & requests of any amount of clients.

- I dont want to unplug the GPU from my gaming PC and plug it into my linux server

- Then: I dont want to figure out PCI forwarding, I'll just open a port and nfs to the containers/vms (ffmpeg-over-ip v4 needed shared filesystem)

- Now: I have a homelab of 4 mini PCs and one of them has an RTX 3090 over Oculink. I need it for local LLMs but also video encoding and I dont want to do both on the same machine.

But you've asked a more fundamental question, why would people need hardware accelerated video decoding in the first place? I need it because my TV doesn't support all the codecs and I still want to watch my movies at 4K without stuttering.

People who need this know who they are. Not everything is for everybody.

The hope is that you stream over LAN not the interwebs!

> I always get a speedup from moving the files off my external hard-drive

Based on your description, it does seem like your ffmpeg may be IO limited

That was the one motivation, the other one was that it would require rewriting arguments going into the server. What you're describing was essentially what ffmpeg-over-ip v4 (and its earlier versions!) was, and the constant feedback I'd heard was that sharing filesystems is too much work, ssh servers on windows and macOS are a bad experience, people want to use a bundled solution.

Forking ffmpeg was no easy task! Took forever to figure out the build process, eventually caved in and started using jellyfin build scripts, but that has the downside of being a few versions behind of upstream HEAD.

The usecase for something like this is when you control both sides, server & client. There is some basic HMAC auth built into each request.

> I would recommend to sandbox if at all possible.

Since the server is a standard binary that doesn't need any special permissions, you could create the most locked down user in your server that only has access to a limit set of files and the GPUs and it'll work just fine. This is encouraged.