steelbrain

You must live in a different New York City than the one I visited. I had the safety calibration of Tallinn, Estonia and Dubai, UAE.

The subway was extremely hostile. People were regularly drugged out of their mind. I saw one guy try to drink a Coca Cola upside down and spilled it all in the bus. Another crazy chased my limited mobility Estonian friend who wanted to visit nyc alongside me when she went alone for groceries.

Could it be that your frame of reference is broken and/or you’re numb to it?

I'm not from the US, but based on my knowledge of your culture, it may be worth it to write a letter to your state's Attorney General

In the US at least, it is illegal to do unsolicited outbound sales with a bot. You have to have humans make these calls.

Sorry to hear about your situation. For the game you're shutting down online services for, forgive my nieve question but how much work is it to expose an environment variable called `GAME_SERVER_URL` and then document the API contract it expects on the other end?

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.

This is not using an eGPU with macOS, ie you can't run your chrome on macOS with its GPU acceleration coming from this eGPU. This is tunneling that eGPU to a Linux VM.

Yes, natively. Thanks Google: https://blog.google/products-and-platforms/platforms/android...

See also: Shrinkflation (https://en.wikipedia.org/wiki/Shrinkflation)

The source code is hosted on Github: https://github.com/gitbutlerapp/gitbutler

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.

Surprised to see that there's no official binaries for arm64 darwin. Meaning macOS users will have to run it through the Rosetta 2 translation layer.

I didnt realize how prolific the OpenClaw author was. Thanks for sharing!

And on top of it, if you develop for native macOS, There’s no official tooling for visual verification. It’s like 95% of development is web and LLM providers care only about that.

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!

Yes, apply the patches on any binary, build it and rename it to ffmpeg and it’ll work over the network with the server and client included

Get a TP Link Tapo! They are like 20-30 bucks and come with ONVIF.

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

To be able to use ffmpeg with its native network capabilities in a usecase of media servers, where you need to stream your input to it, and then get multiple outputs (think HLS) that are streamed back is not possible at this point in time. HTTP, FTP, SFTP, all have their limitations, some are outright broken for HLS usecases, others wont stream seeking.

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.

I am using it as my everything-depot. Beyond this proprietary app, you'll find more than a hundred of my other, open source projects there as well.

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

tl;dr:

- 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'll tell my TV you said that and I'll see if it stops buffering during playback :)

I've traveled around a lot in the past couple years so my situation (read: homelab equipment) has been changing and my usecase has been changing with it. It started out as:

- 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.

Thank you for sharing your experience. Seems like this is not relevant to your setup & usecase.

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

streaming it over the interwebs isn't the issue

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

I've explored sftp since ffmpeg has built-in support for it (-i sftp://...), but the support is quite buggy in code, I hope to submit some patches upstream to be able to change it. FTP in contrast seemed much more stable, at least looking at the code. FTP had some other shortcomings that made it undesirable for my usecase.

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.

Thanks for putting a smile on my face! I am glad you liked it! :)

Thank you for your comment!

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.

I've considered it, thanks for the nudge. Since the patches are quite specific to my usecase:

- https://github.com/steelbrain/ffmpeg-over-ip/blob/main/fio/f... - https://github.com/steelbrain/ffmpeg-over-ip/tree/main/patch...

I am not sure they'll be accepted for upstreaming, but in exploring the options, I noticed ffmpeg has sftp:// transport support and there were some bugs surrounding that. I do intend to publish some patches for those.

You're going to have to chalk this up to human error, in the excitement to post it, I omitted Show HN:

Very cool! Thank you for sharing! I didn't know this existed, so now I'm curious how they solved it :)

My usecase is just-in-time media transcoding, I'll see if PeerTube remote runners support it

I tried to answer it about a year and half ago and that answer is still mostly correct: https://news.ycombinator.com/item?id=41743932

You can mix and match operating systems, macOS, Windows, Linux, you do not need sudo privileges.

rffmpeg needs a shared file system which could be a huge pain to setup: https://github.com/joshuaboniface/rffmpeg/blob/master/docs/S...

ffmpeg-over-ip patches ffmpeg and only needs one port open for the server, then you just run the binary, no mounts needed at all.

I am thinking of adding a Windows application with an installer and a tray icon that you can use for some basic settings like changing port or password, or toggling automatic startup.

For linux, I am thinking of adding convenience helpers around systemd service installation

cool idea. can you elaborate on IO and how the ffmpeg-server reads blocks from the client? that would seem to be a big blocker

ffmpeg-server runs a patched version of ffmpeg locally, ffmpeg requests to read some chunks (ie give me video.mp4) through our patched filesystem (https://github.com/steelbrain/ffmpeg-over-ip/blob/main/fio/f...), which gets sent over the same socket that the client established, client receives the request, does the file operations locally and sends the results back over the socket to the server, and server then sends them to ffmpeg.

ffmpeg has no idea its not interacting with a local file system

Hi HN!

I'm excited to show case an update to a personal project of mine. Its called ffmpeg-over-ip and it allows you connect to remote ffmpeg servers, so if you have one machine with a GPU (could be your windows gaming laptop, gaming PC, a macbook?) and a machine (or VM, docker container etc) without a GPU, you could use the remote GPU to do GPU-accelerated video conversion.

The way it works is pretty neat, there are two components, a server and a client.

- The server (has the GPU) comes with a patched up ffmpeg and listens on a specified port - The client (without the GPU) connects to the server, takes the file IO requests from the server and runs them locally.

ffmpeg doesn't know that its not dealing with a local filesystem, so this approach works with multiple inputs or outputs like HLS, and is perfect for home media servers like Plex or Jellyfin or Emby.

One server can offer up its GPU to as many clients as needed, all clients offer up their own filesystems for their requests, the server also comes with a static build of ffmpeg bundled (built from jellyfin-ffmpeg scripts) so all you have to do is create a config file, set a password and you're good to go!

It's been about a year and half since this was last submitted (https://news.ycombinator.com/item?id=41743780). The feedback at the time was around the difficulty of sharing a filesystem between the machines so that should no longer be a problem.

This has been really useful in my local setup, I hope you find it useful. If you have any further questions, the website has some FAQs (linked in github repo), or you could post them here and I'll answer them for you!

Thanks!