summaryrefslogtreecommitdiffstats
path: root/player/command.c
Commit message (Collapse)AuthorAgeFilesLines
* command: add cache-duration to cache state propertywm42020-02-071-0/+3
| | | | Convenience; see following commit.
* Revert "options: move cursor autohiding opts to mp_vo_opts"dudemanguy2020-01-121-1/+1
| | | | This reverts commit 65a317436df05000366af2738bdbb834e95e33db.
* command, vo: add a mechanism for runtime DPI scale changeswm42020-01-091-1/+4
| | | | | Follow up to commit a58585d5e063. It turned out that the OSX backend needs this.
* command: cache display-hidpi-scale propertywm42020-01-081-4/+14
| | | | | | | | | | | | | | | | | | | | | | This is a gross hack for the shitty design of how VO properties are handled (which was fine with MPlayer, but became increasingly a shit tub with mpv's VO thread). The problem here is that console.lua reads display-hidpi-scale on every render, but which may take a long time for video timing and vsync blocking. It will also block the core, making osc.lua unable to react to window resizing quickly enough. This should be solved by not using the "classic" blocking VOCTRL mechanism, and instead side-stepping it with something that doesn't require any waiting (like for example the "fullscreen" property does). But this require more thinking and work my "brain" can handle at the moment. So for now add a shitty hack that will cause a lot of problems, and which will have to be replaced later. Most importantly, it'll break theoretic support for multiple screens with different DPI, or runtime DPI changes. Possibly could affect the Cocoa backend; the X11 isn't dynamic enough by nature, and other backends do not implement this.
* command: remove outdated MP_EVENT_WIN_STATE entrieswm42020-01-081-2/+1
| | | | | These properties are handled very differently now, and being in that list did pretty much nothing.
* command: add osd-dimensions propertywm42020-01-081-22/+26
| | | | | | | | | | | This "bundles" all OSD properties. It also makes some previously Lua-only values available (Lua has mp.get_osd_margins(), unsure if anything uses it). The main intention is actually to allow retrieving all fields in an "atomic" way. (Could introduce a mechanism on the level of the mpv client API to do this, but doing ti ad-hoc all the time like this commit is easier.)
* command: make sub-step command actually apply sub-delay change properlywm42020-01-041-1/+1
| | | | | | | | | The change was not propagated to the OSD/subtitle code, since that still uses an "old" method. Change it so that the propagation is actually performed. (One could argue the OSD/subtitle code should use other ways to update the options, but that would probably be more effort for now.)
* command: add a playlist-unshuffle commandwm42019-12-281-0/+10
| | | | | | Has a number of restrictions. See: #2491, #7294
* playlist: change from linked list to an arraywm42019-12-281-38/+13
| | | | | | | | | | | | | | | | | | | Although a linked list was ideal at first, there are cases where it sucks, and became increasingly awkward (with the mpv command API preferring integer indexes to access the list). In future, we probably want to add more playlist-related functionality, so better change it to an array now. An array isn't always ideal either. Since playlist entries are still separate objects (because in some cases you need a stable "iterator" to it), but you still need to efficiently get the next/previous playlist entry, there's a pl_index field, that needs to be maintained. E.g. adding an entry at the start of the playlist => update the pl_index field for all other entries. Well, it's not really worth to do something more complicated to avoid these things. This commit is probably buggy as shit. It's not like I bothered to test everything. That's _your_ role.
* command: extend command-list outputwm42019-12-241-0/+14
| | | | Add some very basic information about arguments.
* client API, lua: add new API for setting OSD overlayswm42019-12-231-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | Lua scripting has an undocumented mp.set_osd_ass() function, which is used by osc.lua and console.lua. Apparently, 3rd party scripts also use this. It's probably time to make this a public API. The Lua implementation just bypassed the libmpv API. To make it usable by any type of client, turn it into a command, "osd-overlay". There's already a "overlay-add". Ignore it (although the manpage admits guiltiness). I don't really want to deal with that old command. Its main problem is that it uses global IDs, while I'd like to avoid that scripts mess with each others overlays (whether that is accidentally or intentionally). Maybe "overlay-add" can eventually be merged into "osd-overlay", but I'm too lazy to do that now. Scripting now uses the commands. There is a helper to manage OSD overlays. The helper is very "thin"; I only want to force script authors to use the ID allocation, which may help with putting multiple scripts into a single .lua file without causing conflicts (basically, avoiding singletons within a script's environment). The old set_osd_ass() is emulated with the new API. The JS scripting wrapper also provides a set_osd_ass() function, which calls internal mpv API. Comment that part (to keep it compiling), but I'm leaving it to @avih to finish the change.
* command: fix confusing displayed aspect-ratioAbdullah Alansari2019-12-221-0/+33
| | | | | For example, when a user switches the aspect-ratio display `16:9` instead of `1.778` and `Original` instead of `-1.000`.
* command: add property returning hidpi scalewm42019-12-201-0/+12
|
* command: reduce OSC/stats log spamwm42019-12-191-8/+11
| | | | | | | | | | | | | | | | | | For some inexplicable reason, the OSC runs the expand-text command a _lot_. This command is logged at the log file default log level, so the log file can quickly fill up with these messages. It directly violates the mpv logging policy: per-frame (or similarly common) log messages should not be enabled by default for the log file. stats.lua uses the show-text command for some reason (instead of creating its own OSD layer). Explicitly reduce the log level for expand-text and some other commands. Also reduce the log level for commands triggered by mouse movement. The previous commit also contributed some to reduce log spam. Fixes: #4771
* command, lua: add a way to share data between scriptswm42019-12-181-0/+31
| | | | | | | | | Very primitive and dumb, but fulfils its purpose for the next commits. I chose this specific implementation because it has the lowest footprint in command.c, without resorting to crazy hacks such as sending messages between scripts (which would be hard to coordinate especially on startup).
* command: make change-list work with pure properties toowm42019-12-181-5/+14
| | | | Until now, it only worked on options. Useful for the next commit.
* command, vo: remove old option change notification mechanismswm42019-12-171-13/+2
| | | | | | | These all have been replaced recently. There was a leftover in window.swift. It couldn't have done anything useful in the current state of the code, so drop these lines.
* command: slightly simplify input-ipc-server change detection/initwm42019-12-171-17/+6
| | | | | | | 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.
* command: change "window-scale" property behaviorwm42019-12-161-20/+15
| | | | | | | | | This is similar to the "edition" change. I considered making this go through deprecation, but didn't have a good idea how to do that. Maybe it's fine, because this is pretty obscure. But it might break some API users/scripts (it certainly broke stats.lua), and all I have to say is sorry for that.
* command: remove unnecessary mute property implementationwm42019-12-161-15/+0
| | | | | This only added the CONSTRICTED_TYPE thing, but it works correctly without.
* command: change "edition" property behaviorwm42019-12-161-10/+19
| | | | | | | | | See manpage/changelog changes. The purpose of this change is to removes another case of inconsistent property behavior. At first I wanted to make this go through deprecation before making a technically incompatible change, but then I considered this feature too obscure as that anyone would care.
* command: fix unintended reset of filterswm42019-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | Since the recent option changes (probably b16cea750f527), using the "vf" or "af" commands to change the filter chain did not write the option value correctly. This led to the option value being reset the next time an option changed. This happened because the new option value was not copied to the m_config_cache's internal storage. So on the next option update, it looked like the option value changed, because the user-side value was different from the internal value. It was copied back, which meant the original option value was reinstated, and the previous "vf"/"af" command was undone. Fix this by using the correct way to store the option value. This also takes care of property change notification (because the function is specifically separate from m_config_cache_write_opt() to do that), so remove the old call. Fixes: #7220
* options: move cursor autohiding opts to mp_vo_optsdudemanguy2019-12-041-1/+1
| | | | | | 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.
* wayland: update Maximize and Minimize handling to use new optionsPhilip Langdale2019-12-011-4/+0
| | | | | | | | | | | I wanted to get this done quickly as I introduced the new VOCTRL behaviour for minimize and maximize and it was immediately made legacy, so best to purge it before anyone gets confused. I did not sort out fullscreen as that's more involved and not something I've educated myself about yet. But I did replace the VOCTRL_FULLSCREEN usage with the new option change mechanism as that seemed simple enough.
* command: remove property change notification from property dispatcherwm42019-11-301-3/+2
| | | | | | Properties should handle this themselves. This basically sent redundant notifications. I found only two places where the "proper" notification was missing.
* command: merge two functionswm42019-11-301-11/+3
| | | | Due to recent changes, it makes no sense anymore to keep them separate.
* command: remove another unneeded hackwm42019-11-301-12/+2
| | | | | | | | | | | Now that the option-to-property bridge is gone, this is not needed anymore. It always took the "silent" path. Also, at least as of before this commit, this didn't correctly print a warning when accessing a deprecated option as property. This was because m_config_get_co_raw() was used, which intentionally does not print any warnings, so switch to the non-raw one. (Affects only options that have .deprecation_message set.)
* command: change window-minimized/window-maximized to optionswm42019-11-291-50/+4
| | | | | Unfortunately, this breaks window state reporting for all VOs which supported it. This can be fixed later (for x11 in the next commit).
* player: change m_config to use new option handling mechanismswm42019-11-291-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of making m_config a special-case, it more or less uses the underlying m_config_cache/m_config_shadow APIs properly. This makes the player core a (relatively) equivalent user of the core option API. In particular, this means that other threads can change core options with m_config_cache_write_opt() calls (before this commit, this merely led to diverging option values). An important change is that before this commit, mpctx->opts contained the "master copy" of all option data. Now it's just another copy of the option data, and the shadow copy is considered the master. This is why whenever mpctx->opts is written, the change needs to be copied to the master (thus why this commits add a bunch of m_config_notify... calls). If another thread (e.g. a VO) changes an option, async_change_cb is now invoked, which funnels the change notification through the player's layers. The new self_notification parameter on mp_option_change_callback is so that m_config_notify... doesn't trigger recursion, and it's used in cases where the change was already "processed". It's still needed to trigger libmpv property updates. (I considered using an extra m_config_cache for that, but it'd only cause problems with no advantages.) I think the recent changes actually forgot to send libmpv property updates in some cases. This should fix this anyway. In some cases, property updates are reworked, and the potential for bugs should be lower (probably). The primary point of this change is to allow external updates, for example by a VO writing the fullscreen option if the window state is changed by the window manager (rather than mpv changing it). This is not used yet, but the following commits will.
* command: use m_option_equal()wm42019-11-291-16/+1
| | | | No more converting the option values to a string to compare it.
* command: add `window-maximized` and make `window-minimized` settablePhilip Langdale2019-11-291-2/+38
| | | | | | | | | | | If we want to implement window pseudo-decorations via OSC, we need a way to tell the vo to minimize and maximize the window. Today, we have minimized as a read-only property, and no property for maximized. Let's made minimized settable and add a maximized property to go with it. In turn, that requires us to add VOCTRLs for minimizing or maximizing a window, and an additional WIN_STATE to indicate a maximized window.
* options: remove options-to-property bridgewm42019-11-251-49/+2
| | | | | | | | The previous bunch of commits made this unnecessary, so this should be a purely internal change with no user impact. This may or may not open the way to future improvements. Even if not, at least the property/option interaction should now be much less buggy.
* command: shuffle around even more crapwm42019-11-251-76/+17
| | | | | | | | | | | | | | | | | | Convert some remaining properties to work without the option-to-property bridge. Behavior shouldn't change (except for the corner case that it tries to reapply the new state when setting a property, while it used to ignore redundant sets). As it is the case with many of these changes, much of the code is not in its final proper state yet, but is rather a temporary workaround. For example, these "VO flag" properties should just be fully handled in the VO backend. (Currently, the config or VO layers don't provide enough mechanism yet as that all the backends like x11, win32, etc. could be changed yet, but that's another refactoring mess for another time.) Now nothing relies on this option-to-property bridge anymore, which opens the way to even more refactoring, which eventually may result in tiny improvements for the end user.
* command: change vid/aid/sid property behavior slightlywm42019-11-251-44/+26
| | | | | Again in line with the option-to-property bridge changes. As usual, this causes subtle behavior changes, which may affect some users.
* command: change af/vf property behavior wrt. filter creation failureswm42019-11-251-6/+7
| | | | | | The behavior is slightly different in a messy way. The change is in line with the option-to-property bridge removal mentioned some commits ago and thus is deemed necessary.
* command: remove redundant reinit_filters() call on filter change failurewm42019-11-251-1/+0
| | | | | | This attempted to restore the old filter chain if setting a new one at runtime failed. This is not needed anymore, because changing the filter chain is done in a "transactional" way now.
* command, options: deprecate old --display-fps behaviorwm42019-11-251-2/+20
| | | | | | | See changelog and manpage changes. (So much effort to fix an ancient dumb mistake for an option nobody should use anyway.)
* command: shuffle some crap aroundwm42019-11-251-166/+98
| | | | | | | | | | | | | | | | | | | | | | | | This is preparation to get rid of the option-to-property bridge (mp_on_set_option). This is a pretty insane thing that redirects accesses to options to properties. It was needed in the ever ongoing transition from something to... something else. A good example for the need of this bridge is applying profiles at runtime. This obviously goes through the config parser, but should also make all changes effective, for which traditionally the property layer is used. There isn't much left that needs this bridge. This commit changes a bunch of options (which also have a property implementation) to use option change notifications instead. Many of the properties are still left, but perform unrelated functions like OSD formatting. This should be mostly compatible. There may be some subtle behavior changes. For example, "hwdec" and "record-file" do not check for changes anymore before applying them, so writing the current value to them suddenly does something, while it was ignored before. DVB changes untested, but should work.
* command, input: add input-bindings propertywm42019-11-231-1/+18
| | | | | | Read-only information about all bindings. Somewhat hoping someone can make a nice GUI-like overlay thing for it, which provides information about mapped keys.
* command: add command-list propertywm42019-11-231-0/+25
|
* input: change mp_cmd.original from bstr to cstrwm42019-11-231-2/+2
| | | | | | | | No reason to have this as bstr, just makes everything more complex. Also clear mp_cmd.sender when it's copied. Otherwise it would be a dangling pointer. Apparently it's never set to non-NULL in this situation, but this is cleaner anyway.
* input: add text produced by key to script key eventswm42019-11-221-3/+4
| | | | | | | Particularly for "any_unicode" mappings, so they don't have to special-case keys like '#' and ' ', which are normally mapped to symbolic names for input.conf reasons. (Though admittedly, this is a pretty minor thing, since API users could map these manually.)
* options: remove M_SETOPT_RUNTIMEwm42019-11-101-9/+6
| | | | | | | Used to contain flags for "save" setting of options at runtime. Now there is nothing special needed anymore and it's 0. So drop it completely, and remove anything that distinguishes between runtime and initialization time.
* stats, demux: log byte level stream seekswm42019-11-071-0/+1
|
* img_format: remove some unused format flagswm42019-11-031-1/+1
| | | | | | | | | | | | | | | | | They were used at some point, but then fell into disuse. In general, these old flags are all a bit fuzzy, so it's a good idea to remove them as much as possible. The comment about MP_IMGFLAG_PAL isn't true anymore. The old meaning was deprecated at some point, and the flag was removed from "pseudo paletted" formats. I think mpv at one point changed its own flag from AV_PIX_FMT_FLAG_PSEUDOPAL to AV_PIX_FMT_FLAG_PAL, when the former was deprecated, and it became unnecessary to allocate a palette for non-paletted formats. (The one who deprecated in FFmpeg was me, if you wonder.) MP_IMGFLAG_PLANAR was used in command.c, use a relatively similar flag as replacement.
* command: remove some unused property metadatawm42019-10-251-16/+2
| | | | Also add an OSD entry for the video aspect.
* options: rename --video-aspect to --video-aspect-overrideNiklas Haas2019-10-041-2/+27
| | | | | | | | | | | | 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.
* stream_dvb: Allow actual zapping of channels again.Oliver Freyermuth2019-10-021-0/+1
| | | | | | | | | | | | | | | This is realized by dvbin-channel-switch-offset, which is a numeric offset on the channel initially tuned to. Since the channel list is kept in the stream alone depending on detected hardware and chosen card, and no available backchannel to the player, there's no direct property which could be switched. Using input.conf like: H cycle dvbin-channel-switch-offset up K cycle dvbin-channel-switch-offset down Q set dvbin-prog "ZDF HD" allow fast and reliable channel switching again.
* player: Add mp_property_dvb_channel helper.Oliver Freyermuth2019-10-021-0/+17
| | | | | | | Reinitializes the player as is needed when tuning to a new DVB channel. Currently triggered when dvbin-prog is written to, i.e. when the user explicity switches to a channel by name.
* command: fix bitrate rounding errorStefan Pöschel2019-09-261-2/+2
| | | | | | | | | | | | | When the (float) bitrate is returned, it is implicitely converted to an int64 value, merely discarding the fractional part. However the bitrate of a CBR track can vary a bit due to timestamp precision loss after clock conversion (this can affect MPEG-TS audio tracks). So a bitrate like 191999.999... results in 191999 when being returned - instead of 192000. To fix this, apply proper rounding, as already done for the "old" case. Hereby refactoring the "old" case to also use `llrint`.
* command: add expand-path to expand mpv pathsNicolas F2019-09-221-0/+12
| | | | | | | The question came up on how a client would figure out where screenshot-directory saved its screenshots if it contained mpv-specific expansions. This command should remedy the situation by providing a way for the client to ask mpv to do an expansion.
* command: add sub-start & sub-end propertiesStefano Pigozzi2019-09-221-0/+34
| | | | | These properties contain the current subtitle's start and end times. Can be useful to cut sample audio through the scripting interface.
* input: add keybind commandDudemanguy9112019-09-211-0/+17
|
* player: expose pixel aspect ratio, bitrate and rotation value on trackswnoun2019-09-211-0/+7
|
* command: add video-ad