3 ms·

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

• steelbrain 8mo ago
  > 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/fio.h 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
  • tonymet 8mo ago
    very clever and thanks for explaining. for gpu-bound processes, which are common ffmpeg use cases, this is a great approach
  • matsemann 8mo ago
    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.
    • steelbrain 8mo ago
      > 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
      • matsemann 8mo ago
        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.