Configuration files
Location and Syntax¶
You can put all of the options in configuration files which will be read
every time mpv is run. The system-wide configuration file 'mpv.conf' is
in your configuration directory (e.g. /etc/mpv or
/usr/local/etc/mpv), the user-specific one is
~/.config/mpv/mpv.conf. For details and platform specifics (in
particular Windows paths) see the FILES section.
User-specific options override system-wide options and options given on
the command line override both. The syntax of the configuration files is
option=value. Everything after a # is considered a comment. Options
that work without values can be enabled by setting them to yes and
disabled by setting them to no, and if the value is omitted, yes is
implied. Even suboptions can be specified in this way.
Example configuration file
# Don't allow new windows to be larger than the screen.
autofit-larger=100%x100%
# Enable hardware decoding if available, =yes is implied.
hwdec
# Spaces don't have to be escaped.
osd-playing-msg=File: ${filename}
Escaping special characters¶
This is done like with command line options. A config entry can be
quoted with ", ', as well as with the fixed-length syntax (%n%)
mentioned before. This is like passing the exact contents of the quoted
string as a command line option. C-style escapes are currently
not_ interpreted on this level, although some
options do this manually (this is a mess and should probably be changed
at some point). The shell is not involved here, so option values only
need to be quoted to escape # anywhere in the value, ", ' or %
at the beginning of the value, and leading and trailing whitespace.
Putting Command Line Options into the Configuration File¶
Almost all command line options can be put into the configuration file. Here is a small guide:
| Option | Configuration file entry |
|---|---|
--flag |
flag |
-opt val |
opt=val |
--opt=val |
opt=val |
-opt "has spaces" |
opt=has spaces |
File-specific Configuration Files¶
You can also write file-specific configuration files. If you wish to
have a configuration file for a file called 'video.avi', create a file
named 'video.avi.conf' with the file-specific options in it and put it
in ~/.config/mpv/. You can also put the configuration file in the same
directory as the file to be played. Both require you to set the
--use-filedir-conf option (either on the command line or in your
global config file). If a file-specific configuration file is found in
the same directory, no file-specific configuration is loaded from
~/.config/mpv. In addition, the --use-filedir-conf option enables
directory-specific configuration files. For this, mpv first tries to
load a mpv.conf from the same directory as the file played and then
tries to load any file-specific configuration.
Profiles¶
To ease working with different configurations, profiles can be defined
in the configuration files. A profile starts with its name in square
brackets, e.g. [my-profile]. All following options will be part of the
profile. A description (shown by --profile=help) can be defined with
the profile-desc option. To end the profile, start another one or use
the profile name default to continue with normal options.
You can list profiles with --profile=help, and show the contents of a
profile with --show-profile=<name> (replace <name> with the profile
name). You can apply profiles on start with the --profile=<name>
option, or at runtime with the apply-profile <name> command.
Example mpv config file with profiles
# normal top-level option
fullscreen=yes
# a profile that can be enabled with --profile=big-cache
[big-cache]
cache=yes
demuxer-max-bytes=512MiB
demuxer-readahead-secs=20
[network]
profile-desc="profile for content over network"
force-window=immediate
# you can also include other profiles
profile=big-cache
[reduce-judder]
video-sync=display-resample
interpolation=yes
# using a profile again extends it
[network]
demuxer-max-back-bytes=512MiB
# reference a builtin profile
profile=fast
Runtime profiles¶
Profiles can be set at runtime with apply-profile command. Since this
operation is "destructive" (every item in a profile is simply set as an
option, overwriting the previous value), you can't just enable and
disable profiles again.
As a partial remedy, there is a way to make profiles save old option
values before overwriting them with the profile values, and then
restoring the old values at a later point using
apply-profile <profile-name> restore.
This can be enabled with the profile-restore option, which takes one
of the following options:
defaultDoes nothing, and nothing can be restored (default).
copyWhen applying a profile, copy the old values of all profile options to a backup before setting them from the profile. These options are reset to their old values using the backup when restoring.
Every profile has its own list of backed up values. If the backup already exists (e.g. if
apply-profile namewas called more than once in a row), the existing backup is no changed. The restore operation will remove the backup.It's important to know that restoring does not "undo" setting an option, but simply copies the old option value. Consider for example
vf-add, appends an entry tovf. This mechanism will simply copy the entirevflist, and does not_ execute the inverse ofvf-add(that would bevf-remove) on restoring.Note that if a profile contains recursive profiles (via the
profileoption), the options in these recursive profiles are treated as if they were part of this profile. The referenced profile's backup list is not used when creating or using the backup. Restoring a profile does not restore referenced profiles, only the options of referenced profiles (as if they were part of the main profile).copy-equalSimilar to
copy, but restore an option only if it has the same value as the value effectively set by the profile. This tries to deal with the situation when the user does not want the option to be reset after interactively changing it.
Example
[something]
profile-restore=copy-equal
vf-add=rotate=PI/2 # rotate by 90 degrees
Then running these commands will result in behavior as commented:
set vf vflip
apply-profile something
vf add hflip
apply-profile something
# vf == vflip,rotate=PI/2,hflip,rotate=PI/2
apply-profile something restore
# vf == vflip
Conditional auto profiles¶
Profiles which have the profile-cond option set are applied
automatically if the associated condition matches (unless auto profiles
are disabled). The option takes a string, which is interpreted as Lua
expression. If the expression evaluates as truthy, the profile is
applied. If the expression errors or evaluates as falsy, the profile is
not applied. This Lua code execution is not sandboxed.
Any variables in condition expressions can reference properties. If an
identifier is not already defined by Lua or mpv, it is interpreted as
property. For example, pause would return the current pause status.
You cannot reference properties with - this way since that would
denote a subtraction, but if the variable name contains any _
characters, they are turned into -. For example, playback_time would
return the property playback-time.
A more robust way to access properties is using p.property_name or
get("property-name", default_value). The automatic variable to
property magic will break if a new identifier with the same name is
introduced (for example, if a function named pause() were added,
pause would return a function value instead of the value of the
pause property).
Note that if a property is not available, it will return nil, which
can cause errors if used in expressions. These are logged in verbose
mode, and the expression is considered to be false.
Whenever a property referenced by a profile condition changes, the condition is re-evaluated. If the return value of the condition changes from falsy or error to truthy, the profile is applied.
This mechanism tries to "unapply" profiles once the condition changes
from truthy to falsy or error. If you want to use this, you need to set
profile-restore for the profile. Another possibility it to create
another profile with an inverse condition to undo the other profile.
Recursive profiles can be used. But it is discouraged to reference other conditional profiles in a conditional profile, since this can lead to tricky and unintuitive behavior.
Example
Make only HD video look funny:
[something]
profile-desc=HD video sucks
profile-cond=width >= 1280
hue=-50
Make only videos containing "youtube" or "youtu.be" in their path brighter:
[youtube]
profile-cond=path:find('youtu%.?be')
gamma=20
If you want the profile to be reverted if the condition goes to false
again, you can set profile-restore:
[something]
profile-desc=Mess up video when entering fullscreen
profile-cond=fullscreen
profile-restore=copy
vf-add=rotate=PI/2 # rotate by 90 degrees
This appends the rotate filter to the video filter chain when entering
fullscreen. When leaving fullscreen, the vf option is set to the value
it had before entering fullscreen. Note that this would also remove any
other filters that were added during fullscreen mode by the user.
Avoiding this is trickier, and could for example be solved by adding a
second profile with an inverse condition and operation:
[something]
profile-cond=fullscreen
vf-add=@rot:rotate=PI/2
[something-inv]
profile-cond=not fullscreen
vf-remove=@rot
Warning
Every time an involved property changes, the condition is evaluated
again. If your condition uses p.playback_time for example, the
condition is re-evaluated approximately on every video frame. This is
probably slow.
This feature is managed by an internal Lua script. Conditions are executed as Lua code within this script. Its environment contains at least the following things:
(function environment table)-
Every Lua function has an environment table. This is used for identifier access. There is no named Lua symbol for it; it is implicit.
The environment does "magic" accesses to mpv properties. If an identifier is not already defined in
_G, it retrieves the mpv property of the same name. Any occurrences of_in the name are replaced with-before reading the property. The returned value is as retrieved bymp.get_property_native(name). Internally, a cache of property values, updated by observing the property is used instead, so properties that are not observable will be stuck at the initial value forever.If you want to access properties, that actually contain
_in the name, useget()(which does not perform transliteration).Internally, the environment table has a
__indexmeta method set, which performs the access logic. p-
A "magic" table similar to the environment table. Unlike the latter, this does not prefer accessing variables defined in
_G- it always accesses properties. get(name [, def])-
Read a property and return its value. If the property value is
nil(e.g. if the property does not exist),defis returned.This is superficially similar to
mp.get_property_native(name). An important difference is that this accesses the property cache, and enables the change detection logic (which is essential to the dynamic runtime behavior of auto profiles). Also, it does not return an error value as second return value.The "magic" tables mentioned above use this function as backend. It does not perform the
_transliteration.
In addition, the same environment as in a blank mpv Lua script is
present. For example, math is defined and gives access to the Lua
standard math library.
Warning
This feature is subject to change indefinitely. You might be forced to adjust your profiles on mpv updates.
Legacy auto profiles¶
Some profiles are loaded automatically using a legacy mechanism. The following example demonstrates this:
Auto profile loading
[extension.mkv]
profile-desc="profile for .mkv files"
vf=vflip
The profile name follows the schema type.name, where type can be
protocol for the input/output protocol in use (see
--list-protocols), and extension for the extension of the path of
the currently played file (not the file format).
This feature is very limited, and is considered soft-deprecated. Use conditional auto profiles.