summaryrefslogtreecommitdiffstats
path: root/player/command.c
Commit message (Collapse)AuthorAgeFilesLines
* options: split m_config.c/hwm42020-03-131-1/+1
| | | | | | | | | | | | | | | | | Move the "old" mostly command line parsing and option management related code to m_config_frontend.c/h. Move the the code that enables other part of the player to access options to m_config_core.c/h. "frontend" is out of lack of creativity for a better name. Unfortunately, the separation isn't quite clean yet. m_config_frontend.c still references some m_config_core.c implementation details, and m_config_new() is even left in m_config_core.c for now. There some odd functions that should be removed as well (marked as "Bad functions"). Fixing these things requires more changes and will be done separately. struct m_config is left with the current name to reduce diff noise. Also, since there are a _lot_ source files that include m_config.h, add a replacement m_config.h that "redirects" to m_config_core.h.
* command: add libass-version propertywm42020-03-081-0/+15
| | | | A bit of a mess with that ifdeffery, but fuck it.
* command: remove legacy hook APIwm42020-03-061-61/+8
| | | | | Hopefully nothing uses this. (I know one exception, but, well, what can I do.)
* command: extend osd-overlay command with bounds reportingwm42020-03-061-0/+17
| | | | | | | | | | | | | | | | | | | | This is more or less a minimal hack to make _some_ text measurement functionality available to scripts. Since libass does not support such a thing, this simply uses the bounding box of the rendered text. This is far from ideal. Problems include: - using a bitmap bounding box - additional memory waste and/or flushing caches - dependency on window size - odd small deviations with different window sizes (run osd-test.lua and resize the window after each timer update; the bounding boxes aren't adjusted in an overly useful way) - inability to query the size _after_ actual rendering But I guess it's a start. Since I'm aware that it's crap, add a threat to the manpage that this may be changed/removed again. For now, I'm interested whether anyone will have use for it in its current form, as it's an often requested feature.
* options: make decoder options local to decoder wrapperwm42020-03-011-2/+2
| | | | | | | | | | | | | | | Instead of having f_decoder_wrapper create its own copy of the entire mpv option tree, create a struct local to that file and move all used options to there. movie_aspect is used by the "video-aspect" deprecated property code. I think it's probably better not to remove the property yet, but fortunately it's easy to work around without needing special handling for this option or so. correct_pts is used to prevent use of hr-seek in playloop.c. Ignore that, if you use --no-correct-pts you're asking for trouble anyway. This is the only behavior change.
* f_decoder_wrapper: replace most public fields with setters/getterswm42020-02-291-8/+13
| | | | | | | | | | | | | | | | | | | I may (optionally) move decoding to a separate thread in a future change. It's a bit attractive to move the entire decoder wrapper to there, so if the demuxer has a new packet, it doesn't have to wake up the main thread, and can directly wake up the decoder. (Although that's bullshit, since there's a queue in between, and libavcodec's multi-threaded decoding plays cross-threads ping pong with packets anyway. On the other hand, the main thread would still have to shuffle the packets around, so whatever, just seems like better design.) As preparation, there shouldn't be any mutable state exposed by the wrapper. But there's still a large number of corner-caseish crap, so just use setters/getters for them. This recorder thing will inherently not work, so it'll have to be disabled if threads are used. This is a bit painful, but probably still the right thing. Like speculatively pulling teeth.
* player: set playback_pts in hr-seek past EOF casewm42020-02-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Hr-seek past the last frame instantly enters EOF, which means handle_playback_time() will not set playback_pts to the video PTS (as all video frames are skipped), which leads to the playback time being taken from the last seek target. This results in confusing behavior, especially since the seek time will be clipped to the file duration for display, but not for further relative seeks. Obviously, the time should be set to the last video frame, so use the last video frame as fallback if both audio and video have ended. Also, since the same problem exists with audio-only playback, add a fallback for audio PTS too. We don't know which was the "last" fragment of media played (to decide whether to use the audio or video PTS as the fallback), but it doesn't matter since the maximum works. This could lead to some undesired effects. In particular the audio PTS is basically a bad guess, and is for example not clipped against --end. (But the ridiculous way audio syncing and clamping currently works, I'm not going to touch that shit unless I rewrite it completely.) The cover art case is slightly broken: using --keep-open with keyframe seeks will result in 0 as playback PTS (the video PTS). OK, who cares, it got late. Also casually get rid of last_vo_pts, since that barely made any sense at all. Fixes: #7487
* command: remove unintended newlinewm42020-02-271-1/+1
| | | | This just made it print a blank line.
* ta: remove two pointless wrapperswm42020-02-231-1/+1
|
* sub: make filter_sdh a "proper" filter, allow runtime changeswm42020-02-161-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* player: add ab-loop-count option/propertywm42020-02-081-1/+2
| | | | | | | | | | | | 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
* 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
| | | | | | | | |