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
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
> 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
Is video that cpu/gpu bound that streaming it over the interwebs isn't the issue?
Maybe my use cases for ffmpeg are quite narrow, but I always get a speedup from moving the files off my external hard-drive, suggesting that is my current bottleneck.
> 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
Ah, yeah, so this is probably for more professional workflows where you have a workhorse somewhere. Perhaps even in the cloud as long as the files are close by as well? My use case would be more "my computer sucks, so would be nice to do it on a beefy cloud computer", but of course no time is saved when just reading my files is slow, heh.
very clever and thanks for explaining. for gpu-bound processes, which are common ffmpeg use cases, this is a great approach