summaryrefslogtreecommitdiffstats
path: root/options/options.c
Commit message (Collapse)AuthorAgeFilesLines
* player: dumb seeking related stuff, make audio hr-seek defaultwm42020-02-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* sub: add an option to filter subtitles by regexwm42020-02-161-0/+6
| | | | | | | | | | | | | | | | | | | | 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.
* sub: make filter_sdh a "proper" filter, allow runtime changeswm42020-02-161-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, filter_sdh was simply a function that was called by sd_ass directly (if enabled). I want to add another filter, so it's time to turn this into a somewhat more general subtitle filtering infrastructure. I pondered whether to reuse the audio/video filtering stuff - but better not. Also, since subtitles are horrible and tend to refuse proper abstraction, it's still messed into sd_ass, instead of working on the dec_sub.c level. Actually mpv used to have subtitle "filters" and even made subtitle converters part of it, but it was fairly horrible, so don't do that again. In addition, make runtime changes possible. Since this was supposed to be a quick hack, I just decided to put all subtitle filter options into a separate option group (=> simpler change notification), to manually push the change through the playloop (like it was sort of before for OSD options), and to recreate the sub filter chain completely in every change. Should be good enough. One strangeness is that due to prefetching and such, most subtitle packets (or those some time ahead) are actually done filtering when we change, so the user still needs to manually seek to actually refresh everything. And since subtitle data is usually cached in ASS_Track (for other terrible but user-friendly reasons), we also must clear the subtitle data, but of course only on seek, since otherwise all subtitles would just disappear. What a fucking mess, but such is life. We could trigger a "refresh seek" to make this more automatic, but I don't feel like it currently. This is slightly inefficient (lots of allocations and copying), but I decided that it doesn't matter. Could matter slightly for crazy ASS subtitles that render with thousands of events. Not very well tested. Still seems to work, but I didn't have many test cases.
* mac: always include the macOS config when cocoa is availableder richter2020-02-091-1/+1
| | | | | | | | | | the macOS config was only used in cocoa-cb before and only included when it was available. since this config is meant for general macOS options and backend independent options we include it when cocoa is available. one of the options is already used in the old cocoa backend, which broke using it when build without swift or cocoa-cb support. Fixes #7449
* player: add ab-loop-count option/propertywm42020-02-081-0/+3
| | | | | | | | | | | | 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
* 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".
* Revert "options: move cursor autohiding opts to mp_vo_opts"dudemanguy2020-01-121-4/+4
| | | | This reverts commit 65a317436df05000366af2738bdbb834e95e33db.
* stream, demux: redo origin policy thingwm42019-12-201-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv has a very weak and very annoying policy that determines whether a playlist should be used or not. For example, if you play a remote playlist, you usually don't want it to be able to read local filesystem entries. (Although for a media player the impact is small I guess.) It's weak and annoying as in that it does not prevent certain cases which could be interpreted as bad in some cases, such as allowing playlists on the local filesystem to reference remote URLs. It probably barely makes sense, but we just want to exclude some other "definitely not a good idea" things, all while playlists generally just work, so whatever. The policy is: - from the command line anything is played - local playlists can reference anything except "unsafe" streams ("unsafe" means special stream inputs like libavfilter graphs) - remote playlists can reference only remote URLs - things like "memory://" and archives are "transparent" to this This commit does... something. It replaces the weird stream flags with a slightly clearer "origin" value, which is now consequently passed down and used everywhere. It fixes some deviations from the described policy. I wanted to force archives to reference only content within them, but this would probably have been more complicated (or required different abstractions), and I'm too lazy to figure it out, so archives are now "transparent" (playlists within archives behave the same outside). There may be a lot of bugs in this. This is unfortunately a very noisy commit because: - every stream open call now needs to pass the origin - so does every demuxer open call (=> params param. gets mandatory) - most stream were changed to provide the "origin" value - the origin value needed to be passed along in a lot of places - I was too lazy to split the commit Fixes: #7274
* command: slightly simplify input-ipc-server change detection/initwm42019-12-171-2/+2
| | | | | | | The generic change detection now handles this just as well. The way how this function is manually called at init is slightly gross. Make that part slightly more explicit to hopefully avoid confusion.
* console.lua: add this scriptJames Ross-Gowan2019-12-081-0/+2
| | | | | | | | | | | | | | | | | | | | | 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>
* options: move cursor autohiding opts to mp_vo_optsdudemanguy2019-12-041-4/+4
| | | | | | Certain backends (i.e. wayland) will need to do special things with the mouse. It makes sense to expose the values of these options to them, so they can behave correctly.
* command: change window-minimized/window-maximized to optionswm42019-11-291-0/+2
| | | | | Unfortunately, this breaks window state reporting for all VOs which supported it. This can be fixed later (for x11 in the next commit).
* options: get rid of GLOBAL_CONFIG hackwm42019-11-291-2/+8
| | | | | | | Just an implementation detail that can be cleaned up now. Internally, m_config maintains a tree of m_sub_options structs, except for the root it was not defined explicitly. GLOBAL_CONFIG was a hack to get access to it anyway. Define it explicitly instead.
* command, options: deprecate old --display-fps behaviorwm42019-11-251-1/+2
| | | | | | | See changelog and manpage changes. (So much effort to fix an ancient dumb mistake for an option nobody should use anyway.)
* options: remove deprecated --playlist-pos aliaswm42019-11-241-1/+0
| | | | | This causes problems because it has the same name as a property which behaves differently.
* player: Optionally validate st_mtime when restoring playback stateChris Down2019-11-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-filewm42019-11-161-1/+2
| | | | | | I have no idea why this still exists, since we have --input-ipc-server. I think there was something about Windows, but the latter option is implemented even on Windows.
* options: remove M_OPT_FIXEDwm42019-11-101-19/+18
| | | | | | | | | | | | | | | | | | | | | | | Options marked with this flag were changed to strictly read-only after initialization (mpv_initialize() in the client API, after option parsing and config file loading with the CLI player). This used to be necessary, because there was a single option struct that could be accessed by multiple threads. For example, --config-dir sets MPOpts.force_configdir, which was read whenever anything accessed the mpv config dir (which could be on different threads, e.g. font initialization tries to lookup fonts.conf from an arbitrary thread). This isn't needed anymore, because threads now access these in a thread safe way. In the case of --config-dir, the path is actually just copied on init. This M_OPT_FIXED mechanism is thus not strictly needed anymore. It still prevents writing to some options that cannot take effect at runtime, but even that can be dropped. In general, all mpv options can be changed any time at runtime, even if they never take effect, and there's no need to make an exception for a very low number of options. So just get rid of it.
* test: make tests part of the mpv binarywm42019-11-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, each .c file in test/ was built as separate, self-contained binary. Each binary could be run to execute the tests it contained. Change this and make them part of the normal mpv binary. Now the tests have to be invoked via the --unittest option. Do this for two reasons: - Tests now run within a "properly" initialized mpv instance, so all services are available. - Possibly simplifying the situation for future build systems. The first point is the main motivation. The mpv code is entangled with mp_log and the option system. It feels like a bad idea to duplicate some of the initialization of this just so you can call code using them. I'm also getting rid of cmocka. There wouldn't be any problem to keep it (it's a perfectly sane set of helpers), but NIH calls. I would have had to aggregate all tests into a CMUnitTest list, and I don't see how I'd get different types of entry points easily. Probably easily solvable, but since we made only pretty basic use of this library, NIH-ing this is actually easier (I needed a list of tests with custom metadata anyway, so all what was left was reimplement the assert_* helpers). Unit tests now don't output anything, and if they fail, they'll simply crash and leave a message that typically requires inspecting the test code to figure out what went wrong (and probably editing the test code to get more information). I even merged the various test functions into single ones. Sucks, but here you go. chmap_sel.c is merged into chmap.c, because I didn't see the point of this being separate. json.c drops the print_message() to go along with the new silent-by-default idea, also there's a memory leak fix unrelated to the rest of this commit. The new code is enabled with --enable-tests (--enable-test goes away). Due to waf's option parser, --enable-test still works, because it's a unique prefix to --enable-tests.
* stream: turn into a ring buffer, make size configurablewm42019-11-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some corner cases (see #6802), it can be beneficial to use a larger stream buffer size. Use this as argument to rewrite everything for no reason. Turn stream.c itself into a ring buffer, with configurable size. The latter would have been easily achievable with minimal changes, and the ring buffer is the hard part. There is no reason to have a ring buffer at all, except possibly if ffmpeg don't fix their awful mp4 demuxer, and some subtle issues with demux_mkv.c wanting to seek back by small offsets (the latter was handled with small stream_peek() calls, which are unneeded now). In addition, this turns small forward seeks into reads (where data is simply skipped). Before this commit, only stream_skip() did this (which also mean that stream_skip() simply calls stream_seek() now). Replace all stream_peek() calls with something else (usually stream_read_peek()). The function was a problem, because it returned a pointer to the internal buffer, which is now a ring buffer with wrapping. The new function just copies the data into a buffer, and in some cases requires callers to dynamically allocate memory. (The most common case, demux_lavf.c, required a separate buffer allocation anyway due to FFmpeg "idiosyncrasies".) This is the bulk of the demuxer_* changes. I'm not happy with this. There still isn't a good reason why there should be a ring buffer, that is complex, and most of the time just wastes half of the available memory. Maybe another rewrite soon. It also contains bugs; you're an alpha tester now.
* options: make --show-profile without parameters list all profileswm42019-10-311-2/+2
|
* sws_utils: shuffle around some shitwm42019-10-311-4/+6
| | | | | | | | | | | Purpose uncertain. I guess it's slightly better, maybe. The move of the sws/zimg options from VO opts (vo_opt_list) to the top-level option list is tricky. VO opts have some helper code in vo.c, that sends VOCTRL_SET_PANSCAN to the VO on every VO opts change. That's because updating certain VO options used to be this way (and not just the panscan option). This isn't needed anymore for sws/zimg options, so explicitly move them away.
* options: set correct range for --video-aspect-overridewm42019-10-251-3/+2
| | | | | It appears this option didn't have min/max enabled for quite a while (broken while it was still called --aspect).
* wayland: add various render-related optionsdudemanguy2019-10-201-0/+5
| | | | | The newest wayland changes have some new logic that make sense to expose to users as configurable options.
* video: add zimg wrapperwm42019-10-201-0/+4
| | | | | | | | | | | | | | | | This provides a very similar API to sws_utils.h, which can be used to convert and scale from one mp_image to another. This commit adds only the code, but does not use it anywhere. The code is quite preliminary and barely tested. It supports only a few pixel formats, and will return failure for many others. (Unlike libswscale, which tries to support anything that FFmpeg knows.) zimg itself accepts only planar formats. Supporting other formats requires manual packing/unpacking. (Compared to libswscale, the zimg API is generally lower level, but allows for more flexibility.) Only BGR0 output was actually tested. It appears to work.
* options: rename --video-aspect to --video-aspect-overrideNiklas Haas2019-10-041-2/+3
| | | | | | | | | | | | The justification for this is the fact that the `video-aspect` property doesn't work well with `cycle_values` commands that include the value "-1". The "video-aspect" property has effectively no change in behavior, but we may want to make it read-only in the future. I think it's probably fine to leave as-is, though. Fixes #6068.
* vo: make swapchain-depth option generic for all VOsAnton Kindestam2019-09-281-0/+2
| | | | In preparation for making vo_drm able to use swapchain-depth
* options: add M_OPT_FILE to some more options that take filesPhilip Sequeira2019-09-271-7/+7
|
* demux_cue: auto-detect CUE sheet charsetwnoun2019-09-211-0/+2
|
* options: deprecate --stream-recordwm42019-09-191-1/+2
| | | | It's inadequate for most uses. There are better mechanisms.
* aspect: add video margin optionswm42019-09-191-0/+4
| | | | | | | | | | | | | | | Semantics a bit questionable. This is done for the OSC (next commit), and a comment added the manpage explicitly states this. Meaning this is probably garbage and needs to revisit when the OSC changes and/or someone wants to use this margin feature for something else. Not sure about the subtitle thing. It's imaginable that someone uses these options to create empty borders for subtitles on the bottom, so subtitles should be located there. On the other hand, this gives a rather unpolished user experience when using the (later added) OSC feature to not overlap with the video. There's not much of a point if the OSC still overlaps the video. However, I'm too lazy to think about this, so it stays like it is.
* demux: add a on-disk cachewm42019-09-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Somewhat similar to the old --cache-file, except for the demuxer cache. Instead of keeping packet data in memory, it's written to disk and read back when needed. The idea is to reduce main memory usage, while allowing fast seeking in large cached network streams (especially live streams). Keeping the packet metadata on disk would be rather hard (would use mmap or so, or rewrite the entire demux.c packet queue handling), and since it's relatively small, just keep it in memory. Also for simplicity, the disk cache is append-only. If you're watching really long livestreams, and need pruning, you're probably out of luck. This still could be improved by trying to free unused blocks with fallocate(), but since we're writing multiple streams in an interleaved manner, this is slightly hard. Some rather gross ugliness in packet.h: we want to store the file position of the cached data somewhere, but on 32 bit architectures, we don't have any usable 64 bit members for this, just the buf/len fields, which add up to 64 bit - so the shitty union aliases this memory. Error paths untested. Side data (the complicated part of trying to serialize ffmpeg packets) untested. Stream recording had to be adjusted. Some minor details change due to this, but probably nothing important. The change in attempt_range_joining() is because packets in cache have no valid len field. It was a useful check (heuristically finding broken cases), but not a necessary one. Various other approaches were tried. It would be interesting to list them and to mention the pros and cons, but I don't feel like it.
* options: rename --play-direction to --play-dirwm42019-09-191-2/+2
| | | | | | | | | | | | | | | | | | | And add simpler aliases for the modes. I'm not sure how to name things, and the option list is in general full of different conventions. Some names are shortened, some are explicit and long. I guess options that have a chance to be used normally (i.e. not obscure tuning or debugging) should have a short and convenient names. In this specific case, play-direction is like a mixture of both. It should be either playback-direction or play-dir, not shorten one word but not the other. The convenience aliases are because I got sick of typing out "backward". I guess "back" would also do it, but there's no proper antonym (and maybe it's "wrong" in the strict sense of the word).
* options: remove --chapterwm42019-09-191-3/+1
| | | | | | | | | Has been deprecated for almost 3 years. Manpage didn't mention the deprecation, but CLI and release notes did. It wouldn't be much effort to keep this option working, but I just don't see the damn point. --start/--end can specify chapters using special syntax, which is equivalent.
* Implement backwards playbackwm42019-09-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See manpage additions. This is a huge hack. You can bet there are shit tons of bugs. It's literally forcing square pegs into round holes. Hopefully, the manpage wall of text makes it clear enough that the whole shit can easily crash and burn. (Although it shouldn't literally crash. That would be a bug. It possibly _could_ start a fire by entering some sort of endless loop, not a literal one, just something where it tries to do work without making progress.) (Some obvious bugs I simply ignored for this initial version, but there's a number of potential bugs I can't even imagine. Normal playback should remain completely unaffected, though.) How this works is also described in the manpage. Basically, we demux in reverse, then we decode in reverse, then we render in reverse. The decoding part is the simplest: just reorder the decoder output. This weirdly integrates with the timeline/ordered chapter code, which also has special requirements on feeding the packets to the decoder in a non-straightforward way (it doesn't conflict, although a bugmessmass breaks correct slicing of segments, so EDL/ordered chapter playback is broken in backward direction). Backward demuxing is pretty involved. In theory, it could be much easier: simply iterating the usual demuxer output backward. But this just doesn't fit into our code, so there's a cthulhu nightmare of shit. To be specific, each stream (audio, video) is reversed separately. At least this means we can do backward playback within cached content (for example, you could play backwards in a live stream; on that note, it disables prefetching, which would lead to losing new live video, but this could be avoided). The fuckmess also meant that I didn't bother trying to support subtitles. Subtitles are a problem because they're "sparse" streams. They need to be "passively" demuxed: you don't try to read a subtitle packet, you demux audio and video, and then look whether there was a subtitle packet. This means to get subtitles for a time range, you need to know that you demuxed video and audio over this range, which becomes pretty messy when you demux audio and video backwards separately. Backward display is the most weird (and potentially buggy) part. To avoid that we need to touch a LOT of timing code, we negate all timestamps. The basic idea is that due to the navigation, all comparisons and subtractions of timestamps keep working, and you don't need to touch every single of them to "reverse" them. E.g.: bool before = pts_a < pts_b; would need to be: bool before = forward ? pts_a < pts_b : pts_a > pts_b; or: bool before = pts_a * dir < pts_b * dir; or if you, as it's implemented now, just do this after decoding: pts_a *= dir; pts_b *= dir; and then in the normal timing/renderer code: bool before = pts_a < pts_b; Consequently, we don't need many changes in the latter code. But some assumptions inhererently true for forward playback may have been broken anyway. What is mainly needed is fixing places where values are passed between positive and negative "domains". For example, seeking and timestamp user display always uses positive timestamps. The main mess is that it's not obvious which domain a given variable should or does use. Well, in my tests with a single file, it suddenly started to work when I did this. I'm honestly surprised that it did, and that I didn'