summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: allow --hdr-peak-decay-rate=0.0Niklas Haas2023-08-181-2/+2
| | | | | | | | | | | | | | This completely disables all smoothing. Despite what the manual claims, a decay rate of 1.0 does *not*. It's worth pointing out that this depends on the following commit to work properly in --vo=gpu-next, but I don't think working around such a minor detail is worth the trouble, considering people building nightly mpv are probably also building nightly libplacebo it should just work (tm). See-Also: https://github.com/haasn/libplacebo/commit/1c464baaf4c6228dcfac87f19db1dafc22e328c8 See-Also: https://github.com/haasn/libplacebo/commit/83af2d4ebd5086a56f7b1a2f86628ada3612ee7c
* x11: add --x11-wid-title optionDudemanguy2023-08-132-0/+5
| | | | | | | | | | This deliberately wasn't being done when mpv was embedded (fbccddb48b4c71c18300b092ef7a3860be2a659a). There are some applications that would benefit from mpv setting a title since they don't do so themselves (such as tabbed), but at the same time some others would probably rather not have this behavior (like smplayer). Add an option that allows an embedded mpv to set the title if the user wishes. Fixes #11528.
* player: add playlist-path propertiesDudemanguy2023-08-132-0/+11
| | | | | | | | | | | | A bit of a long standing pain with scripting is that when opening a file that gets interpreted as a playlist (like an m3u), the original path of the file gets thrown away later. Workarounds basically consist of getting the filename before mpv expands the path, but that's not really reliable. Instead of throwing it away, save the original playlist path by copying to the playlist entries when applicable (demuxer playlist and the playlist option). Then expose these as properties: playlist-path for the currently playing entry and playlist/N/playlist-path for each specific entry. Closes #8508, #7605.
* vf_vapoursynth: save display resolution as a variableDudemanguy2023-08-131-0/+6
| | | | | | | | | | | | | | mpv has a generic method for getting the display resolution, so we can save it in vf_vapoursynth without too much trouble. Unfortunately, the resolution won't actually be available in many cases (like my own) because the windowing backend doesn't actually know it yet. It looks like at least windows always returns the default monitor (maybe we should do something similar for x11 and wayland), so there's at least some value. Of course, this still has a bunch of pitfalls like not being able to cope with multi monitor setups at all but so does display_fps. As an aside, the vapoursynth API this uses apparently requires R26 (an ancient version anyway), so bump the build to compensate for this. Fixes #11510
* player: add --term-remaining-playtime optionDudemanguy2023-08-132-0/+6
| | | | | | | The OSC reports the speed-adjusted remaining time, but the terminal does not. This is a weird mismatch and the OSC's default behavior makes sense, so let's just do some division and add an option to disable it. Also named "remaining-playtime" after the OSC option. Fixes #10445.
* player: make sub-pos a float valueDudemanguy2023-08-131-0/+1
| | | | | | | | mpv makes this option an integer, but the underlying ass API actually accepts doubles. From some testing, there is no meaningful precision difference between float or double (it seems to go in roughly 0.05 steps), so just make it a float. sd_lavc also can handle non-integer values here. Closes #11583.
* player/command: add video-params/aspect-nameKacper Michajłow2023-08-132-0/+5
| | | | With pretty printed aspect ratio and related format.
* ytdl_hook: improve Windows exe search with suffixfireattack2023-08-131-1/+1
|
* osc: support speed-independent time-remaiing displayDave2023-08-111-0/+7
| | | | | The new OSC config option "remaining_playtime" controls whether the time-remaining display considers speed (yes - default) or ignores it.
* ao_audiotrack: enable pcm-float by defaultsfan52023-08-081-0/+1
| | | | Since recent commits this should work 100% as well as s16.
* DOCS/options: fix typo in hdr-peak-percentileAlexander Georgiadis2023-08-051-1/+1
|
* builtin.conf: add --hdr-peak-percentile=99.995 to gpu-hqNiklas Haas2023-08-041-0/+1
| | | | | | This is higher quality but comes with a slight performance hit, especially for weaker iGPUs, so I don't want to enable it out of the box even when --hdr-compute-peak=auto.
* vo_gpu_next: add --hdr-peak-percentileNiklas Haas2023-08-042-0/+10
|
* options: restore old default sub selection behaviorDudemanguy2023-07-292-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 1669c4698d237eb885aa3f9c5b81983de6009418 notably flipped the default of --subs-with-matching-audio from yes to no as part of a series of changes that gave more control over sub selection behavior. While the increased amount of options is definitely nice, changing the default to no results in very unintuitive behavior. For example, setting alang=en and slang=en in your config will not show any subtitles since the audio stream is English as well so --subs-with-matching-audio being no causes the subs to not be be selected. This is very weird for users who reasonably expect slang being set to actually result in showing subs and this is what mpv did for the past decade. The other case is when a subtitle does not have a language tag but is flagged as default. Because --subs-fallback (a new option), defaults to no, these subtitles also will not be loaded. This is also strange for users since mpv previously loaded these and they would need to change the value of this option. It's also inconsistent because audio tracks that are tagged as default are also loaded by default. The new behavior seems to have mostly just confused users, and it also regresses their configs for unclear reasons. Let's just set the options to be back in line with the old behavior with is what most users expect. --subs-with-matching-audio goes back to being yes and the new option --subs-fallback should be default. Fixes #11854.
* path-win: move state directory to %LOCALAPPDATA%Kacper Michajłow2023-07-292-0/+5
| | | | %LOCALAPPDATA% is where the local application state belongs.
* path-win: add subdirectory for cacheKacper Michajłow2023-07-291-1/+1
| | | | To not polute %LOCALAPPDATA%/mpv as it may be used for other things too.
* waf: remove waf as a build systemLaserEyess2023-07-232-228/+0
| | | | | | Remove waf entirely in favor of meson as the only supported build system. Waf was officially deprecated in 0.36.0, and has not been preferred over meson since 0.35.0.
* Release 0.36.0v0.36.0release/0.36sfan52023-07-231-1/+2
|
* DOCS/vo: clarify dmabuf-wayland a bitDudemanguy2023-07-231-2/+6
| | | | | | Make it clearer that you should be using --hwdec with this VO. Also make some comments about the things that are required for this to work correctly (i.e. working drivers/GPU and the right compositor).
* DOCS: clarify screenshot window and screenshot-swDudemanguy2023-07-212-6/+6
|
* image_writer: move tag_csp check into image_writer_flexible_csp()sfan52023-07-191-4/+4
| | | | | | | This ensures the sRGB fallback to happen in all situations involving the image writer code, notably --screenshot-sw. fixes: cbbe2e52210d9885a0897e9c7833267a60456c56
* builtin.conf: add --hdr-contrast-recovery to gpu-hqNiklas Haas2023-07-181-0/+1
| | | | The first change to the gpu-hq profile in aeons.
* vo_gpu_next: add --hdr-contrast-recovery/smoothnessNiklas Haas2023-07-182-0/+13
| | | | New upstream feature. Disabled by default.
* vo_gpu_next: add --target-contrast optionKacper Michajłow2023-07-172-0/+10
| | | | For better control over target display levels.
* DOCS/release-policy.md: add additional advicesfan52023-07-171-6/+18
|
* player: set default cache dir on macOSm154k12023-07-151-0/+8
| | | | Use ~/Library/Caches/io.mpv for caches instead of ~~home.
* DOCS/mpv: clarify the location of cache/state filesDudemanguy2023-07-151-7/+31
|
* DOCS/interface-changes: document change in ctrl+h behaviourPhilip Langdale2023-07-151-0/+1
| | | | | We now use `auto-safe` when turning on hardware decoding instead of `auto`.
* vd_lavc: map `hwdec=yes` to `hwdec=auto-safe`Philip Langdale2023-07-141-1/+1
| | | | | | To remain consistent with our belief that `auto-safe` should be the recommended mode when turning on hw decoding, let's remap `yes` from `auto` to `auto-safe`.
* input: update ctrl+h to toggle `auto-safe` rather than `auto`Philip Langdale2023-07-141-2/+2
| | | | | | | | | | | | | It has been odd that ctrl+h toggles `auto` for hwdecs even though we always recommend people start with `auto-safe`, and `auto` will attempt various hwdecs that can fail so badly we can't fall back to software decoding. With the change to more exhaustively attempt to use hwdecs, it is now easier to get into situations where these fragile hwdecs will get attempted in basic scenarios, like pressing ctrl+h. So it is high time to default to `auto-safe`.
* vo_dmabuf_wayland: add osd supportDudemanguy2023-07-121-2/+1
| | | | | | | | | | | | | | | | | | This adds osd support via shm buffers using a similar approach that the normal buffers do, but it differs in a few key areas. One thing to note is that sway and weston actually handle this extremely differently which required all the abstractions here. In particular, weston does not cope well with destroying the wl_buffer from shm outside of the release handler at all (i.e. it segfaults). The workaround here is to simply attach a NULL to the osd surface and do a surface commit before we destroy the buffers. This is reasonable enough and seems to work well although it's pretty weird. Sway is more straightforward although it actually releases the osd buffer when the window goes out of sight. Also, I found that it doesn't always release every buffer before you close it unlike weston seems to do which is part of the reason all this bookkeeping is required. I don't know if there's any other compositor out there that can possibly handle vo_dmabuf_wayland right now, but suffering through these two is good enough for now I think.
* stats.lua: set sans-serif as default fontm154k12023-07-101-9/+2
| | | | sans is deprecated and unsupported on some platforms.
* demux_playlist: add option to control recursive directory loadingChristoph Heinrich2023-07-062-0/+8
| | | | | | | | | | | Directories were always loaded recursively, which can be slow (e.g. one of the subdirectories is a mounting point to a slow device) and can unexpectedly expand into a massive playlist. Due to the problems described in 503dada42f1ea1007768da0dc6a41b67cdf89400, this defaults to recursive loading. ref. https://github.com/mpv-player/mpv/issues/9652
* various: correctly ignore cache files with --no-configDudemanguy2023-07-061-3/+3
| | | | | | | | | | | | --no-config should prevent loading user files of any type: configs, cache, etc. For cache files, this case wasn't properly handled and it was assumed they would always get something. vo_gpu's shader cache actually already handles this, so it was left untouched. In theory, demuxer cache should never have this issue because saving it to disk is disabled by default (and likely that will never change), but go ahead and change it for consistency's sake. Fixes some segfaults with --no-config and various combinations of settings (particularly --vo=gpu-next).
* vo_gpu/vo_gpu_next: enable gpu shader and icc cache by defaultDudemanguy2023-07-042-9/+11
| | | | | | | | | | | 4502522a7aee093c923e79a65e4684ea2634af30 changed the way mpv handled and saved cached files. In particular, it made a separate boolean option for actually enabling cache and left the *-dir options as purely just a path (i.e. having a dir set didn't mean you save cache). This technically regressed people's configs, so let's just turn the cache on by default. Linux users already expect random stuff in ~/.cache and well everyone else can just live with some files possibly appearing in their config directory.
* player: add --input-cursor-passthrough optionDudemanguy2023-07-042-0/+8
| | | | | | | | | | | | | Add an option for allowing pointer events to pass through the mpv window. This could be useful in cases where a user wants to display transparent images/video with mpv and interact with applications beneath the window. This commit implements this functionality for x11 and wayland. Note that whether or not this actually works likely depends on your window manager and/or compositor. E.g. sway ignores pointer events but the entire window becomes draggable when you float it (nothing under the mpv window receives events). Weston behaves as expected however so that is a compositor bug. Excuse the couple of completely unrelated style fixes (both were originally done by me).
* win32: add support for drag-and-drop optionDudemanguy2023-07-011-1/+1
|
* options: add no to drag-and-dropDudemanguy2023-07-011-2/+3
| | | | | Suggested by @sfan5. Naturally, "no" disables all drag and drop behavior.
* video/image_writer: add avif screenshot supportcloud116652023-07-011-0/+28
| | | | | | | | | | Notes: - converts the (image) write() api to filenames, because using avio with FILE* is a pain. - adds more debug logs for screenshots. build: rename av1 dependency to avif_muxer wscript: unify lavf dependency with meson
* vd_lavc: let the user provide a priority list of hwdecs to considerPhilip Langdale2023-06-291-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Today, the only way to make mpv consider multiple hwdecs and pick the first one that works is to use one of the `auto` modes. But the list that is considered in those cases is hard-coded. If the user wants to provide their own list, they are out of luck. And I think that there is now a significant reason to support this - the new Vulkan hwdec is definitely not ready to be in the auto list, but if you want to use it by default, it will not work with many codecs that are normally hardware decodable (only h.264, hevc and av1 if you are very lucky). Everything else will fall back to software decoding. Instead, what you really want to say is: use Vulkan for whatever it supports, and fall back to my old hwdec for everything else. One side-effect of this implementation is that you can freely mix hwdec names and special values like `auto` and `no`. The behaviour will be correct, so I didn't try and prohibit any combinations. However, some combinations will be silly - eg: sticking any further values after `no` will result in them being ignored. On the other hand, a combination like `vulkan,auto` could be very useful as that will use Vulkan if possible, and if not, run the normal auto routine. Fixes #11797
* command: add sub-forced-only-cur proprcombs2023-06-251-0/+3
|
* sub: rewrite auto-forced-only supportrcombs2023-06-251-0/+4
| | | | | - No longer has a fake "option" used only internally (which didn't always get propagated properly) - Always overrideable during playback
* player: add more precise sub fallback optionsrcombs2023-06-251-0/+9
|
* options: default slang to autorcombs2023-06-252-1/+2
|
* loadfile: support "auto" as a language optionrcombs2023-06-251-0/+3
| | | | This uses the user's OS-level preferred set of languages
* loadfile: use mp_match_lang_singlercombs2023-06-251-8/+8
| | | | | This adds basic support for IETF language tags, as well as matching 2-letter language codes against 3-letter ones (and vice versa).
* options: set subs-with-matching-audio to off by defaultrcombs2023-06-252-3/+3
| | | | This means that subtitles won't be displayed unless the user asks for them
* vo_gpu_next: add --corner-rounding optionNiklas Haas2023-06-212-0/+7
| | | | For better or worse.
* vo_gpu_next: add missing --gamut-mapping-mode optionsNiklas Haas2023-06-212-7/+28
| | | | | Adds the missing upstream values that were exposed by the new gamut mapping API.
* DOCS: fix admonition typoLeo Izen2023-06-151-1/+1
| | | | Fix missing second : in DOCS/man/options.rst after a .. admonition::
* player: add drag-and-drop optionDudemanguy2023-06-121-0/+8
| | | | | | | | | | | Some platforms (wayland) apparently have a lot of trouble with drag and drop. The default behavior is still the same which is basically obeying what we get from the window manager/compositor, but the --drag-and-drop option allows forcibly overriding the drag and drop behavior. i.e. you can force it to always replace the playlist or append at the end. This only implements this in X11 and Wayland but in theory windows and macos could find this option useful (both hardcode the shift key for appending). Patches welcome.
* DOCS/mpv: add an example for applying profiles to certain pathsGuido Cella2023-06-071-0/+8
| | | | | | | It is worth adding this example because it has been asked multiple times in the issue tracker and the IRC channel. string.find() is used because it's 20 times faster than string.match().
* hwdec_vulkan: add Vulkan HW InteropPhilip Langdale2023-05-282-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vulkan Video Decoding has finally become a reality, as it's now showing up in shipping drivers, and the ffmpeg support has been merged. With that in mind, this change introduces HW interop support for ffmpeg Vulkan frames. The implementation is functionally complete - it can display frames produced by hardware decoding, and it can work with ffmpeg vulkan filters. There are still various caveats due to gaps and bugs in drivers, so YMMV, as always. Primary testing has been done on Intel, AMD, and nvidia hardware on Linux with basic Windows testing on nvidia. Notable caveats: * Due to driver bugs, video decoding on nvidia does not work right now, unless you use the Vulkan Beta driver. It can be worked around, but requires ffmpeg changes that are not considered acceptable to merge. * Even if those work-arounds are applied, Vulkan filters will not work on video that was decoded by Vulkan, due to additional bugs in the nvidia drivers. The filters do work correctly on content decoded some other way, and then uploaded to Vulkan (eg: Decode with nvdec, upload with --vf=format=vulkan) * Vulkan filters can only be used with drivers that support VK_EXT_descriptor_buffer which doesn't include Intel ANV as yet. There is an MR outstanding for this. * When dealing with 1080p content, there may be some visual distortion in the bottom lines of frames due to chroma scaling incorporating the extra hidden lines at the bottom of the frame (1080p content is actually stored as 1088 lines), depending on the hardware/driver combination and the scaling algorithm. This cannot be easily addressed as the mechanical fix for it violates the Vulkan spec, and probably requires a spec change to resolve properly. All of these caveats will be fixed in either drivers or ffmpeg, and so will not require mpv changes (unless something unexpected happens) If you want to run on nvidia with the non-beta drivers, you can this ffmpeg tree with the work-around patches: * https://github.com/philipl/FFmpeg/tree/vulkan-nvidia-workarounds
* vo_gpu_next: remove --tone-mapping-crosstalkNiklas Haas2023-05-242-5/+1
| | | | Removed upstream, to be replaced by constant 0.04.
* vo_gpu_next: allow to use ICC profile luminance valueKacper Michajłow2023-05-132-0/+7
| | | | | | Also while at it respect target-peak option when ICC profile is used. Fixes #11449
* player: use XDG_CACHE_HOME by defaultDudemanguy2023-05-093-11/+28
| | | | | | | | | | | | This adds cache as a possible path for mpv to internally pick (~/.cache/mpv for non-darwin unix-like systems, the usual config directory for everyone else). For gpu shader cache and icc cache, controlling whether or not to write such files is done with the new --gpu-shader-cache and --icc-cache options respectively. Additionally, --cache-on-disk no longer requires explicitly setting the --cache-dir option. The old options, --cache-dir, --gpu-shader-cache-dir, and --icc-cache-dir simply set an override for the directory to save cache files. If unset, then the cache is saved in XDG_CACHE_HOME.
* player: use XDG_STATE_HOME for watch_laterDudemanguy2023-05-093-3/+9
| | | | | | | | | | | | | | | | | | A pain point for some users is the fact that watch_later is stored in the ~/.config directory when it's really not configuration data. Roughly 2 years ago, XDG_STATE_DIR was added to the XDG Base Directory Specification[0] and its description, user-specific state data, actually perfectly matches what watch_later data is for. Let's go ahead and use this directory as the default for watch_later. This change only affects non-darwin unix-like systems (i.e. Linux, BSDs, etc.). The directory doesn't move for anyone else. Internally, quite a few things change with regards to the path selection. If the platform in question does not have a statedir concept, then the path selection will simply return "home" instead (old behavior). Fixes #9147. [0]: https://gitlab.freedesktop.org/xdg/xdg-specs/-/commit/4f2884e16db35f2962d9b64312917c81be5cb54b
* DOCS/options: document required parameter for --x11-nameNick Hanley2023-05-061-1/+1
|
* console.lua: add a script-opt for the border sizeGuido Cella2023-04-261-0/+5
| | | | Because I find the console log easier to read with a thicker border.
* ao_pipewire: clarify --pipewire-buffer=nativeThomas Weißschuh2023-04-231-1/+1
|
* ao_pulse: clarify --pulse-buffer=nativeThomas Weißschuh2023-04-231-1/+1
|
* meson: use the new build_options methodDudemanguy2023-04-111-2/+3
| | | | | | | | This finally allows us to put any user defined options into the CONFIGURATION variable like what waf does. The arbitrary hardcoded fallback is left in place for old meson versions. Also update the documentation in regards to the mpv-configuration va