Tips for Battery Optimization

[gjgress]

I often need to work from my laptop without access to my charger, and so running mpv in the background with default settings all the time is a serious battery drain.

Fortunately, mpv can be easily configured to reduce power-- especially in this case, when one does not need to worry about things like video/audio desync, cutting out some of the superfluous mpv features goes a long way.

I'm just opening this issue to share my mpv config optimized for this script in particular, in case other users have the same needs. In your local mpv config location (either ~/.config/mpv/mpv.config or /etc/mpv/mpv.config), add to your config the following profile:

[lowpower]
profile-desc = "Profile designed to run mpv and minimize battery usage, perfect for using mpv for backgrounds and whatnot. Set for files with no audio"
deband=no
gpu-dumb-mode=yes
hwdec=auto-safe
hwdec-codecs=all
interpolation=no
osc=no
terminal=no
video-sync = display-desync
vo=gpu
vd-lavc-fast
vd-lavc-skiploopfilter=all
ytdl=no

Of course, you have to enable the profile for this to work. In the video-wallpaper.sh script, adding the --profile=lowpower flag to the xwinwrap call will do exactly this.

Obvious caveat: I can't guarantee this profile will work on all computers. If mpv does not work with this profile, try removing the hwdec-codecs=all line or the vo=gpu line. In terms of performance, this reduced my power usage to 3% of the original power usage (even lower than my compositor!), and I didn't notice a significant drop in quality.

I don't think I could in good faith suggest adding any of these flags to the default behavior in the repo. That being said, these options can be toggled directly by just adding the flag to mpv. The safest options are:

• interpolation=no
• video-sync=display-desync (disables audio/video syncing, which is unnecessary for this anyway)
• hwdec=auto-safe (enables hardware decoding, the "safe" aspect is supposed to prevent issues if codecs aren't available)
• vd-lavc-fast (uses optimizations which make small sacrifices in video quality)

I think vd-lavc-skiploopfilter is also safe too.

I hope this helps!

[ZediAlreadyTaken]

Will this also pause the playback when the desktop is out of focus? If not, then is there something we could change to achieve such behavior?

[gjgress]

Hmm, that's a tougher question. To get such behavior, you would have to either:

• Have an active process which sits and looks for desktop focus commands (impractical and probably invasive) or
• Modify the desktop focus behavior directly to include running such commands

I use a compsoitor with semi transparent windows, so for me I wouldn't want such behavior. And while it would save battery power I'm sure, it wouldn't make a massive difference (no more than turning off your compositor)

That being said, since this profile relies on mpv to utilize the gpu, its possible (I don't know) that it could affect games. But I think a much simpler solution would be to map a key to video-wallpaper.sh --start' andvideo-wallpaper --stop`, personally.

[SwallowYourDreams]

I don't think I could in good faith suggest adding any of these flags to the default behavior in the repo. That being said, these options can be toggled directly by just adding the flag to mpv. The safest options are:

Thank you for your suggestion. I'll try it out and will consider adding it to the script. Could you elaborate on the "risks" associated with using this config or the corresponding flags?

[gjgress]

Hi SwallowYourDreams,

I'll do my best (I'm not a mpv power user).

• gpu-dumb-mode=yes Big power saver. This is MPV's description:

This mode is extremely restricted, and will disable most extended features. That includes high quality scalers and custom shaders!

It is intended for hardware that does not support FBOs (including GLES, which supports it insufficiently), or to get some more performance out of bad or old hardware.

This mode is forced automatically if needed, and this option is mostly useful for debugging. The default of auto will enable it automatically if nothing uses features which require FBOs.

This option might be silently removed in the future.

It's probably not a good idea to enable this by default because it disables pretty much all new features. It's just an easy way to disable a lot of heavy resources like shaders that consume power pretty heavily. As a result, I don't think its a good idea to enable in general (but it could be worth using on your own config if you are still starved for battery)

• hwdec = auto-safe Here is what MPV says about it:

Specify the hardware video decoding API that should be used if possible. Whether hardware decoding is actually done depends on the video codec. If hardware decoding is not possible, mpv will fall back on software decoding.

Hardware decoding is not enabled by default, because it is typically an additional source of errors. It is worth using only if your CPU is too slow to decode a specific video.

Most modern computers use hardware which is compatible with hardware decoding. This is also another huge power saver. Auto-safe means that it will only use codecs which are white-listed (I think the white-listing is determined by the hardware, but I don't know for sure). My understanding is that if your hardware does not support decoding, this will simply disable hwdec anyway.

• hwdec-codecs=all Enables all the hardware decoding codecs. This gives hwdec more options to choose from. Can't recommend because some codecs may cause issues for other users.
• interpolation=no This is enabled by default, so it's not necessary, but it disables frame interpolation. This obviously saves CPU power, and framerate isn't a huge deal when it comes to wallpapers.
• osc=no Just disables the on-screen controller (i.e. pause play buttons etc.) Obviously this is unnecessary because it is a wallpaper, but I also don't know how much power it really saves.
• terminal=no This just disables the terminal and stdin/stdout/stderr . I don't think you can even access the terminal it loads so there's no reason for it to use a terminal
• video-sync=display-desync This is another huge one. Basically, MPV has some different methods for synchronizing video and audio. This is actually a pretty tough job sometimes, and so the default method can be resource intensive. Because this is a wallpaper, I can't think of a scenario where anyone would care about the audio synchronizing. The choice display-desync means that MPV syncs the video to the display, and just ignores the audio syncing entirely. There is another option desync which also allows video to not synchronize, which is probably also a safe option, but I don't think it would offer any significant improvement.
• vo=gpu This specifies the video output backend that MPV uses. I don't know what the default is, but gpu sets it so MPV uses GPU-accelerated video output drivers. Since CPU usage is where most of the power is going, relegating the video output driver to the GPU is a huge energy saver. This option is pretty safe, because the option has built-in fallbacks.
• vd-lavc-fast This is a setting for video decoding. It enables optimizations which do not comply with the format specification and so has potential issues; stuff like simpler dequantization, simpler motion compensation, and some other checks. Ultimately it makes the video decoding go much faster, and hence less power. This won't cause any crashes or anything, but may affect the visual output (on my end, I had no visible changes)
• vd-lavc-skiploopfilter=all During H.264 decoding, the decoder uses a loop filter, which helps it maintain quality. However, it is really common for high bitrate HDTVs to skip the loop filter altogether, as it provides huge speed-up with little visible quality loss. Also safe to enable, but the possible visual effects are probably dependent on the user.
• ytdl=no Disables youtube-download. I can't think of a reason to have it enabled.

To be honest, playing around with MPV flags is dangerous business because it is so difficult to standardize across different machines. That's why I decided to open an issue with this information instead of a pull request; that way if other uses are concerned about the battery usage, they can experiment for themselves and find a configuration that works for them.

Upon further reflection, I don't know if I would suggest any of these flags to be enabled by default. It's just a headache waiting to happen.