I’m excited to show case a personal project. It has helped me quite a bit with my home lab, I hope it can help you with yours too! ffmpeg-over-ip has two components, a server and a client. You can run the server in an environment with access to a GPU and a locally installed version of ffmpeg, the client only needs network access to the server and no GPU or ffmpeg locally.
Both and client and the server need a shared filesystem for this to work (so the server can write output to it, and client can read from it). In my usecase, smb works well if your (GPU) server is a windows machine, nfs works really well for linux setups.
This utility can be useful in a number of scenarios:
- You find passing through a (v)GPU to your virtual machines complicated
- You want to use the same GPU for ffmpeg in multiple virtual machines
- Your server has a weak GPU so you want to use the GPU from your gaming machine
- Your GPU drivers in one OS are not as good as another (AMD RX6400 never worked for me in linux, but did so in windows)
I’ve posted some instructions in the Github package README, please let me know if they are unclear in any way and I’ll try to help!
Here's the link: https://github.com/steelbrain/ffmpeg-over-ip
If you are wondering why the binaries are so large, it's because they are packaged-up node.js binaries. I tried to learn a compile-to-native language to rewrite this in so you won't have to download such bloated binaries but didn't get far. I learned Swift and still have a WIP branch up for it[2]. I gave up after learning that there's no well maintained windows http server for swift.
I'm currently on my journey to learn Rust. So maybe one day when I do, you'll see the binary sizes drop.
[1]:https://github.com/steelbrain/ffmpeg-over-ip/releases/tag/v3... [2]:https://github.com/steelbrain/ffmpeg-over-ip/tree/swift-lang
Keep up the good work!
> Note that if hardware acceleration is configured in the calling application, the exact same hardware acceleration modes must be available on all configured hosts, and, for fallback to work, the local host as well, or the ffmpeg commands will fail.
I wanted to mix and match windows and linux, and it was clear rffmpeg wasn't going to work for me.
One plus rffmpeg does have is that it supports multiple target hosts, so it's useful if you want some load balancing action. Although you could do the same with ffmpeg-over-ip, just selecting the servers dynamically but rffmpeg does make it easier out of the box.
How to use it? Do you have example commands?
How is video data transferred between the client and the server?
Would it be possible to connect with SSH to a Linux server, using SFTP with FUSE or Samba with port forwarding for file sharing? This way the server could be zero-configuration (except that ffmpeg has to be installed, but the executable can also be transferred over SSH).
For different people it's going to solve different problems. For me, most recently, I wanted to use the powerful GPU in my gaming machine for transcoding in my plex server with an integrated GPU.
> How to use it? Do you have example commands?
The Github repository should have instructions on how to use. The client usage (once you setup the configuration) is the same as ffmpeg, so anything ffmpeg ... becomes ffmpeg-over-ip-client ... -- you need a server running on the machine with the GPU and then client anywhere network-accessible.
> How is video data transferred between the client and the server?
The server and client only transfer commands, stdout/err etc. The data of the transcoded files themselves is transferred over the network mount. The README of the repository has more details here but essentially you'll want a shared filesystem between the two.
> Would it be possible to connect with SSH to a Linux server, using SFTP with FUSE or Samba with port forwarding for file sharing? This way the server could be zero-configuration (except that ffmpeg has to be installed, but the executable can also be transferred over SSH).
Configuration should be pretty straight forward but let me know if you try it and find it difficult. A template configuration file is provided and you can edit your way out of it. You can absolutely do this with port forwarding even over the internet, provided the file system mount over the network can keep up.
I dont meant to discourage you, but it is possible to replace your entire repo with a simple bash alias:
alias ffmpeg-over-ip='ssh myserver "ffmpeg \"\$@\""'If your usecase is solved by an alias, that's really good! I am glad you can use an alias. My usecase required a bit more so I wrote this utility and am sharing it with my peers
I looked over your source code and just saw a bash wrapper with webserver, so no significant IP. Any potential innovations: like possible distributed transcoding, sharding/partitioning transcoding pipeline to speed-up are missing.
its just a bash wrapper, thats why I commented about bash alias.
I don't mean to sound like a jerk, but I was honestly looking for some innovation about ffmpeg
There's no significant IP in this utility, it's something I wrote for a usecase and it works well for that usecase. I ran the server side on a windows machine, and I did not want to setup a full blown ssh server and expose it over the network for this usecase.
Another thing was logging. The way logging is currently setup really hits the sweet spot for debugability for me. Lastly it's the rewrites. I've used the config to rewrite incoming codecs to something the machine supports.
This is a purpose built utility that does one job and IMO does it fairly well. It's definitely not as complex as Dropbox but also not as simple as an ssh alias. I appreciate you sharing the alias code (not just the comment) so if some of our peers have usecases that could be solved by it, they are welcome to use that as well!
Can you expand on that?
as for bash-ssh solution, you don't need shared FS, if you don't need intermediate results. you can use SCP to get the final result after transcoding has finished. something like:
alias ffmpeg-over-ip='ssh myserver "ffmpeg \"\$@\" /tmp/output/"'
alias download-results='scp myserver:/tmp/output/*.* .'
ffmpeg-over-ip <args> && download-results
Martin Klepmann created an entire database using just bash aliases in his book "Designing Data Intensive Applications"
Submission from 6 months ago, https://news.ycombinator.com/item?id=39929602 https://www.youtube.com/watch?v=0RvosCplkCc
Because if so, the word transcoding does not appear neither in this Show HN nor in the GitHub README.
And I can't think of any other use for this than to perform hardware-assisted transcoding on a remote machine.
Apparently it has nothing to do with OpenGL or CUDA, which are the primary uses for a GPU. And ffmpeg itself has more use cases than just transcoding files.
Oh oof. I thought removing that requirement would be the whole point of something named "FFmpeg-over-IP". Shared filesystem usually involves full trust between machines, bad network error handling, and setting things up by hand (different config on every distro)