Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replace fluent-ffmpeg with custom cli wrapper + pidusage package? #73

Open
friday opened this issue Apr 5, 2024 · 1 comment
Open

Comments

@friday
Copy link
Member

friday commented Apr 5, 2024

I looked into how we are measuring CPU usage with our fluent-ffmpeg fork, and I can see some issues with it. For starters, time is a shell builtin in bash, zsh and fish, and then the binary is not needed, and if not installed the local pipeline will fail. It will also fail for Windows. Maybe it should degrade gracefully instead so we don't get any CPU measurements, but I think we still can get them with pidusage (which should work cross platform).

This only works if we have access to the pid. From what I have seen fluent-ffmpeg doesn't expose the pid or the process, but it's really not that hard to write a cli wrapper for ffmpeg. I have already done that previously (this doesn't help "build" the command for you unlike fluent-ffmpeg, making it much lighter and easier to maintain, it just helps you run the command and get the progress updates).

The pidusage package also recommends process.cpuUsage, which also works cross platform, but it's is not available on the child proccess, and I'm not sure if it's possible to use it with child processes). Perhaps you can if you fork the process, then spawn a command from there, but I'm not sure if it measures the child process cpu usage then?

@grusell
Copy link
Contributor

grusell commented Oct 4, 2024

Just noticed this issues. I agree that it should degrade gracefully if the 'time' command is not available.

The downside with pidusage (or with calculating cpu usage from procfile in general) is that the procfile is not available after the process has exited, so poll interval needs to be short compared to the total runtime of the process to get an accurate value. This is why I decided to use time instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants