logoalt Hacker News

FFmpeg-over-IP – Connect to remote FFmpeg servers

66 pointsby steelbraintoday at 6:26 PM26 commentsview on HN

Comments

steelbraintoday at 6:26 PM

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!

show 4 replies
longislandguidotoday at 8:51 PM

On the surface this seems like a terrible idea:

FFmpeg is mountains of extremely complex C code whose entire job is processing untrusted inputs.

Choosing to make such code network-enabled if you can't trust your inputs, I would recommend to sandbox if at all possible. Otherwise you are asking for trouble.

show 1 reply
deadlyllamatoday at 9:07 PM

I've been meaning to build exactly this for a while, and my waiting has been rewarded by someone else doing it!

Had you thought about using FUSE on the server side, rather than patching ffmpeg? Like a reverse sshfs? That avoids patching the ffmpeg binary, which allows usage of wierd and wonderful ffmpeg binaries with other people's patches.

I'd be interested in seeing how well it works with SBC GPUs - many have hardware decoding and encoding, and their vendors love to fork ffmpeg.

show 1 reply
offmycloudtoday at 7:34 PM

How does this differ in performance from rffmpeg?

https://github.com/joshuaboniface/rffmpeg

show 1 reply
throwaway81523today at 8:22 PM

This sounds like a nice project, but is it a Show HN without putting that in the title, because of the stigma that Show HN has recently acquired?

show 1 reply
naikrovektoday at 7:43 PM

This is software which basically replicates what Plan9 gives you out of the box.

Dammit I really wish Plan9 had taken off. It isn’t perfect but it does a much, much better job of helping me run my applications in ways that I want.

If anyone doesn’t already know, one method of Plan9 remote access is to “cpu” into a remote machine which has the hardware you need. Your local filesystems go with you, and your environment on the remote machine consists of your local filesystems mounted to the remote machine, but only for you, and all applications you run in this context execute on the cpu of the remote machine and have access to the remote machines hardware, but your local filesystems. Imagine SSHing into a remote machine and your entire environment goes with you, development tools and all. That’s what Plan9 does for you.

So if I “cpu” into a machine without ffmpeg, but with a GPU and I run ffmpeg, not only will it work, but I can tell ffmpeg to use a hardware encoder with a simple command line flag, and it’ll work.

toomuchtodotoday at 7:32 PM

Thanks for the update and continuing to share this project. What does the roadmap look like into the future?

show 2 replies