Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

IDK, this lacks a lot of examples and explaining what exactly it is for. Is it for remote transcoding only?

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.



I question for why not just SSH into the more powerful computer to run the ffmpeg command like a normal person. Why would you need to install a server and client? There are plenty of binaries available for ffmpeg to avoid compiling from source difficulties.

Solutions like these are the things that just make me tilt my head and make the clueless "huh?" sound.


Because OpenSSH on Windows is a shitshow. Mounted SMB shares can’t be accessed because they’re tied to login sessions, and you can’t mount them from within an SSH session (IIRC in theory you can, but in practice it never worked for me).[1] Which means ffmpeg is practically useless if you need input that you can’t (e.g. livestream) or don’t want to copy in advance, or need output in realtime.

At least that’s why I built something similar in Go for myself.

Before anyone mentions WSL: it either didn’t support GPU passthrough or was very difficult to configure when I set this up a few years ago, don’t know about current status. And you can’t call Windows executables from WSL when you SSH into it.

[1] https://github.com/PowerShell/Win32-OpenSSH/issues/139


there are other ways to mount drives. you can even mount drives on a PC like normal computers with a "/" mount point instead of ridiculous C:\ stuff that does not require WSL.

you can use a URI as an input to ffmpeg which allows for not needing access to a C:\. pretty much any decent NAS will allow access via URI instead of drive letter mounts.

if something was learned during the building of the server/client app, then great if that's why it was done. but it's only one of the 99 ways of skinning the cat, and probably not even close to the best one.


Don’t know why you’re fixated on NAS, I use my program mostly from my Mac laptop and desktop, and it allows me to simply replace ffmpeg with ffmpeg-remote, nothing more, which is not true for ssh (thanks double quoting). The thing took me less than hour to write and has been running for years, I don’t need to learn anything new to justify the trivial amount of investment. I also wrote a simple utility to monitor all my ffmpeg-remote processes, reporting all kinds of statistics, which is more involved if I was running a raw ssh command. And who cares about “the best” way, and who are you to decide my simple solution isn’t the best for me?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: