Opened 10 months ago
Last modified 10 months ago
#10447 new enhancement
On macOS ffmpeg should create a power assertion to prevent system sleep while job runs
Reported by: | porg | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | ffmpeg |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Problem
- Started a long encoding job, CPU was at 540% on my 8 cores, fans on, encoding speed showed as circa 2.5x.
- Left MacBookPro unattended in good spirit to come back to a finished result.
- Came back some 30min later or so. Screen was dimmed: Expected. But: Fans silent...
- Touched keyboard (to wake it from sleep or at least dimmed screen with the system running in a reduced power state, not sure which of the two it was)
- ffmpeg encoding speed now showed at a crawling 0.05x or similar (accumulated average over time).
- Conclusion: The system has been in sleep or reduced power state and the encoding had came to a halt or slowdown.
Reproduction
- Start a long ffmpeg job
- Check macOS power assertions with
pmset -g assertions
- There is no power assertion by ffmpeg which would prevent system sleep.
Competition & Best Practices
HandBrake on macOS automatically sets a user requested power assertion:
$ pmset -g assertions [...] pid 1234(HandBrake): [0x0003118f00019293] 00:00:15 PreventUserIdleSystemSleep named: "HandBrake is currently scanning and/or encoding" [...]
Proposed Solution
- Offer "prevent-sleep" as an argument or config.
- Ideally on macOS to be compliant with conventions this is ON as a default and needs to be opted out.
- This should not re-invent the wheel but utilized the proper mechanism for this on the respective platform. (macOS in my case).
macOS I/O Kit power assertions
- On macOS processes can create a power assertion to prevent system sleep until they are done and the assertion gets revoked.
- This is great to start long jobs (like video encodings) unattended and be sure that this job runs uninterrupted and unthrottled until done. Then the system may go to sleep (according to your setup).
- See manpage and its chapters/keywords
- pmset -- manipulate power management settings
-g assertions
- caffeinate -- prevent the system from sleeping on behalf of a utility
-i
Create an assertion to prevent the system from idle sleeping.- caffeinate -i ffmpeg ...
- pmset -- manipulate power management settings
Environment
- ffmpeg 5.1.2 (installed via brew)
- macOS 11.7.7 Big Sur
Workaround
- Invoke
ffmpeg
yourself viacaffeinate -i ffmpeg ...
. - After 10 secs I checked pmset -g assertions and saw that it had created a corresponding assertion indeed:
pid 12345(caffeinate): [0x0003105200019286] 00:00:10 PreventUserIdleSystemSleep named: "caffeinate command-line tool" Details: caffeinate asserting on behalf of 'ffmpeg' (pid 12345) Localized=THE CAFFEINATE TOOL IS PREVENTING SLEEP.
Change History (2)
comment:1 by , 10 months ago
comment:2 by , 10 months ago
As written in the ticket:
- On macOS the convention is that apps which perform long term jobs usually themselves start their process with a power assertion. And not hand that over as a user responsibility.
- Even Pro apps, with the respective Pro user base.
- Needing to manage power/CPU per app is simply not a Mac thing. (Luckily, I say).
- I stated HandBrake as an example for another popular multi platform video encoding app, which adheres to this.
- And also several other batch processing apps (e.g. image processing) on the Mac set a power assertion for their long jobs automatically.
It's how things work on the Mac platform
- and I'd love if the
ffmpeg
team would add a generic power-option a for all platforms which then bind to the platform specific calls - and ship/build the Mac
ffmpeg
version with the power assertion option ON by default.
Note:
See TracTickets
for help on using tickets.
Ha? It is not our job to do that. WHAT?