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 8 hours ago | parent [-]

> 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

▲

matsemann 7 hours ago | parent | next [-]

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 6 hours ago \| parent [-]
		> 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

▲

tonymet 8 hours ago | parent | prev [-]

very clever and thanks for explaining. for gpu-bound processes, which are common ffmpeg use cases, this is a great approach