summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* command, lua: add a way to share data between scriptswm42019-12-182-0/+55
| | | | | | | | | 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-172-24/+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.
* client API: remove some dead codewm42019-12-171-6/+0
| | | | | This was for the "suspend" API, which has been removed (turned into stubs) a long time ago.
* 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-162-21/+16
| | | | | | | | | 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.
* player: avoid underrun wakeup loopwm42019-12-162-1/+9
| | | | | | | | | | | | | | | | | | The VO underrun detection (just a weak heuristic) added in commit f26dfb flagged the underrun state every time it was checked, and since the check happened in every playloop iteration, this caused the playloop to wake up itself on every iteration. It burned an entire core while in this state. Fix this by flagging this condition only once (as it should be), and requiring that a frame is displayed to trigger it again. This makes it work similar as the audio underrun check. The bug report referenced below says --demuxer-thread=no avoided this. This is because the demuxer layer doesn't do proper underrun reporting if the reader thread is disabled. Fixes: #7259
* player: fix an outdated commentwm42019-12-141-2/+1
| | | | | The client API doesn't use input_ctx anymore, and the "wakeup" flag is gone (if it even existed at all).
* player: move point at which queued seeks are appliedwm42019-12-141-2/+3
| | | | | | | | | | | Do it after decoding etc., but before waiting for input. This seems to make more sense, because whether a queued seek can be applied depends on the playback state. So it sounds like a good idea to apply the seek first thing, but it's a bad idea to go to sleep if there's still a queued seek pending (that couldn't be processed earlier). Also add an empty line before mp_wait_events(); it doesn't really have to do with the filter bullshit.
* player: make repeated hr-seeks past EOF trigger EOF as expectedwm42019-12-142-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you have a normal file with audio and video, and keep "spamming" forward hr-seeks, the player just kept showing the last video frame instead of exiting or playing the next file. This started happening since commit 6bcda94cb. Although not a bug per se, it was odd, and very user-noticable. The main problem was that the pending seek command was processed before the EOF was "noticed". Processing the command reset everything, so the player did not terminate playback, but repeated the seek. This commit restores the old behavior. For one, it makes video return the correct status (video.c). The parameter is a bit ugly, but better than duplicating the logic or having another MPContext field. (As a minor detail, setting r=VD_EOF makes sure have_new_frame() returns true, rather than going through another iteration or whatever the hell will happen instead, which would clobber logical_eof.) Another thing is making the seek logic actually wait until the seek outcome has been determined if audio is also active. Audio needs to wait for video in order to get the video seek target position. (Which in turn is because hr-seek still "snaps" to video frames. You can't seek in between two frames, so audio can't just use the seek target, but always has to wait on the timestamp of the video frame. This has other disadvantages and is a misdesign, but not something I'll fix today.) In theory, this might make hr-seeks less responsive, because it needs to fully decode/filter the audio too, but in practice most time is spent on video, which had to be fully decoded before this change. (In general, hr-seek could probably just show a random frame when a queued hr-seek overrides the current hr-seek, which would probably lead to a better user experience, but that's out of scope.) Fixes: #7206
* player: cosmetically restructure a small functionwm42019-12-141-7/+11
| | | | | No actual functional changes. Just preparation for the next commit, to reduce its diff.
* player: add comment to clarify FFmpeg ABI handlingwm42019-12-131-0/+3
| | | | Don't patch it out.
* osc: set the wrap style for the title shown with window controlsPhilip Langdale2019-12-121-1/+1
| | | | | | I missed adding this when defining the style used for the video title in the window control bar. The default behaviour is to wrap, but we want to cut the title off when we run out of space.
* osc: use custom symbols for window controlsPhilip Langdale2019-12-111-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | I was recently informed that unicode has official symbols for window controls, and I put together a change to use them, which worked, as long as a suitable font was installed. However, it's not that hard to get a normal system that lacks an appropriate font, and libass wants to print warnings if the symbols aren't in the default font, which will almost always be true. So, I gave up and added the symbols to the custom osd font that we already have. This ensures they are always available, and that they are aligned consistently on all platforms. I took the symbols from the `symbola` font, as this has a suitable licence and the symbols look nice enough. Symbola Licence: Fonts are free for any use; they may be opened, edited, modified, regenerated, packaged and redistributed. Finally, as we now have access to an un-maximize symbol, I added logic to use it when the window is maximized.
* osc: explicitly re-init the osc on a change in border visibilityPhilip Langdale2019-12-091-0/+1
| | | | | | | | | | | | | | I had previously wondered whether to do this, but in my testing with x11 and wayland, the osc was being re-inited on a border toggle already so I didn't add it. However, on win32, things are different and there is no re-init when toggling borders. I belive this is because the active window size doesn't change in anyway, while on x11/wayland, toggling the border actually changes the window size - and that trigger a re-init. So, let's just be explicit and request a re-init when the border is toggled.
* console.lua: add this scriptJames Ross-Gowan2019-12-083-0/+705
| | | | | | | | | | | | | | | | | | | | | 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>
* lua: make later key bindings always have higher prioritywm42019-12-071-2/+13
| | | | | | | | | | | | | | | | | | | Later calls to mp.add_key_binding() should take priority over previous calls with the same key. Until now, the order was random (due to using table pairs() iteration order). Do this by simply sorting by a counter that is never reset. Since input.c also gives later bindings priority, this works out. Calling mp.remove_key_binding() on a newer binding makes an older still existing binding with the same key active again. New bindings override older ones, but do not overwrite them. I think these are good semantics for most use cases. (Note that the Lua code cannot determine whether two bindings use the same key. Keys are strings, and two different strings could refer to the same key. The code does not have access to input.c's key name normalization, so it cannot compare them.)
* 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
* player: loadfile overrides previous stop commandwm42019-12-061-1/+1
| | | | | | | | | | | | | | | | Both the "stop" and "loadfile" commands are asynchronous. "stop" starts terminating playback, which used to be done in the same playloop iteration, but now it may take longer, so a "loadfile" command can be received while this is going on. (Possible that it used to work if the second command was issued at least in the next playloop iteration.) Make the "loadfile" override the "stop" mode, so the next file will be played, instead of quitting or going into idle mode. Unlike the referenced bug report claims, this has nothing to do with IPC. Fixes: #7225
* osc: rework window control configuration to add auto modePhilip Langdale2019-12-041-17/+46
| | | | | | | | | | | | | | | | To aid in discoverability, and to address the most common case directly, I'm adding an 'auto' mode for the window controls. In this case, we will show the controls if there is no window border and hide them if there are borders. This also respects the option being toggled at runtime. To ensure that it works in the wayland case, I've also made sure that the wayland code explicitly forces the option to false if decoration support is missing. Based on feedback, I've split the config in two, with one option for whether controls are active, and one for alignment. These are new enough that we can get away with ignoring compatibility.
* osc: ensure that window control show/hide zone is handled dynamicallyPhilip Langdale2019-12-041-6/+6
| | | | | | | | | | | | | | | | | | | As preparation for adding the auto mode for window controls, we need to make sure that the controls can be successfully toggled at runtime, rather than only being able to configure them once at startup. Right now, there is a problem with the handling of the show/hide zone for the window controls. The previous fix for #7212 was to avoid registering the input mapping for the window control show/hide zone. If there is no input mapping, then there is no input, and the zone is a no-op, even if it exists. But this only happens at startup. After that point, the input mapping doesn't exist and cannot be turned on. In this change, I'm switching the approach; we now go back to always registering the input mapping, and instead, we zero out the show/hide zone if window controls are disabled, and set its size appropriately if they are enabled.
* options: move cursor autohiding opts to mp_vo_optsdudemanguy2019-12-042-5/+5
| | | | | | 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.
* player: don't apply weird timestamp tolerance on backstepwm42019-12-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Hr-seek has some sort of tolerance against timestamps, where it allows for up to 5ms deviation. This means it can work only for videos with up to 200 FPS framerate. There were complains about how it doesn't work with videos beyond some high fps. (1000 was mentioned, although that sounds more like it's about the limit that .mkv has.) I suspect this is because otherwise, it might be hard to hit a timestamp with --start, which specifies timestamps as integer, and thus will most likely never represent a timestamp exactly. Another part of the problem is that mpv uses 64 bit floats for timestamps, so fractional parts are never represented exactly. (Both the "tolerance" and using floats for timestamps were things introduced before my time.) Anyway, in the backstep case, we can be relatively sure that the timestamp will be exact (as in, the same unmodified value that was returned by the filter chain), so we can make an exception for that, in order to fix backstep. Untested. (For that you have users.) May help with #7208.
* osc: don't show error if windowcontrols=yesPhilip Langdale2019-12-021-1/+2
| | | | | | | | I always intended for this to be accepted and mean "right" but I made it show an error for any value that's not explicitly recognised (while considering all unrecognised values to mean "right"). So let's explicitly recognise "yes".
* osc: don't always set window control keybindingsDudemanguy2019-12-011-4/+6
| | | | | Only set the window control keybindings if the window control option is actually enabled. Fixes #7212.
* 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.
* osc: ensure the window-controls mouse area is initially zero sizedPhilip Langdale2019-11-301-0/+1
| | | | | | This is necessary to avoid breaking input behaviour in the 'idle' state when not playing a video. Otherwise, the mouse area starts off covering the whole window and blocks normal input.
* js: mp.add_key_binding: allow false-y name (match 311cc5b)Avi Halachmi (:avih)2019-11-301-1/+3
| | | | | This is in addition to the allowed omission of name and/or flags (as documented).
* lua: unbreak mp.add_key_binding(key, fn)Avi Halachmi (:avih)2019-11-301-1/+1
| | | | | | | Commit 311cc5b6 added the ability use flags while omitting name, but broke the case where both name and flags are omitted. Now omitting either name or flags or both works as documented.
* osc: fix typo wsc_geo -> wc_geoPhilip Langdale2019-11-301-1/+1
|
* osc: apply boxvideo margins to the window controlsPhilip Langdale2019-11-301-0/+3
| | | | | | It seems logical to account for the window controls if `boxvideo` is in use (which has the effect of reducing the size of the video so that the osc is not covering the video).
* 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.)
* osc: fix operation when window controls are disabledwm42019-11-291-2/+4
| | | | | It seems this area is simply not defined when window controls are disabled, so ipairs() will crash on it.
* osc: handle deadzone and barmargin for window controlsPhilip Langdale2019-11-291-6/+28
| | | | | | | | | | | | | | | | I missed these due to only testing with my personal osc config. The deadzone needs to be correctly handled for the window controls, or they will fail to appear when the mouse is close to or over them. In the process of doing that, I realised that the controls should respect the barmargin, if set. This is because the controls should remain aligned when layout=topbar and as the control bar is top aligned, it should be equally affected if the user needs to set the barmargin. I also fixed a mistake in trying to the use the mpv-osd-symbols font for the window controls.
* 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-295-19/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* options: get rid of GLOBAL_CONFIG hackwm42019-11-291-2/+1
| | | | | | | 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: use m_option_equal()wm42019-11-291-16/+1
| | | | No more converting the option values to a string to compare it.
* osc: implement pseudo client side decorations via OSCPhilip Langdale2019-11-291-7/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, if window decorations are not present, either because they were disabled, or because the platform doesn't support them (eg: gnome-shell on wayland), there are no window controls, meaning it is not possible to minimize/maximize/close a window without knowing keyboard shortcuts. While you can imagine various ways of offering client side decorations, it is attractive to consider using OSC because that is functionality that we already have. The main work here is defining a separate input area from the main OSC box with its own buttons, etc. While we could probably handle auto-detection based on whether decorations are present or not, it's manually controlled for now. The window control logic is mostly disconnected from the OSC itself, except in the case of the `topbar` layout, where there has to be coordination so that the controls don't get drawn on top of each other. I had to do fine-positioning of the buttons based on the font on my system, so don't be surprised if it looks wrong elsewhere. You could also argue that window controls should be unscaled, even if the main OSC box is scaled, but I've not tried to do this.
* 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-254-53/+3
| | | | | | | | 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-252-79/+23
| | | | | | | | | | | | | | | | | | 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
| | | |