summaryrefslogtreecommitdiffstats
path: root/DOCS/man/options.rst
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: warn if correct-downscaling is ignoredAvi Halachmi (:avih)2020-03-141-0/+2
| | | | And document that it's ignored with bilinear scaler.
* manpage: fix typoswm42020-03-061-2/+2
|
* demux: deprecate --cache-secswm42020-03-051-2/+13
| | | | | Because it's confusing and useless. If nobody complains, we'll have one weird cache configuration option less.
* manpage: make suggestion for --vd-queue dynamic configwm42020-03-051-1/+3
|
* f_decoder_wrapper: make decoder thread responsive while filling queuewm42020-03-051-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The mp_filter_run() invocation blocks as long as the demuxer provides packets and the queue can be filled. That means it may block quite a long time of the decoder queue size is large (since we use libavcodec in a blocking manner; it regrettably does not have an async. API). This made the main thread freeze in certain situations, because it has to wait on the decoder thread. Other than I suspected (I wrote that code, but that doesn't mean I know how the hell it works), this did not freeze during seeking: seek resets flushed the queue, which also prevented the decoder thread from adding more frames to it, thus stopping decoding and responding to the main thread in time. But it does fix the issue that exiting the player waited for the decoder to finish filling the queue when stopping playback. (This happened because it called mp_decoder_wrapper_set_play_dir() before any resets. Related to the somewhat messy way play_dir is generally set. But it affects all "synchronous" decoder wrapper API calls.) This uses pretty weird mechanisms in filter.h and dispatch.h. The resulting durr hurr interactions are probably hard to follow, and this whole thing is a sin. On the other hand, this is a _very_ user visible issue, and I'm happy that it can be fixed in such an unintrusive way.
* manpage: document how final queue size is determinedwm42020-03-051-0/+5
| | | | Believe it or not, users were confused about this.
* demuxer-lavf: udp_multicast rtsp-transport optionmg2020-03-031-1/+1
|
* manpage: suggest using the decoding queue with backward playbackwm42020-03-011-0/+3
|
* f_decoder_wrapper: make most queue options runtime changeablewm42020-03-011-0/+4
| | | | Why not.
* ad_lavc: disable decoder downmix by defaultwm42020-02-291-1/+1
| | | | | | | | Let's see how much everyone hates this. Leaving it enabled seems problematic, because libavcodec returns an unspecific error if it doesn't like it. Fixes: #6300
* player: add optional separate video decoding threadwm42020-02-291-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See manpage additions. This has been a topic in MPlayer/mplayer2/mpv since forever. But since libavcodec multi-threaded decoding was added, I've always considered this pointless. libavcodec requires you to "preload" it with packets, and then you can pretty much avoid blocking on it, if decoding is fast enough. But in some cases, a decoupled decoder thread _might_ help. Users have for example come up with cases where decoding video in a separate process and piping it as raw video to mpv helped. (Or my memory is false, and it was about vapoursynth filtering, who knows.) So let's just see whether this helps with anything. Note that this would have been _much_ easier if libavcodec had an asynchronous (or rather, non-blocking) API. It could probably have easily gained that with a small change to its multi-threading code and a small extension to its API, but I guess not. Unfortunately, this uglifies f_decoder_wrapper quite a lot. Part of this is due to annoying corner cases like legacy frame dropping and hardware decoder state. These could probably be prettified later on. There is also a change in playloop.c: this is because there is a need to coordinate playback resets between demuxer thread, decoder thread, and playback logic. I think this SEEK_BLOCK idea worked out reasonably well. There are still a number of problems. For example, if the demuxer cache is full, the decoder thread will simply block hard until the output queue is full, which interferes with seeking. Could also be improved later. Hardware decoding will probably die in a fire, because it will run out of surfaces quickly. We could reduce the queue to size 1... maybe later. We could update the queue options at runtime easily, but currently I'm not going to bother. I could only have put the lavc wrapper itself on a separate thread. But there is some annoying interaction with EDL and backward playback shit, and also you would have had to loop demuxer packets through the playloop, so this sounded less annoying. The food my mother made for us today was delicious. Because audio uses the same code, also for audio (even if completely pointless). Fixes: #6926
* player: dumb seeking related stuff, make audio hr-seek defaultwm42020-02-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Try to deal with various corner cases. But when I fix one thing, another thing breaks. (And it's 50/50 whether I find the breakage immediately or a few months later.) So results may vary. The default for--hr-seek is changed to "default" (not creative enough to find a better name). In this mode, audio seeking is exact if there is no video, or if the video has only a single frame. This change is actually pretty dumb, since audio frames are usually small enough that exact seeking does not really add much. But it gets rid of some weird special cases. Internally, the most important change is that is_coverart and is_sparse handling is merged. is_sparse was originally just a special case for weird .ts streams that have the corresponding low-level flag set. The idea is that they're pretty similar anyway, so this would reduce the number of corner cases. But I'm not sure if this doesn't break the original intended use case for it (I don't have a sample anyway). This changes last-frame handling, and respects the duration of the last frame only if audio is disabled. This is mostly "coincidental" due to the need to make seeking past EOF trigger player exit, and is caused by setting STATUS_EOF early. On the other hand, this might have been this way before (see removed chunk close to it).
* demux_mkv: document probe-start-time option and enable it by defaultwm42020-02-271-0/+6
| | | | | | | | | | | | This is useful with live streams, and it's not much worse than the h264 first packet hack, which reads some data anyway. For some reason, the option wasn't even documented, so do that. In addition, print the start time even if it's negative. That should not be possible, but for some reason, the field is an int64_t copied from an uint64_t so... whatever. Keeping the logging slightly more straight forward is better anyway.
* demux: simplify some internals, stop trying to read packets after EOFwm42020-02-271-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove some redundant fields that controlled or indicated whether the demuxer was/could/should prefetch. Redefine how the eof/reading fields work. The in->eof field is now always valid, instead of weirdly being reset to false in random situations. The in->reading field now corresponds to whether the demuxer thread is working at all, and is reset if it stops doing anything. Also, I always found it stupid that dequeue_packet() forced the demuxer thread to retry reading if it was EOF. This makes little sense, but was probably added for files that are being appended to (running downloads). It makes no sense, because if the cache really tried to read until file EOF, it would encounter partial packets and throw errors, so all is lost anyway. Plus stream_file now handles this better. So stop this behavior, but add a temporary option that enables the old behavior. I think checking for ds->eager when enabling prefetching never really made sense (could be debated, but no, not really). On the other hand, the change above exposed a missing wakeup in the backward demuxing code. Some chances of regressions that could make it stuck in certain states or so, or incorrect demuxer cache state reporting to the player frontend.
* ytdl_hook: enable default selection via --ytdl-format with all_formatswm42020-02-211-4/+7
| | | | | | | | | In all_formats mode, we've ignored what --ytdl-format did so far, since we've converted the full format list, instead of just the formats selected by youtube-dl. But we can easily restore --ytdl-format behavior: just mark the selected tracks as default tracks.
* ytdl_hook: replace skip_muxed with force_all_formats optionwm42020-02-211-16/+33
| | | | | | | | | | | | | I don't think the skip_muxed option was overlay useful. While it was nice to filter out the low quality muxed versions (as it happens on the alphabetic site, I suspect it's compatibility stuff), it's not really necessary, and just makes for another tricky and rarely used configuration option. (This was different before muxed tracks were also delay-loaded, and including the muxed versions slowed down loading.) Add the force_all_formats option instead, which handles the HLS case. Set it to true because they are also delay-loaded now, and don't slow down startup as much.
* manpage: reorganize ytdl_hook option descriptionswm42020-02-211-51/+66
| | | | Make it a proper list, instead of a paragraph soup.
* ytdl_hook: attempt to filter out muxed streams if all_formats is usedwm42020-02-201-0/+12
| | | | | | | | | | | | | See manpage additions. We would have to extend delay_open to support multiple sub-tracks (for audio and video), and we'd still don't know (?) whether it might contain more than one stream each (thinking of HLS master streams). And if it's a true interleaved file (such as a "normal" mp4 file provided as fallback for more primitive players), we'd either have to signal such "bundled" tracks, or waste bandwidth. This restructures a lot. The if/else tree in add_single_video for format selection was a bit annoying, so it's split into separate if blocks, where it checks each time whether a URL was determined yet.
* manpage: minor fixeswm42020-02-191-10/+10
| | | | | In particular, all_formats description split away the example section of an unrelated option, so move that to its proper place.
* ytdl_hook: add all_formats optionwm42020-02-191-0/+17
| | | | | | | | | Pretty worthless I guess. I only tested one site (and 2 videos), it's somewhat likely that it will break with other sites. Even if you leave the option disabled (the default). Slightly related to #3548. This will allows you to use the bitrate stream selection mechanism, that was added for HLS, with normal videos.
* ytdl_hook: add a way to not pass --format to the command linewm42020-02-191-2/+7
| | | | Might be helpful for... whatever.
* sub: add an option to filter subtitles by regexwm42020-02-161-0/+41
| | | | | | | | | | | | | | | | | | | | Works as ad-filter. I had some more plans, for example replacing matching text with different text, but for now it's dropping matches only. There's a big warning in the manpage that I might change semantics. For example, I might turn it into a primitive sed. In a sane world, you'd probably write a simple script that processes downloaded subtitles before giving them to mpv, and avoid all this complexity. But we don't live in a sane world, and the sooner you learn this, the happier you will be. (But I also want to run this on muxed subtitles.) This is pretty straightforward. We use POSIX regexes, which are readily available without additional pain or dependencies. This also means it's (apparently) not available on win32 (MinGW). The regex list is because I hate big monolithic regexes, and this makes it slightly better. Very superficially tested.
* msg: slightly improve --msg-time outputwm42020-02-141-1/+4
| | | | Cut the arbitrary offset, and document what unit/timesource it uses.
* manpage: clarify --player-operation-modewm42020-02-141-1/+1
| | | | | | | options.rst to clarify the option, some more text in mpv.rst to separate out the compatibility stuff a little. Fixes: #7461 (options.rst change only)
* sws_utils: use zimg by default if availablewm42020-02-121-6/+5
| | | | | This seems stable enough to use. Change the default, and remove it from the sw-fast profile.
* manpage: add some blabla about zimg speed vs. libswscalewm42020-02-101-1/+10
| | | | | Of course nobody will read this. I'm just putting it there so I can blame users, who run into problems, for not having read it.
* player: add ab-loop-count option/propertywm42020-02-081-0/+8
| | | | | | | | | | | | As requested I guess. It behaves quite similar to the --loop* options. Not quite happy with the idea that 1) the option is mutated on each operation (but at least it's consistent with --loop* and doesn't require more properties), and 2) the ab-loop command will do nothing once all loop iterations are done. As a concession, the OSD shows something about "disabled". Fixes: #7360
* mac: activate logging when started from the bundleder richter2020-02-081-0/+3
| | | | | | | | | | this creates a default log for the last mpv run when started from the bundle. that way one can get a log of what happened even after an issue occurred. also add a menu entry under Help to show the current log, but only when the bundle is used. Fixes #7396 Fixes #2547
* demux: add option to disable "sharing" between back and forward bufferswm42020-02-071-1/+14
| | | | | | | As requested. I guess option name and manpage text could be better and clearer. Closes: #7442
* options: disable vsfilter blur compat by defaultwm42020-02-071-1/+1
| | | | | | | | | | | | | | | | | | | See #7435 and related for context. Basically, it seems that while the original vsfilter processed subtitles like with this option set to "yes", many current players (mpc-hc default, vlc, probably most libass users) treat them like with "no". In the linked issue, this makes rendering severely slower, and can consume a lot of memory (or just overflow libass memory calculations). It seems that changing this to "no" will lead to more good than bad, especially because newer subtitles may be authored for the "no" behavior. Most libass users seem to use "no" exactly because they do not call ass_set_storage_size() at all. This API was needed because the scaling of the subtitles depends on the video size (vsfilter bugs, or something). In addition, it's my personal opinion that rendering should not depend on the video at all, so I like setting the default of this to "no".
* manpage: --sub-codepage cannot do muxed subswm42020-02-011-0/+5
| | | | | mpv actually used to be able to, from what I remember, but this was changed for simplicity and because of problems with FFmpeg.
* wayland: remove wayland-frame-wait-offset optiondudemanguy2020-01-311-9/+0
| | | | | | | | | | | | | | | | | This originally existed as a hack for weston. In certain scenarios, a frame taking too long to render would cause vo_wayland_wait_frame to timeout which would result in a ton of dropped frames. The naive solution was to just to add a slight delay to the time value. If a frame took too long, it would likely to fall under the timeout value and all was well. This was exposed to the user since the default delay (1000) was completely arbitrary. However with presentation time, this doesn't appear to be neccesary. Fresh frames that take longer than the display's refresh rate (16.666 ms in most cases) behave well in Weston. In the other two main compositors without presentation time (GNOME and Plasma), they also do not experience any ill effects. It's better not to overcomplicate things, so this "feature" can be removed now.
* manpage: update force dedicated gpu on macOS optionder richter2020-01-271-1/+1
| | | | was forgotten in commit 3275cd0
* libarchive: some shitty hack to make opening slightly fasterwm42020-01-041-0/+12
| | | | | | | | See manpage additions. The libarchive behavior mentioned in the last paragraph there is technically unrelated, but makes this new option mostly pointless. See: #7182
* manpage: update discussion of nvidia hardware accelerationPhilip Langdale2019-12-291-26/+25
| | | | | The text here has become somewhat outdated over the years, and it's worth updating to reflect the current situation.
* video: cuda: add explicit context creation for copy hwaccelsPhilip Langdale2019-12-291-8/+9
| | | | | | | | | | | | | | | | | | | | | In the distant past, the cuviddec backed copy hwaccel could be configured directly using lavc options. However, since that time, we gained support for automatic hw ctx creation which ended up bypassing the lavc options. Rather than trying to find a way to pass those options again, a better idea is to make the 'cuda-decode-device' option, used by the interop hwaccels, work for the copy hwaccels too. And that's pretty simple: we have to add a create function that checks the option and passes it on to ffmpeg. Note that this does require a slight re-jig to the configuration flags, as we now have a scenario where we want to build with support for the cuda copy hwaccels but not the interop ones. So we need a distinct configuration flag for that combination. Fixes #7295.
* manpage: fix example in --hwdec sectionwm42019-12-241-1/+3
|
* vd_lavc: more hwdec autoselect nonsensewm42019-12-241-4/+36
| | | | | | | | | | | | | Add an "auto-safe" mode, mostly triggered by Ubuntu's nonsense to force hwdec=vaapi in the global config file in their mpv package. But to be honest it's probably something more people want. This is implemented as explicit whitelist. On Windows, HEVC/Intel is sometimes broken, but it's still whitelisted, and in theory we'd need a detailed whitelist of device names etc. (like for example browsers tend to do). On OSX, videotoolbox is a pretty bad choice, but unfortunately the only one, so it's whitelisted too. There may be a larger number of hwdec wrappers that work anyway, and I'm for example ignoring Android.
* video/out/x11: add fs-screen fallbackNicolas F2019-12-221-2/+2
| | | | | | | | | | | | | Apparently there are two different options for controlling which screen an mpv window goes onto: --fs-screen and --screen. The former explicitly only controls which screen a fullscreened window goes onto, but does not appear to actually care about this option at runtime for X11, so pressing f will always fullscreen to the screen mpv is currently on. This means the option is of questionable usefulness for starters. Making it worse, if you use --screen=1 --fs, mpv will actually fullscreen on screen 0, because --fs-screen isn't set. Instead of doing that, fall back to whatever --screen is set to.
* demux: add an option to control tag charsetwm42019-12-201-0/+13
| | | | | | Fucking gross that you need this in almost-2020. Fixes: #7255
* options: increase consistency between list options and document themwm42019-12-181-7/+43
| | | | | | | | | | | | | | | | | | | | Whenever I deal with this, I have to look at the code to make sense of this. And beyond that, there are some strange inconsistencies. (I think this code is cursed. It always was, and maybe always will be.) Although the manpage claimed that using multiple items for -add etc. is deprecated, string list options didn't warn against it. So add the warning, and add something in the changelog (even though nobody will ever read this). The manpage mentioned --vf-append, but this didn't even exist. So add it, I guess. We encourage using -append for the other option types, so for consistency, it should work on filter options. (And I already tricked me into believing it existed when I mentioned it in the manpage.) Make the "operations" table separate for all option types, and mention the option type on every single of the top-level list options.
* mac: remove Apple Remote supportder richter2019-12-151-4/+0
| | | | | | the Apple Remote has long been deprecated and abandoned by Apple. current macs don't come with support for it anymore. support might be re-added with the next commit.
* manpage: fix --vulkan-async-compute default valuewm42019-12-121-2/+2
| | | | | | | | | | Seems like this was silently changed to enabled by default on the change to libplacebo, without adjusting the manpage. Fix the documented default. Also add a comment about Nvidia; see referenced issue. Fixes: #7245
* console.lua: add this scriptJames Ross-Gowan2019-12-081-0/+6
| | | | | | | | | | | | | | | | | | | | | Merged from mpv-repl git repo commit 5ea2bf64f9c239f0326b02. Some changes were made on top of it: - Tabs were converted to 4 spaces indentation (plus some manual indentation fixes in some places). - All user-visible mentions of "repl" were renamed to "console". - The README was converted to a manpage (with heavy changes, some additions taken from stats.rst; rossy converted the key bindings table to RST). - The method to change the default key binding was changed. - Change minor detail about "font" default value setting (not a functional change). - Integrate into the player as builtin script, including an option to prevent loading it. Above changes and commit message done by wm4. Signed-off-by: wm4 <wm4@nowhere>
* DOCS: fix wayland-frame-wait offset value rangedudemanguy2019-12-051-1/+1
| | | | It actually goes down to -500 not -100.
* x11: implement unminimizationwm42019-11-291-1/+1
| | | | This appears to work with IceWM.
* command: change window-minimized/window-maximized to optionswm42019-11-291-0/+17
| | | | | Unfortunately, this breaks window state reporting for all VOs which supported it. This can be fixed later (for x11 in the next commit).
* command, options: deprecate old --display-fps behaviorwm42019-11-251-3/+5
| | | | | | | See changelog and manpage changes. (So much effort to fix an ancient dumb mistake for an option nobody should use anyway.)
* player: Optionally validate st_mtime when restoring playback stateChris Down2019-11-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I often watch sporting events. On many occasions I get files with the same filename for each session. For example, for F1 I might have the following directory structure: F1/ FP1.mkv FP2.mkv FP3.mkv Qualification.mkv Race.mkv Since usually one simply watches one race after the other, I usually just rsync the new event's files over the old ones, so, for example, Race.mkv will be replaced from the file for the last event with the file from the new event. One problem with this is that I like to use --resume-playback for other kinds of media, so I have it on by default. That works great for, say, a movie, but doesn't work so well with this scheme, because you can trivially forget to pass --no-resume-playback on the command line and end up 2 hours in, watching spoilers as the race results scroll down the screen :-) This patch adds a new option, --resume-playback-check-mtime, which validates that the file's mtime hasn't changed since the watch_later configuration was saved. It does this by setting the watch_later configuration to have the same mtime as the file after it is saved. Switching back and forth between checking mtime and not checking mtime works fine, as we only choose whether to compare based on it, but we update the watch_later configuration mtime regardless of its value.
* options: deprecate --input-fi