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

This is neat. The thing I would most want in the README is a benchmark section showing where it wins and where it does not. My guess is long GPU bound transcodes look great and tiny file churn workloads probably do not. Having that boundary spelled out would make adoption a lot easier.

I am thinking of adding a Windows application with an installer and a tray icon that you can use for some basic settings like changing port or password, or toggling automatic startup.

For linux, I am thinking of adding convenience helpers around systemd service installation

Very cool. Peertube supports remote runners [1] [2], might take a look for inspiration. As a distributed compute enthusiast, big fan of of this model for media processing.

[1] https://docs.joinpeertube.org/maintain/tools#peertube-runner

[2] https://docs.joinpeertube.org/admin/remote-runners

Very nice. Could this concept be applied to have ffmpeg running in webassembly, and over HTTP?

Similar to https://github.com/ffmpegwasm/ffmpeg.wasm ?

Exactly - but can transcoding be remote?

Very cool! Thank you for sharing! I didn't know this existed, so now I'm curious how they solved it :)

My usecase is just-in-time media transcoding, I'll see if PeerTube remote runners support it

Roughly what you'd expect https://docs.joinpeertube.org/contribute/architecture#remote... basically a request queue that gets periodically queried by trusted runners, fulfilled, updated.