summaryrefslogtreecommitdiffstats
path: root/player/command.c
Commit message (Collapse)AuthorAgeFilesLines
* 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-add/video-remove/video-reload commandsPaul B Mahol2019-09-211-0/+21
|
* command: drop removed cache properties from cache update eventswm42019-09-201-2/+2
| | | | These did nothing anymore, maybe made it slightly slower.
* command: make vf-metadata/af-metadata somewhat observablewm42019-09-191-1/+1
| | | | | | | | | | | Until now they weren't observable and never reported any updates. Apply a shitty hack to make them mostly-observable. It relies on the "idle" event, which is basically triggered on every frame displayed, or similar. This can lead to property change notifications not being sent quickly enough. The cleaner solution would be adding a notification mechanisms from filters, but I'm too lazy for that.
* command: make vf-metadata/af-metadata not query metadata twicewm42019-09-191-7/+13
| | | | | | | | | | | For simplicity, these properties usually query the metadata from the filter twice, even if it's not technically needed at all. The reason for this is mostly the horrible (and legacy) sub-path access (which is why tag_property() is so complex). But for simple cases, we can easily avoid double querying, so do that. The benefit is performance (well, won't matter), and supporting filters that reset information on query (for later).
* command: don't add deprecated CLI aliases to property listwm42019-09-191-0/+12
| | | | | | | A dumb thing that the cursed property-option bridge accidentally did. Normal deprecated options on the other hand are fine in the property list, because they're wanted for compatibility.
* command, demux: add AB-loop keyframe cache align commandwm42019-09-191-0/+22
| | | | | | | | | | | | | | | Helper for the ab-loop-dump-cache command, see manpage additions. This is kind of shit. Not only is this a very "special" feature, but it also vomits more messy code into the big and already bloated demux.c, and the implementation is sort of duplicated with the dump-cache code. (Except it's different.) In addition, the results sort of depend what a video player would do with the dump-cache output, or what the user wants (for example, a user might be more interested in the range of output audio, instead of the video). But hey, I don't actually need to justify it. I'm only justifying it for fun.
* command: shuffle cache-dump start messagewm42019-09-191-2/+2
| | | | This is better?
* demux, command: add a third stream recording mechanismwm42019-09-191-1/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That's right, and it's probably not the end of it. I'll just claim that I have no idea how to create a proper user interface for this, so I'm creating multiple partially-orthogonal, of which some may work better in each of its special use cases. Until now, there was --record-file. You get relatively good control about what is muxed, and it can use the cache. But it sucks that it's bound to playback. If you pause while it's set, muxing stops. If you seek while it's set, the output will be sort-of trashed, and that's by design. Then --stream-record was added. This is a bit better (especially for live streams), but you can't really control well when muxing stops or ends. In particular, it can't use the cache (it just dumps whatever the underlying demuxer returns). Today, the idea is that the user should just be able to select a time range to dump to a file, and it should not affected by the user seeking around in the cache. In addition, the stream may still be running, so there's some need to continue dumping, even if it's redundant to --stream-record. One notable thing is that it uses the async command shit. Not sure whether this is a good idea. Maybe not, but whatever. Also, a user can always use the "async" prefix to pretend it doesn't. Much of this was barely tested (especially the reinterleaving crap), let's just hope it mostly works. I'm sure you can tolerate the one or other crash?
* screenshot: move message showing to common codewm42019-09-191-0/+18
| | | | | | | | | | | | | | The screenshot command has this weird behavior that it shows messages both on terminal and OSD by default, but that a command prefix can be used to disable the OSD message. Move this mechanism to