search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.5k stars 2.92k forks source link

An easy way to switch profiles such as a flush-config option #4843

Open ekce opened 7 years ago

ekce commented 7 years ago

mpv version and platform

mpv 0.26.0-237-g5771f7abf4 (C) 2000-2017 mpv/MPlayer/mplayer2 projects

Actual behavior

Suppose an mpv.conf as follows.

profile=general-content

[general-content]
profile-desc="a profile for normal every day content"
...

[special-content]
profile-desc="a special profile for special content"
...

Calling mpv --profile=special-content will append the options under the special-content to the rest of the options. Calling mpv --no-config --profile=special-content gives an unknown profile error (and disables input.conf along with other config files).

Desired behavior

Some nice way to run mpv on special profiles reserved for special content.

There are many ways to achieve this. One way would be to add an option that flushes all the configuration loaded via mpv.conf up to that point without disabling the config file itself (as well as other config files). Something like:

mpv --flush-config --profile=special-content

or alternatively:

profile=general-content

[general-content]
profile-desc="a profile for normal every day content"
...

[special-content]
profile-desc="a special profile for special content"
flush-config
...

and mpv --profile=special-content

Current solution/workaround

Currently the only ways to switch between profiles are:

[general-content] profile-desc="a profile for normal every day content" fs=yes ...

[negate-general-content] profile-desc="for each option in general-content add an option setting it back to mpv defaults" fs=no ...

[special-content] profile-desc="a special profile for special content" profile=negate-general-content ...

kkkrackpot commented 7 years ago

@ekce Afaik, --no-config option tells mpv not to use config file at all, therefore mpv doesn't see any profiles there, being them "special" or not, and gives unknown profile error.

Otherwise, personally I can't fully understand what exactly you try to achieve. If you want your general content being played in fullscreen mode, and your special content being played in window mode, you could use something like this:

fullscreen=yes

[special content]
fullscreen=no

Also there's a script (autoprofiles as far as I remember) that switches profiles automatically depending on specified conditions.

ekce commented 7 years ago

I understand why the current behavior works the way it does (no-config simply blocks all config files and is likely meant for debugging and adding options via the command line effectively appends them to the top level area of mpv.conf). Also, the fs=yes and fs=no were just meant an example to illustrate what I meant by a negation profile.

For a better example suppose a user has a special profile for SVP (note SVP uses vapoursynth and requires certain options to work) and that they only use SVP on content where it is not likely to produce artifacts (not something that one could possibly describe with lua code via autoprofiles). Moreover, suppose that options contained in the user's main profile are not desired in SVP's profile.

In this scenario it would be preferable to have a "default" configuration that would easily work for normal content while also being able to easily switch to the "just SVP profile" configuration without having to modify the config file.

Of course, the workarounds I mentioned could be applied as well but they're either impractically tedious or brittle (or both).

kkkrackpot commented 7 years ago

@ekce

In this scenario it would be preferable to have a "default" configuration that would easily work for normal content while also being able to easily switch to the "just SVP profile" configuration without having to modify the config file.

Then why not to make an [SVP] profile, to put there the options SVP wants, and to start mpv with --profile="SVP" when needed? The undesired options from "default" profile can be "negated" (or rather, "set to desired values" overriding the "default" ones) in "SVP" profile. That's how it works now afaik, and personally I don't see why it should work some other way.

Sorry, personally I don't know what SVP is and what exactly it wants, and I can't tell anything about how it all should be in mpv in theory. If it's not a real-world problem (with logs, examples, etc.), I can't say anything here.

PS. And with --config-dir it's possible to have several completely different configurations (afaik, not only different config files, but also scripts, shaders, etc.).

haasn commented 7 years ago

I've personally been thinking about a "hierarchical config" system where each profile defines its own config object - in addition to the built-in defaults, global options, command line settings, and "runtime changes".

Toggling a profile on or off would simply enable or disable it. To get the final, computed options - mpv would "cascade" these config objects, with higher-priority sources overriding lower-priority sources. Disabled profiles would simply get skipped.

That way, you could toggle profiles on or off and have mpv "recompute" the config based on that.

ekce commented 7 years ago

SVP is a program that implements motion interpolation and black bar lighting. It relies heavily on the graphics card and is fed into mpv via an IPC pipe (i.e. input-ipc-server). Thus one may not want to use normal mpv options that also make heavy use of the video card and implement smoothmotion.

You are correct in that one could add a lot of extra options to the SVP profile to undo everything in the default profile (eg. the third workaround I mentioned) but doing so is brittle and requires updating the SVP profile each time the default profile is updated.

My issue is twofold. On the personal side of things I feel like the current solutions are tedious and feel like obvious workarounds for a feature that should exist. On a less personal note I've been updating the Arch wiki since it had a lot of bad/outdated information and is used by a lot of users (still needs a lot of work) and once I realized that adding profiles via cli did not work how I expected it to I was faced with two options:

  1. I could make a git issue asking for the desired behavior.
  2. I could rewrite several sections either removing profiles altogether or giving a really convoluted explanation on how (not) to use them, essentially making them not very practical.

You can read a bit more about SVP on my work in progress updates to the mpv Arch Wiki page (note the profile section will probably be rewritten because as it currently is it is wrong). https://wiki.archlinux.org/index.php/mpv#SVP_4_Linux_.28SmoothVideoProject.29

ekce commented 7 years ago

I didn't notice Haasn's post until now for some reason. That suggestion sounds both really cool and really powerful. If you deem it practical to implement then I'm all for it (I understand if you don't since it sounds like a lot of work and it may make users update their config).

PS. And with --config-dir it's possible to have several completely different configurations (afaik, not only different config files, but also scripts, shaders, etc.).

I hadn't looked into config-dirs because I thought extra configs would also just get appended to the current one (like adding options at the command line). This may be a reasonable and viable solution.

ghost commented 7 years ago

It's most likely impractical to implement.

ekce commented 7 years ago

After looking at the documentation some more I'm not entirely sure how the config file/directory stuff works. Is the following correct?

basics

mpv will check the following directories for configuration files (in this order) until it finds some at which point it will load said files and stop looking.

include

If --include is passed to mpv (either in an mpv.conf or via command line) then the entire mpv.conf configuration file will be appended to the END of the current one. In other words given two files mpv.conf

include=./mpv-extra.conf
fs=yes

mpv-extra.conf

[test]

mpv won't parse it as

[test]
fs=yes

but rather

fs=yes
[test]

Moreover, --include only applies to mpv.conf files and not other types of configuration files.

config-dir

Using config-dir will load all configuration files from said directory. So a user would want to place copies of input.conf, lua-settings/, and other configuration files in said directory if only wanting to change mpv.conf.

input-conf

input-conf will over-ride the directory of the input.conf file. How is this affected by config-dir and no-config? Would it be possible to add a command-line only version of this option for mpv.conf, i.e. mpv-conf?

use-filedir-conf

use-filedir-conf enables the use of file specific configuration files (but only for mpv.conf, not other sorts of config files) but there is currently no way for said config file to apply to more than one file in said directory (either via prefix or making it folder-wide)?