summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* client API: remove comment about error statuswm42019-12-191-1/+0
| | | | | | mpv_event_property (for property observation) actually never sets an error status. You cannot distinguish between unavailable properties and properties which returned an error. Not sure if it ever did.
* manpage: lua: mention what happens on unavailable propertieswm42019-12-191-0/+4
| | | | Kind of as big one if the user unexpectedly gets nil instead of a value.
* client API: rewrite property observation (again)wm42019-12-193-137/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I intend to rewrite this code approximately every 2 months. Last time, I did this in commit d66eb93e5d4 (and 065c307e8e7 and b2006eeb74f). It was intended to remove the roundabout synchronous thread "ping pong" when observing properties. At first, the original async. code was replaced with some nice mostly synchronous code. But then an async. code path had to be added for vo_libmpv, and finally the sync. code was dropped because it broke in other obscure cases (like the Objective-C Cocoa backend). Try again. This time, update properties entirely on the main thread. Updates get batched out on every playloop iteration. (At first I wanted it to make it every time the player goes to sleep, but that might starve API clients if the playloop get saturated.) One nice thing is that clients only get woken up once all changed events have been sent, which might reduce overhead. While this sounds simple, it's not. The main problem is that reading properties must not block the client API, i.e. no client API locks can be held while reading the property. Maybe eventually we can avoid this requirement, but currently it's just a fact. This means we have to iterate over all clients and then over all properties (of each client), all while releasing all locks when updating a property. Solve this by rechecking on each iteration whether the list changed, and if so, aborting the iteration and redo it "next time". High risk change, expect bugs such as crashes and missing property updates.
* options: fix incorrect deprecation messagewm42019-12-191-2/+4
| | | | | Passing multiple items to a key/value option is OK, only for -add suffixed options it's deprecated.
* options: fix UB/crash in key/values parserwm42019-12-181-2/+2
| | | | | | | | keyvalue_list_find_key() was called on a "partially" constructed list, because the terminating NULL was added only later. Didn't I say this code is cursed? Fixes: #7273
* console: adjust position to OSCwm42019-12-181-1/+17
| | | | See previous commit.
* osc: make margins availablewm42019-12-181-1/+23
| | | | | | | | | This is for console.lua (see next commit). The idea is that console.lua can adjust its offset to the bottom of the window by the height of the OSC. If the OSC is not set to permanently visible, export no margins, because it would look weird to move the console depending on the mouse movement.
* command, lua: add a way to share data between scriptswm42019-12-183-0/+77
| | | | | | | | | 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.
* x11: fix X property out of bounds memory readswm42019-12-181-2/+2
| | | | | | | | | | | | | | | | | | | | The size overflow check was inverted: instead of allowing reading only the first dst_size bytes of the property, it allowed copying past the property buffer (as returned by xlib). xlib doesn't return the size of the buffer in bytes, so it has to be computed and checked manually. Wouldn't it be great if C allowed me to write the overflow check in a readable way, so it doesn't trick me into writing dumb security bugs? Relying on X security is even dumber than creating a X security bug, though, so this was not a real problem. But I found that one specific call tried to read more than what the property provided, so reduce that. Also, len*ib obviously can't overflow, so there's an additional layer of dumb to this whole thing. While we're at dumb things, why the hell does xlib use "long" for 32 bit types. It's a god damn pain.
* options: deprecate -del for list optionswm42019-12-185-6/+14
| | | | | | I never liked that these used integer indexes. -remove should have existed from the start. This deprecation is yet another empty threat, though.
* options: fix filter list comparison (again)wm42019-12-183-19/+18
| | | | | | | | | | | This was completely broken: it compared the first item of the filter list only. Apparently I forgot that this is a list. This probably broke aspects of runtime filter changing probably since commit b16cea750f52. Fix this, and remove some redundant code from obj_settings_equals(). Which is not the same as m_obj_settings_equal(), so rename it to make confusing them harder. (obj_setting_match() has these very weird label semantics that should probably just be killed. Or not.)
* options: add -remove action to list optionswm42019-12-184-12/+60
| | | | | | Actually I wanted this for key/value lists only, but add it to the others for consistency too. (For vf/af it barely makes even sense, but anyway.)
* options: make keys in key/value lists uniquewm42019-12-182-0/+30
| | | | | | | | | | | | | | I don't even know anymore whether this was intended or not. Certain use cases for the "-o" options might require this. These options are for passing general FFmpeg options. These are translated to av_opt_set() calls, which may or may not accumulate the option values on multiple calls with the same option name (how should I know?). Anyway, it seems crazy to allow non-unique keys, so make them unique. The ad-hoc nature of the option code makes this wonderfully complicated (when I wrote that this code is cursed, I meant it). In combination with lazy testing, it probably means there are lots of bugs here.
* options: increase consistency between list options and document themwm42019-12-186-33/+145
| | | | | | | | | | | | | | | | | | | | Whenever I deal with this, I have to look at the code to make sense of this. And beyond that, there are some strange inconsistencies. (I think this code is cursed. It always was, and maybe always will be.) Although the manpage claimed that using multiple items for -add etc. is deprecated, string list options didn't warn against it. So add the warning, and add something in the changelog (even though nobody will ever read this). The manpage mentioned --vf-append, but this didn't even exist. So add it, I guess. We encourage using -append for the other option types, so for consistency, it should work on filter options. (And I already tricked me into believing it existed when I mentioned it in the manpage.) Make the "operations" table separate for all option types, and mention the option type on every single of the top-level list options.
* vd_lavc: add gross workaround for nvdec/libavcodec broken API issuewm42019-12-181-4/+10
| | | | | | | | | | | | | | | | | libavcodec's nvdec wrapper can return invalid frames, that do not have any data fields set. This is not allowed by the API, but why would they follow their own API? Add a workaround to specifically detect this situation. In practice, this should fall back to software decoding if it happens too often in a row. (But single errors are still tolerated, because I don't know why.) Untested due to lack of hardware from the regrettable graphics company. Better do this here than deal with the moronic project we unfortunately depend on. See: #7185
* f_lavfi: add gross workaround for af_dynaudnorm bugwm42019-12-181-0/+35
| | | | | | | | | | | | | Better do this here than deal with the moronic project we unfortunately depend on. The workaround is generic; unknown whether it works correctly with multi-input/output filters or filter graphs. It assumes that if all inputs are EOF, and all outputs are EAGAIN, the bug happened. This is pretty tricky, because anything could happen. Any time some form of progress is made, the got_eagain state needs to be reset, because the filter pad's state could have changed.
* cocoa-cb: report fullscreen state for legacy fullscreender richter2019-12-171-0/+2
| | | | | report the fs screen state when the fullscreen is externally triggered for the legacy fullscreen.
* command, vo: remove old option change notification mechanismswm42019-12-174-39/+3
| | | | | | | 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-172-19/+8
| | | | | | | 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.
* video/w32_common: follow updates to the border option instead of VOCTRL_BORDERJan Ekström2019-12-181-4/+3
|
* video/w32_common: follow updates to the ontop option instead of VOCTRL_ONTOPJan Ekström2019-12-181-3/+2
|
* video/w32_common: move minimized state signaling to where it happensJan Ekström2019-12-181-3/+3
| | | | | WM_SIZE is the message we receive from which we can infer if we got minimized or not.
* video/w32_common: switch full screening to options cacheJan Ekström2019-12-181-9/+22
| | | | | | | | | | | | * Instead of following VOCTRL_FULLSCREEN, check for option changes. * Instead of signaling VO_EVENT_FULLSCREEN_STATE, update the cached option structure and have it propagated to the origin. Additionally, gets rid of all the straight usage of the VO options structure. Done in a similar style to the Wayland common file, where in case of reading the value, the "payload" from cache is utilized.
* demux_edl: fix reusing segment source fileswm42019-12-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | EDL files can have multiple segments taken from the same source file. In this case, the source file is supposed to be opened only once. This stopped working, and it created a new demuxer instance for every single segment entry. This made it slow and made it use much more memory than needed. This was because it tried to iterate over the array of source files, but the array count (num_parts) was only set to a non-0 value later. Fix this by maintaining the count correctly. In addition, the actual code for checking whether a source can be reused (in open_source()) regressed and stopped working correctly. d->stream could be NULL. Use demuxer.filename instead; I'm not entirely sure whether this is always correct, but fortunately we have a distributed almost-AI driven test suite (called "users") which will probably find and report such cases. Probably broke with commit a09396ee60 or something close, but didn't check closer. Fixes: #7267
* x11: fix --hidpi-window-scale=no on hidpi screenswm42019-12-161-1/+1
| | | | | | | | | | In this combination, the [current-]window-scale properties still incorrectly applied scaling. For some reason, vo_calc_window_geometry2() handled this option (basically ignored the dpi_scale parameter passed to it), but since the DPI compensation for window-scale is implemented in x11_common.c, we need to check and honor this option here too. (What a mess.)
* msg: fix "terminal-default" logging modewm42019-12-161-2/+5
| | | | | | | | | | | | | | | | | | | | | | | console.lua uses "terminal-default" logging, which is supposed to return all messages logged to the terminal to the API. Internally, this is translated to MP_LOG_BUFFER_MSGL_TERM, which is MSGL_MAX+1, because it's not an actual log level (blame C for not having proper sum types or something). Unfortunately, this unintentionally raised the internal log level to MSGL_MAX+1. It still functioned as intended, because log messages were simply filtered at a "later" point. But it led to every message being formatted even if not needed. More importantly, it made mp_msg_test() pointless (code calls this to avoid logging in "expensive" cases and if the messages would just get discarded). Also, this broke libplacebo logging, because the code to map the log messages did not expect a level higher than MSGL_MAX (mp_msg_level() returned MSGL_MAX+1 too). Fix this by not letting the dummy level value be used as log level. Messages at terminal log level will always make it to the inner log message dispatcher function (i.e. mp_msg_va() will call write_msg_to_buffers()), so log buffers which use the dummy log level don't need to adjust the actual log level at all.
* command: change "window-scale" property behaviorwm42019-12-164-25/+34
| | | | | | | | | 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.
* x11: scale window-scale by DPIwm42019-12-161-6/+8
| | | | | | | | | | | | | | | | | "window-scale" is 1.0 by default; however, x11 implicitly set that to 2.0 on hidpi screens. This made the default 2.0, which was inconsistent with the option. The "window-scale" property jumped from 1.0 to 2.0 when a window was created. Avoid this by factoring the DPI into the window-scale. This makes the UNFS_WINDOW_SIZE return a virtual size; since this value is used for the window-scale property only, this is fine and has no further consequences. (Originally, this was possibly meant to be used for other purposes, but I'm perfectly fine with redoing this again should that ever happen.) This changes user-visible behavior, and it's as if setting window-scale multiplies its argument by 2 suddenly. Hopefully no user will get angry.
* command: remove unnecessary mute property implementationwm42019-12-161-15/+0
| | | | | This only added the CONSTRICTED_TYPE thing, but it works correctly without.
* m_option: clamp integer before adding a valuewm42019-12-161-0/+2
| | | | | | | | | | | | | | This is for the previous commit, and should affect behavior with the special M_PROPERTY_GET_CONSTRICTED_TYPE mechanism only. The effect is that cycling the "edition" property, if the option is set to "auto", will change to the second edition instead of the first. Normally, option values must always be within their range, so this should not affect anything else. M_PROPERTY_GET_CONSTRICTED_TYPE is sort-of fine with this kind of behavior. If this affects any other M_PROPERTY_GET_CONSTRICTED_TYPE users neqatively, I will revert the change.
* command: change "edition" property behaviorwm42019-12-163-15/+36
| | | | | | | | | 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
* build: downgrade EGL requirement from 1.5 to 1.4wm42019-12-163-6/+6
| | | | | | | | | | With the previous commit, there's no need for 1.5 anymore. And in fact, it's just too dangerous to rely on 1.5 because of all the EGL craziness. For example, you might get a 1.5 EGL system library, but a driver might still give you 1.4 at runtime. If you assume that you can call 1.5 functions, you will probably get random crashes in this case. What a cursed API. (The same problem exists with EGL 1.3, but fortunately nothing seems to use that anymore. We can just ignore that problem.)
* vo_gpu: opengl: make it work with EGL 1.4wm42019-12-164-4/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This tries to deal with the crazy EGL situation. The summary is: - using eglGetDisplay() with multiple windowing platforms doesn't really work, but Mesa had an awful hack for it - this hack can be disabled at build time, and some distros sometimes accidentally or intentionally do so - Mesa will probably eventually disable it by default - we switched to eglGetPlatformDisplay(), but this requires EGL 1.5 - the very regrettable graphics company (also known as Nvidia) ships drivers (for old hardware I think) that are EGL 1.4 only - that means even though we "require" EGL 1.5 and link against it, the runtime EGL may be 1.4 - trying to run mpv there crashes in the dynamic linker - so we have to go through some more awful compatibility hacks This commit tries to do it "properly", but using EGL 1.4 as base. The plaform selection mechanism is a messy extension there, which got elevated to core API in 1.5 (but OF COURSE in incompatible ways). I'm not sure whether the EGL 1.5 code path (by parsing the EGL_VERSION) is really needed, but if you ask me, it feels slightly saner not to rely on an EGL 1.4 kludge forever. But maybe this is just an instance of self-harm, since they will most likely never drop or not provide this API. Also, unlike before, we actually check the extension string for the individual platform extensions, because who knows, some EGL implementations might curse us if we pass unknown platform parameters. (But actually, the more I think about this, the more bullshit it is.) X11 and Wayland were the only ones trying to call eglGetPlatformDisplay, so they're the only ones which are adjusted in this commit. Unfortunately, correct function of this commit is unconfirmed. It's possible that it crashes with the old drivers mentioned above. Why didn't they solve it like this: struct native_display { int platform_type; void *native_display; }; Could have kept eglGetDisplay() without all the obnoxious extension BS.
* vd_lavc: fix broken assert()wm42019-12-151-1/+2
| | | | | | | | | | | | | | | | | | | | | This assert() sometimes triggered (and still triggers) with lavc API bugs. It tries to check that at least 1 plane is set to a non-NULL value. Obviously, a valid frame returned by successful decoding should never have it. The problem is that some hwdecs use integer surface IDs cast to a pointer. Recently, it happened that newer Intel drivers started using surface ID 0 under certain circumstances (for unknown reasons), which triggers this assert. Just get rid of it. For the sake of #7185, add an assert() specifically for nvdec. That failure needs to be further analyzed, is probably a FFmpeg bug, and without this assert() would just crash somewhere further down the video chain. Fixes: #7261
* vo_gpu: x11egl: log EGL config IDwm42019-12-151-2/+6
| | | | Somewhat useful for debugging.
* vd_lavc: simplify decode return error checkingwm42019-12-151-11/+16
| | | | | | | | | | | | This code checked AVFrame.buf[0] instead of the decode return code to see whether a frame was decoded. This is sort of suspicious; while I think that the lavc API actually guarantees it, it's not intuitive anyway. In addition, the code was unnecessarily roundabout. Replace it with a proper error code check. Remove the other error return (that was, or should have been, redundant before). The no-frame path is now cleanly separated. Add an assert on the frame-returned path; if this fails, lavc violated its own API.
* mac: replace old event tap for media key support with MediaPlayerder richter2019-12-1510-133/+197
| | | | | | | | | | | | | | | the old event tap has several problems, like no proper priority support or having to set accessibility permissions for mpv or the terminal. it is now replaced by the new MediaPlayer which has proper priority support and isn't as greedy as previously. this only includes Media Key support and not any of the other features included in the MediaPlayer framework, like proper Now Playing data (only set dummy data for now). this is only available on macOS 10.12.2 and higher. also removes some unnecessary redefines. Fixes #6389
* mac: remove Apple Remote supportder richter2019-12-1518-2580/+9
| | | | | | the Apple Remote has long been deprecated and abandoned by Apple. current macs don't come with support for it anymore. support might be re-added with the next commit.
* cocoa-cb: fix freeing of macos_opts config groupder richter2019-12-151-5/+5
| | | | | | | | | using the MPContext as ta parent was a bad idea and shouldn't be done in any circumstances there because it only supposed to be for internal usage. this had the undesired effect that the options group was freed but still used since the MPContext is freed afterwards. instead manually free options group.
* cocoa-cb: update and add more options to use new options handlingder richter2019-12-153-10/+46
| | | | | this updates and add the maximized, minimized, keepaspect and ontop options to use the new options handling
* cocoa-cb: use m_config_cache and new VOCTRL for option handlingder richter2019-12-156-42/+87
| | | | | | | | this removes the direct access of the mp_vo_opts stuct via the vo struct and replaces it with the m_config_cache usage. this updates the fullscreen and window-minimized property via m_config_cache_write_opt instead of the old mechanism via VOCTRL and event flagging. also use the new VOCTRL_VO_OPTS_CHANGED event for fullscreen and border changes.
* DOCS/contribute.md: fix a typowm42019-12-151-1/+1
|
* DOCS/contribute.md: should -> mustwm42019-12-151-8/+8
| | | | | | | | | | People somehow think "should" makes things optional, even though the wording was merely trying to account for the exception of the rule. I guess this means programming documents should sound like we're running a police state (which is also the ultimate outcome of all technological development, if you weren't aware). See: #7248
* zsh completion: fix handling of aliases that are listed without --Philip Sequeira2019-12-151-2/+2
| | | | | | Pretty sure they used to all have --, but I guess it was changed at some point. More incentive to do this completion stuff in a more structured way.
* zsh completion: use actual POSIX-compatible regex for whitespacePhilip Sequeira2019-12-151-5/+5
| | | | | | | | | | | | | | \s and \S aren't actually part of the spec, but it seems glibc supports them anyway so I didn't notice when originally testing. This fixes the script on Apple's libc and probably others that adhere more closely to the spec. The most direct replacement for \s would have been [[:space:]], but we only expect to see spaces and tabs, so might as well just do that. Also could have used [[:blank:]], which is basically a locale-aware version of [ \t], but mpv isn't going to output anything but ASCII spaces and tabs, so let's avoid unnecessary complexity and stick with the ASCII literals.
* zsh completion: actually make pcre optionalPhilip Sequeira2019-12-151-7/+6
| |