Add backend support for reducing energy use

[low-batt]

This commit will:

• Add a new reduceEnergyUse setting to Preferences
• Add a new configureEnergyUse method to PlayerCore
• Change PlayerCore.startMPV to call the new configureEnergyUse method

When the reduceEnergyUse setting is enabled the configureEnergyUse method will apply mpv's builtin fast profile to reduce the energy used by mpv.

As the fast profile does not support restoring the old values of the options set by the profile, changes to the reduceEnergyUse setting require IINA to be restarted.

• I have read CONTRIBUTING.md
• This implements/fixes issue #.

---

Description:

[low-batt]

This PR only provides the backend support for this feature. I did not include UI as it would generate merge conflicts with some outstanding PRs.

This can be tested by enabling the feature using the defaults command:

defaults write com.colliderli.iina reduceEnergyUse true

See issue #5697 for details on the need for this change.

[lhc70000]

Is there a user request for this? I'm not sure if it's appropriate to treat them as equivalent, because MPV has many profiles, but this setting only has two options (reduce energy use or not). A user conf file can also override this, and the user might not know what's happening just looking at the name of this setting. Perhaps a profile selector would be better?

[low-batt]

Good point about expanding this to be a general profile settings.

This is about issue #5697 where users with old Macs are complaining because the increase in energy use is noticeable for them and the improvement in picture quality, not so much. This is a regression for these users.

This is not for advanced users who know mpv and can create a mpv.conf file.

I was expecting we'd add a Reduce energy use setting either in general or in video. It would need some sort of explanation about reducing video quality and the need to restart IINA after changing the setting.

One of the users thought IINA ought to just do this by default for Intel Macs. I'm thinking that would not be appropriate for the newer more powerful Intel Macs.

Anyway, I only coded up the backend as I wanted advice on how to handle this.

Thoughts?

[uiryuu]

Tried to list all available builtin profiles of the current release of mpv:

mpv --profile=help                                                                                    
Available profiles:
	enc-to-hp-slate-7	MP4 for HP Slate 7 (1024x600, crazy aspect)
	enc-to-nok-6300	3GP for Nokia 6300
	enc-to-nok-n900	MP4 for Nokia N900
	enc-to-dvdntsc	DVD-Video NTSC, use dvdauthor -v ntsc -a ac3+en (MUST be used with 4:3 or 16:9 aspect, and 720x480, 704x480, 352x480 or 352x240 resolution)
	enc-to-dvdpal	DVD-Video PAL, use dvdauthor -v pal -a ac3+en (MUST be used with 4:3 or 16:9 aspect, and 720x576, 704x576, 352x576 or 352x288 resolution)
	enc-f-webm	VP9 + Opus (for WebM)
	enc-f-mp4	H.264 + AAC (for MP4)
	enc-f-avi	MPEG-4 + MP3 (for AVI)
	enc-f-3gp	H.263 + AAC (for 3GP)
	enc-v-vp9	VP9 (libvpx)
	enc-v-vp8	VP8 (libvpx)
	enc-v-mpeg4	MPEG-4 Part 2 (FFmpeg)
	enc-v-mpeg2	MPEG-2 Video (FFmpeg)
	enc-v-h264	H.264 (x264)
	enc-v-h263	H.263 (FFmpeg)
	enc-a-opus	Opus (libopus or FFmpeg)
	enc-a-vorbis	Vorbis (libvorbis or FFmpeg)
	enc-a-mp3	MP3 (LAME)
	enc-a-ac3	AC3 (FFmpeg)
	enc-a-aac	AAC (libfdk-aac or FFmpeg)
	box	
	sub-box
	osd-box
	sw-fast
	low-latency	
	gpu-hq	
	high-quality	
	fast	
	encoding	
	libmpv	
	builtin-pseudo-gui	
	pseudo-gui	
	default

Only a few of them are reasonable as a option in our UI.

Also I think its better to implement this under Advanced > mpv Settings and use --profile=<name> at start instead of --apply-profile at runtime:

You can list profiles with --profile=help, and show the contents of a profile with --show-profile= (replace with the profile name). You can apply profiles on start with the --profile= option, or at runtime with the apply-profile command.

[uiryuu]

I implemented a popup button to select builtin mpv profiles:

The code is on the mpv-profile branch. Verified by observe the scale option when selecting Fast and High quality profiles.

[low-batt]

This does not address the problem I was trying to address…

This goes into IINA design philosophy. Which of these best describes IINA?:

1. Video player that uses mpv for its implementation
2. UI frontend for mpv

I would say that IINA is a more 1. than 2. For the most part mpv is mostly hidden. It is exposed in Advanced settings and in the Audio Filters and Video Filters windows. The IINA homepage only says:

Powered by the open source media player mpv, …

The problem I was trying to solve is that when IINA upgraded from mpv 0.35.0 to 0.38.0 the amount of CPU/energy used during playback greatly increased due to mpv deciding to change the defaults of several options to slightly improve picture quality. This increased load caused problems for users with old hardware. Users that understood mpv probably used IINA's Advanced settings to workaround this. Users that don't know what the Advanced settings are all about only knew that IINA 1.4.x had performance problems and went back to IINA 1.3.5.

This is the reason why I was suggesting a Reduce energy use setting either on the General or Video/Audio tabs. This was to address users that don't know about mpv. I did not create UI for this as I was slightly uncomfortable about going to far with hiding mpv. Anyway, I think we missed the boat on this as if we were going to address this it should have gone into 1.4.x as users with old Macs may be trapped on macOS Catalina. At this point I'm thinking this PR should probably just be closed.

I believe adding support for profiles would address discussion #6032. But to me the first step would be to address the serious problems in the existing Additional mpv options setting pointed out in that discussion. Users need to be able to select the position at which to add new entries as well as being able to change the order of existing entries.

There are other ways in which IINA falls short on being a "UI frontend for mpv". In some cases, for example HDR settings, IINA will stomp on advanced user's attempts to apply mpv configuration. In MPVController there are a couple of examples of IINA not applying mpv configuration when it detects the user has set the option in Additional mpv options. However that won't work for mpv configuration applied dynamically in a mpv.conf file. IINA probably needs to support a "hands off" list of mpv options in Advanced settings to allow users to override IINA in more complex cases, such as IINA's dynamic changing of HDR related configuration.

The problem that comes up the most with advanced configuration is the failure to support dynamic key assignment from Lua scripts. I remember @svobs discussing changes needed to support this with the mpv project. I don't know if he was able to solve this problem.

Tuesday is my busy day. I will take a look at the mpv-profile branch tomorrow.

[uiryuu]

I believe adding support for profiles would address discussion #6032. But to me the first step would be to address the serious problems in the existing Additional mpv options setting pointed out in that discussion. Users need to be able to select the position at which to add new entries as well as being able to change the order of existing entries.

Check out the current dev branch, this has already be fixed by 712d9cd :)

While I agree you that we indeed hide most of the mpv features from the users, but having the ability to choose builtin mpv profile is still important imo. So may be we can move this feature to General or A/V tab and rename it to "video quality", rename the options, with some descriptive text to tell users the difference between the options.

[low-batt]

First on this:

Check out the current dev branch, this has already be fixed by 712d9cd :)

I did before I posted that. I had selected a row, clicked on + and expected to see a new entry before the selected one, but the new entry was added to the end. The last table that I can remember had a way to order entries displayed ^v buttons on a row when it was selected. I was looking for that. I think I tried dragging an entry. I must have not properly grapped the entry. So I thought nothing had been changed yet.

On this:

So may be we can move this feature to General or A/V tab and rename it to "video quality", rename the options, with some descriptive text to tell users the difference between the options.

I'd leave this setting on the Advanced tab, especially since it requires a restart like some of the other setting on the Advanced tab.

However…

I had forgotten about the details of this PR. It is coming back to me now and I'm thinking we should not make any changes to IINA at this point in time. More on this after some info and experiments…

On this:

use --profile= at start instead of --apply-profile at runtime

It is just apply-profile, without --, since that is a mpv command:

apply-profile <name> [<mode>]
Apply the contents of a named profile. This is like using profile=name in a config file, except you can map it to a key binding to change it at runtime.

The mode argument:

• apply
  Apply the profile. Default if the argument is omitted.
• restore
  Restore options set by a previous apply-profile command for this profile. Only works if the profile has profile-restore set to a relevant mode. Prints a warning if nothing could be done. See Runtime profiles for details.

It is really desirable for IINA to respond dynamically to changes to a setting. Using this command with the restore argument allows IINA to properly respond to a user disabling the Reduce energy use setting. Except this did not work because mpv did not include profile-restore in the fast profile. Before exploring that with the mpv project I wanted us to decide on exactly how we wanted to handle this.

The following shows the other reason why I was using this command…

I set mpv Builtin profile to Fast:

Checking the log files I see IINA is setting the option to fast:

low-batt@gag 2026-05-13-15-02-00_nT801R$ grep -i profile iina.log | grep -i fast
15:02:00.945 [mpv0][v] Set option: profile=fast

But checking the mpv log it is like that did not happen:

low-batt@gag 2026-05-13-15-02-00_nT801R$ grep -i profile mpv.log | grep -i fast
low-batt@gag 2026-05-13-15-02-00_nT801R$ 

Nothing. Nothing at all.

If instead I enable Use config directory and set profile=fast in mpv.conf I see this in the mpv log file:

[   0.216][v][cplayer] Setting option 'profile' = 'fast' (flags = 4)
[   0.216][v][cplayer] Applying profile 'fast'...
[   0.216][v][cplayer] Setting option 'scale' = 'bilinear' (flags = 4)
[   0.216][v][cplayer] Setting option 'dscale' = 'bilinear' (flags = 4)
[   0.216][v][cplayer] Setting option 'dither' = 'no' (flags = 4)
[   0.216][v][cplayer] Setting option 'correct-downscaling' = 'no' (flags = 4)
[   0.216][v][cplayer] Setting option 'linear-downscaling' = 'no' (flags = 4)
[   0.216][v][cplayer] Setting option 'sigmoid-upscaling' = 'no' (flags = 4)
[   0.216][v][cplayer] Setting option 'hdr-compute-peak' = 'no' (flags = 4)
[   0.216][v][cplayer] Setting option 'allow-delayed-peak-detect' = 'yes' (flags = 4)

I came to the conclusion that for some reason --profile cannot be used by clients of libmpv, so I switched to the apply-profile command.

However Experimenting further… Despite there being nothing in the mpv log file the changes the fast profile applies seem to have been made:

low-batt@gag ~$ echo '{ "command": ["get_property", "correct-downscaling"] }' | socat - /tmp/mpv-socket | jq
{
  "data": false,
  "request_id": 0,
  "error": "success"
}
low-batt@gag ~$ 

In either case if I try and check the value of the profile option something goes wrong:

low-batt@gag ~$ echo '{ "command": ["get_property", "profile"] }' | socat - /tmp/mpv-socket | jq
{
  "request_id": 0,
  "error": "error accessing property"
}
low-batt@gag ~$ 

Probably some of this is simple to fix in mpv, but we don't want to distract them with that now as we have critical mpv problems that need to be fixed.

I'm thinking we close this PR and don't take any action on this at this time. Eventually we report the odd mpv behavior to the mpv project.

Some feedback on the changes even though I don't think we should implement anything now…

This error:

13:05:18.839 [settings][e] Default for Key(rawValue: "mpvProfile") is of type __NSCFNumber and cannot be cast to Bool

Is because the new logging that lists settings that were changed from their defaults needs to be updated when a new settings value class is added. Possibly we could avoid this by making it data driven. To do that you might change the settings from being static Key variables to enum constants that provide all the information to "define" the setting. That would be such a big change that I did not look into doing that.

This is the old way:

      chkErr(setOptionString(MPVOption.ProgramBehavior.profile, Preference.MpvProfile(rawValue: profile)!.description, level: .verbose))

Other code that passes settings values to mpv now does this:

      return String(describing: Preference.enum(for: key) as Preference.HardwareDecoderOption)

To match up with the other enums declared in Preference the enum constants should appear first instead of last as seen here:

  enum MpvProfile: Int, InitializingFromKey, CaseIterable {
    static let defaultValue: Preference.MpvProfile = .default

    init?(key: Preference.Key) {
      self.init(rawValue: Preference.integer(for: key))
    }

    var description: String {
      switch self {
      case .default: "default"
      case .fast : "fast"
      case .high_quality: "high-quality"
      case .low_latency: "low-latency"
      }
    }

    case `default` = 0
    case fast
    case high_quality
    case low_latency
  }