summaryrefslogtreecommitdiffstats
path: root/options/options.c
Commit message (Collapse)AuthorAgeFilesLines
* x11: add --x11-present optionDudemanguy2022-06-221-0/+3
| | | | | | | | | | | With the recent addition of the libxpresent, it should improve frame timings for most users. However, there were known cases of bad behavior (Nvidia) which lead to a construction of a whitelist instead of just enabling this all the time. Since there's no way to predict whatever combination of hardware/drivers/etc. may work correctly, just give users an option to switch the usage of xorg's presentation statistics on/off. The default value, auto, works like before (basically, Mesa drivers and no Nvidia are allowed), but now one can force it on/off if needed.
* options: make --cover-art-auto=exact the defaultGuido Cella2022-04-211-1/+1
| | | | | | | | | Now that a separate --cover-art-whitelist option exists, files like cover.jpg are loaded even without setting --cover-art-auto to fuzzy, so only load files that have exactly the media filename by default, since fuzzy loading is probably more likely to load unwanted images than to load cover art that the user intended to display, especially if you play audio files with a short filename like a.mp3.
* player: add cover-art-whitelist optionGuido Cella2022-04-211-0/+2
| | | | | | | | This allows more fine grained control over which cover art to load. With --cover-art-auto=exact and --cover-art-whitelist=yes, you can now load cover art with the exact media filename and the whitelisted filenames, but not cover art that contains the media filename (--cover-art-auto=fuzzy).
* player: rearrange video sync opts/enums/definesDudemanguy2022-04-111-9/+9
| | | | | | | | | | | | | | | | | The video sync logic for mpv lies completely within its core at essentially the highest layer of abstraction. The problem with this is that it is impossible for VOs to know what video sync mode mpv is currently using since it has no access to the opts. Because different video sync modes completely changes how mpv's render loop operates, it's reasonable that a VO may want to change how it renders based on the current mode (see the next commit for an example). Let's just move the video sync option to mp_vo_opts. MPContext, of course, can still access the value of the option so it only requires minor changes in player/video.c. Additionally, move the VS_IS_DISP define from to player/core.h to common/common.h. All VOs already have access to common/common.h, and there's no need for them to gain access to everything that's in player/core.h.
* options: add osd-playing-msg-durationGuido Cella2022-04-071-0/+2
|
* options: add always to stop-screensaverDudemanguy2022-02-181-1/+5
| | | | | | | | | | The stop-screensaver option is currently limited to a simple yes/no option. While the no option does always disable mpv trying to stop the screensaver, yes does not mean the screensaver is always stopped. The screensaver will be enabled again depending on certain conditions (like if the player is paused). Simply introduce a new value for this option, always, which does exactly what the name implies: the screensaver will always be disabled.
* Revert "options: add --sub-visibility=<primary-only|secondary-only>"Avi Halachmi (:avih)2022-01-191-5/+3
| | | | | | | | | | This reverts commit 04f0b0abe48d664aaa1400d1dddb02b434999b85. It's not a good idea to unify the names only for visibility, while keeping secondary-* for everything else. This needs a bit more thought before we allow secondary sub to be visible on its own.
* options: add --sub-visibility=<primary-only|secondary-only>Ripose2022-01-191-3/+5
| | | | | | | | | | | | | Adds --sub-visibility choices 'primary-only' for only displaying the primary subtitle track, and 'secondary-only' for only displaying secondary subtitle track. Removes --secondary-sub-visibility and displays a message telling the user to use --sub-visibility=yes/primary-only instead. These changes make it so that the default 'sub-visibility' bind 'v' cycles through all the 'sub-visibility' choices, 'no', 'yes', 'primary-only', and 'secondary-only'.
* vo_gpu: lift ra_ctx_* opts to a global structNiklas Haas2021-11-031-0/+2
| | | | So I can re-use them for vo_gpu_next.
* sub: sub-filter-regex and jsre: support ass-to-plaintextAvi Halachmi (:avih)2021-08-051-0/+1
| | | | | | | | | | | Using --sub-filter-regex-plain (default:no) The ass-to-plaintext functionality already existed at sd_ass.c, but it's internal and uses a private buffer type, so a trivial utility wrapper was added with standard char*/bstr interface. The plaintext can be multi-line, and the multi-line regexp flag is now always set, but only affects plaintext (the ASS source is one line).
* sub: new: --sub-filter-jsre (js regex)Avi Halachmi (:avih)2021-08-051-0/+1
| | | | | | | | | | | | Pretty much identical to filter-regex but with JS expressions and requires only JS support. Shares the filter-regex-* control options. The target audience is Windows users - where filter-regex doesn't work due to missing APIs, but mujs builds cleanly on Windows, and JS is usually enabled in 3rd party Windows mpv builds. Lua could have been used with similar effort, however, the JS regex syntax is more extensive and also much more similar to POSIX.
* options: audio-display determines cover priorityGuido Cella2021-07-291-1/+2
| | | | | | | | | | | | Let audio-display determine whether embedded images or external cover art tracks should be selected when both are present. Attached pictures are given priority by default as requested in #8539. Also updates references to attached pictures in the log and manpage to refer to cover art as well. Closes #8539.
* options: add watch-later-optionsGuido Cella2021-07-211-0/+39
| | | | | | | | | | This allows configuring which options are saved by quit-watch-later. Fixes #4126, #4641 and #5567. Toggling a video or audio filter twice would treat the option as changed because the backup value is NULL, and the current value of vf/af is a list with one empty item, so obj_settings_list_equal had to be changed.
* wayland: handle app id option less stupidlyDudemanguy2021-06-261-0/+1
| | | | | | Not sure what I was on when I wrote this. wayland-app-id is supposed to default to "mpv". Just set that in the vo_sub_opts and don't do this weird m_config_cache_write_opt thing. Also make the doc entry nicer.
* sub: by default, don't render timestamps after video EOFrcombs2021-06-231-0/+1
| | | | | | | | | This fixes a long-standing apparent issue where mpv would display the last frame with no subtitles at EOF. This is caused by sub rendering switching from video timestamps to audio timestamps when the video ends, and audio streams often running past the timestamp of the last video frame. However, authoring tools (most notably Aegisub) don't tend to provide easy ways to add meaningful subtitles after the end of the video, so this is rarely actually useful.
* player: change cover-art-auto behaviorGuido Cella2021-06-231-1/+1
| | | | | | | | | | | | | | This makes cover-art-auto behave more like sub-auto and audio-file-auto: - load cover art with a language, e.g. if playing foo.mp3, foo.en.jpg will be loaded with lang=en - load cover art containing the media filename with fuzzy and all, e.g. 'foo (large).jpg' - make all/2 load all images in the directory, and make fuzzy/1 the default These are all uncommon use cases, but synchronizing the behavior of the external file options simplifies the code.
* vo_gpu: vulkan: implement a VkDisplayKHR backed contextPhilip Langdale2021-06-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This is the Vulkan equivalent of the drm context for OpenGL, with the big difference that it's implemented purely in terms of Vulkan calls and doesn't actually require drm or kms. The basic idea is to identify a display, mode, and plane on a device, and then create a display backed surface for the swapchain. In theory, past that point, everything is the same, and this is in fact the case on Intel hardware. I can get a video playing on a vt. On nvidia, naturally, things don't work that way. Instead, nvidia only implemented the extension for scenarios where a VR application is stealing a display from a running window system, and not for standalone scenarios. With additional code, I've got this scenario to work but that's a separate incremental change. Other people have tested on AMD, and report roughly the same behaviour as on Intel. Note, that in this change, the VT will not be correctly restored after qutting. The only way to restore the VT is to introduce some drm specific code which I will illustrate in a separate change.
* player: load cover art with the media filenameGuido Cella2021-05-271-2/+2
| | | | Closes #8666.
* sub/osd: hide secondary subtitles if secondary-sub-visibility is falseZsolt Vadasz2021-05-191-0/+2
|
* options: add some entries to --display-tags defaultsYour Name2021-05-111-0/+1
| | | | Useful for the previous commit.
* options: extend --replaygain-preamp rangeYour Name2021-05-071-1/+1
| | | | Whether that makes sense or not.
* options: win32: ignore and deprecate --fit-borderAvi Halachmi (:avih)2021-04-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The accurate description of this option was: - fit-border is enabled by default. When disabled, it adds a bug where if the window has borders and mpv shrinks it to fit the desktop, then the calculation ignores the borders and adds incorrect video crop. The option was added at commits 70f64f3c and 949247d6, in order to solve an issue (#2935) where if mpv wanted to display a video with size WxH, then w32_common.c incorrectly set the window to WxH, while down-scaling the video slightly to fit (even with small sizes). It was addressed with a new option which is enabled by default, but does the right thing (sets the client area to WxH) only when disabled, so that everyone who prefers their video slightly downscaled could keep their default behavior. (#2935 also addressed an off-by-one issue, fixed before fit-border) While disabling the option did avoid unnecessary downscaling, it also added a bug when disabled: the borders are no longer taken into account when the size is too big for the desktop. Most users don't notice and are unaffected as it's enabled by default. Shortly later (981048e0) the core issue is fixed, and now the client area is correctly set to WxH instead of the window (and together with the three following commits which center the video, adds a new bug where the window title can be outside the display - addressed next). However, fit-border remained, now without any effect, except that it still has the same bug when disabled and the window is too big. Later code changes and refactoring preserved this issue with great attention to details, and it remained in identical form until now. Simply rip out fit-border.
* demux: Move demuxer help to new standard mechanismPhilip Langdale2021-03-281-3/+4
| | | | | Previously, demux help was handled as a special case in main.c and this is no longer necessary.
* player: add --screen-name and --fs-screen-nameDudemanguy2020-12-061-0/+2
| | | | | | Simple groundwork for adding a couple of user options that allow selecting the screen with a string name. The next two commits implements these options for xorg and wayland.
* Revert "options: disable vsfilter blur compat by default"rcombs2020-11-221-1/+1
| | | | | | | | | | | | | | | This reverts commit 3d17e19c2c5ca80f916411e7e61126cac8443baa. The effect of turning off this setting is that mpv doesn't tell libass what the video stream's resolution is. This happens to result in some files having their transforms scaled in ways that give higher performance (as described in #7435) because libass happened to guess a video resolution that resulted in transforms yielding smaller bitmaps, but it's just as easy for the opposite to happen depending on the resolutions and effects involved. The option's name is also somewhat misleading: setting the storage size affects blur, but it also affects stroke (which is far more important for the vast majority of scripts) and 3D transforms (which look very screwy when done wrong).
* screenshot: add --screenshot-sw optionwm42020-10-051-0/+1
| | | | | Probably worthless. As usual, the manpage dumps all the subtle differences due to implementation details on the user.
* options: fix --cover-art-file typoGuido Cella2020-09-301-1/+1
| | | | ...which makes it not work.
* player: add automatic loading of external cover art fileswm42020-09-281-2/+10
| | | | | | | | | | | | | | | | | | | | | | | Picks up files like "cover.jpg". It's made part of normal external file loading, so I'm adding 3 new options that are direct equivalents for the options that control loading of external subtitle and audio files. Even though I bet nobody wants them and they just increase confusion... I guess the world is actually hell, so this outcome should be fine. It prefers non-specific external files like "cover.jpg" over embedded cover art. Not sure if that's wanted or unwanted. There's some pain over explicitly marking such files as external pictures. This is basically an optimization: in most cases, a heuristic would treat an image file loaded with --external-file the same (it's a heuristic because ffmpeg can't tell us whether something is an image or a video). However, even with this heuristic, it would decode the cover art picture again on each seek, which would essentially slow down seeking in audio files. This bothered me greatly, which is why I'm adding these additional options at all, and bothered with the previous commit. Fixes: #3056
* mac: add an option to prevent focusing of the window on opender richter2020-09-251-0/+2
| | | | | | | | | on macOS 10.15 setting the activation policy behaves quite weirdly. the call changes the current active App to a nameless process, which probably also the reason that prevents the not focusing to work. a workaround for that, is to refocus the previous active app. Fixes #7725
* mac: add ontop window level for desktopder richter2020-09-201-2/+2
| | | | | | this puts the window ontop of the desktop but behind the desktop icons. Fixes #7791
* options: simplify --android-surface-size handlingsfan52020-09-201-5/+3
|
* options: fix a flags fieldwm42020-09-041-2/+2
|
* player: add --subs-with-matching-audio optionrcombs2020-08-191-1/+5
| | | | | | | | | This allows users to control whether full dialogue subtitles are displayed with an audio track already in their preferred subtitle language. Additionally, this improves handling for the forced flag, automatically selecting between forced and unforced subtitle streams based on the user's settings and the selected audio.
* wayland: expose wayland-app-id as a user optionDudemanguy2020-08-141-0/+1
| | | | | This is extremely similar to x11's WM_CLASS. This commit allows users to set mpv's app-id at runtime for any of the wayland backends.
* sub: extend range of --sub-pos optionwm42020-08-121-1/+1
| | | | | | | | | | | | Seems like this is requested all the time. It seems libass allows out of range values, but does allows the subtitle to go out of the screen at the bottom (only when moving it to the top it's "clamped"). Too bad, don't do that then. The bitmap sub rendering code on the other hand is under our control, and will not move a subtitle out of the screen. Fixes: #7986
* sd_ass: force full reinit if certain options change at runtimewm42020-08-121-4/+6
| | | | | | | | | | Options like --sub-ass-force-style and others could not be changed at runtime (the changes didn't take any effect). Fix this by using the brutal approach, and completely reinit the subtitle state when this happens. Maybe a bit clunky, but for now I'd rather not put more effort into this. Fixes: #7689
* auto_profiles: add this scriptwm42020-08-051-0/+4
| | | | | | | | | | | | | | | | | | | | | This is taken from a somewhat older proof-of-concept script. The basic idea, and most of the implementation, is still the same. The way the profiles are actually defined changed. I still feel bad about this being a Lua script, and running user expressions as Lua code in a vaguely defined environment, but I guess as far as balance of effort/maintenance/results goes, this is fine. It's a bit bloated (the Lua scripting state is at least 150KB or so in total), so in order to enable this by default, I decided it should unload itself by default if no auto-profiles are used. (And currently, it does not actually rescan the profile list if a new config file is loaded some time later, so the script would do nothing anyway if no auto profiles were defined.) This still requires defining inverse profiles for "unapplying" a profile. Also this is still somewhat racy. Both will probably be alleviated to some degree in the future.
* options: add --video-scale-x/ywm42020-06-031-0/+4
| | | | | | Requested. Fixes: #6303
* player: add --term-title optionwm42020-05-251-0/+1
| | | | | | | | | | | | | | This simply printf()s a concatenation of the provided string and the relevant escape sequences. No idea what exactly defines this escape sequence (is it just a xterm thing that is now supported relatively widely?), and this simply uses information provided on the linked github issue. Not much of an advantage over --term-status-msg, though at least this can have a lower update frequency. Also I may consider setting a default value, and then it shouldn't conflict with the status message. Fixes: #1725
* player: remove some display-adrop leftoverswm42020-05-231-3/+0
| | | | | Forgotten in one of the previous commits. Also undeprecates display-adrop since it's out of sight now.
* options: add option to control display-sync factorwm42020-05-231-0/+2
| | | | | | | | Can be useful to force it to adapt to extreme speed changes, while a higher limit would just use a fraction closer to the original video speed. Probably useful for testing only.
* options: update OSD when writing some OSD-related optionswm42020-05-091-9/+9
| | | | | | Just the usual change notification mess. Fixes: #7697
* options: don't trigger bool "compact" path for --loop-filewm42020-05-061-2/+2
| | | | | | | In theory an incompatible change, but I think it's for the better. Impact should be relatively low. I hope. Fixes: #7676
* player: slightly improve use of secondary track selection limitswm42020-04-151-0/+1
| | | | | | Apparently, this was a bit of a mess, which caused the bug fixed by commit ec7f2388af2df. Try to improve this, and only use track selection entries that exist.
* options: fix ab-loop-* propertieswm42020-04-091-2/+2
| | | | | | | | | | | These used ".min = MP_NOPTS_VALUE" to indicate certain exceptions. This broke with the recent change to how min/max are handled, which made setting min or max mean that a value range is used, thus setting max=0. Fix this by not using magic a value in .min; replace it with a proper flag. Fixes: #7596
* ipc: add --input-ipc-client optionwm42020-04-091-0/+3
| | | | | | | | | While --input-file was removed for justified reasons, wanting to pass down socket FDs this way is legitimate, useful, and easy to implement. One odd thing is that Fixes: #7592
* input: remove deprecated --input-file optionwm42020-03-281-2/+0
| | | | | This was deprecated 2 releases ago. The deprecation changelog entry says that there are no plans to remove it short-term, but I guess I lied.
* options: change option macros and all option declarationswm42020-03-181-539/+552
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* options: introduce bool option type, use it for --fullscreenwm42020-03-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The option code is very old and was added to MPlayer in the early 2000s, when C99 was still new. MPlayer did not use the "bool" type anywhere,l and the logical option equivalent to bool, the "flag" option type, used int, with the convention that only the values 0 and 1 are allowed. mpv may have hammered many, many additional tentacles to the option code, but some of the basics never changed, and m_option_type_flag still uses int. This seems a bit weird, since mpv uses bool for booleans. So finally introduce an m_option_type_bool. To avoid duplicating too much code, change the flag code to bool, and "reimplement" m_option_type_flag on top of m_option_type_bool. As a "demonstration", change the --fullscreen option to this new type. Ideally, all options would be changed too bool, and m_option_type_flag would be removed. But that is a lot of monotonous thankless work, so I'm not doing it, and making it a painful years long transition. At the same time, I'm introducing a new concept for option declarations. Instead of OPT_BOOL(), which define the full m_option struct contents, there's OPTF_BOOL(), which only takes the option field name itself. The name is provided via a normal struct field initializer. Other fields (such as flags) can be provided via designated initializers. The advantage of this is that we don't need tons of nested vararg macros. We also don't need to deal with 0-sized varargs being a pain (and in fact they are not a thing in standard C99 and probably C11). There is no need to provide a mandatory flags argument either, which is the reason why so many OPT_ macros are used with a "0" argument. (The flag argument seems to confuse other developers; they either don't immediately recognize what it is, and sometimes it's supposed to be the option's default value.) Not having to mess with the flag argument in such option macros is also a reason for the removal of M_OPT_RANGE etc., for the better or worse. The only place that special-cased the _flag option type was in command.c; change it to use something effectively very similar that automatically includes the new _bool option type. Everything else should be transparent to the change. The fullscreen option change should be transparent too, as C99 bool is basically an integer type that is clamped to 0/1 (except in Swift, Swift sucks).
* options: change how option range min/max is handledwm42020-03-131-12/+14
| | | | | | | | | |