summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* debug stuffstream_debug_stuffwm42020-02-122-2/+20
|
* sws_utils: use zimg by default if availablewm42020-02-123-7/+6
| | | | | This seems stable enough to use. Change the default, and remove it from the sw-fast profile.
* zimg: correct output to odd (chroma un-aligned) sizeswm42020-02-121-10/+18
| | | | | | | | | | As suggested by the zimg author: active_region is not supported on outputs (and the API returns an error), so instead scale to the "full" surface, but adjust the source rectangle such that the cropped output image happens to cover the correct region. Does this even work? Since Balmer Peak doesn't work, I can't really say, but it seems to look correct.
* zimg: fix typos in a commentwm42020-02-121-3/+2
| | | | | | Also remove the "o" case, which was never implemented (probably was an idea to output alpha formats, now obsoleted by zimg's full alpha support).
* vo_drm, wo_wlshm: mention that it's software scalingwm42020-02-112-2/+2
| | | | (But does anyone even read --vo=help output?)
* vo_x11: don't call X11 "crap"wm42020-02-111-1/+1
| | | | | | X11 is in fact beautiful and superior to Wayland. Instead, just state what the problem is in most cases: software scaling. (We have accelerated X11 rendering in vo_gpu and others.)
* zimg: add pal8 unpackerwm42020-02-101-0/+39
| | | | Some pngs are paletted, so this is vaguely interesting.
* img_format: add alias for ffmpeg pal8 formatwm42020-02-102-0/+4
| | | | For the next commit.
* manpage: add some blabla about zimg speed vs. libswscalewm42020-02-101-1/+10
| | | | | Of course nobody will read this. I'm just putting it there so I can blame users, who run into problems, for not having read it.
* zimg: rename zplanes fieldwm42020-02-101-4/+4
| | | | | | | | | This was a confusing name, because 1. there's also a z_planes[] field, and 2. it was not specific to zimg indexes. Possibly there used to be an idea involved about supporting alpha to non-alpha formats by discarding the alpha plane, but zimg does this now (and zimg will correctly blend the alpha component too).
* zimg: support gray/alpha conversionwm42020-02-101-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | The special thing about this format is 1. mpv assigns the component ID 4 to alpha, and component IDs 2 and 3 are not present, which causes some messy details. 2. zimg always wants the alpha plane as plane 3, and plane 1 and 2 are not present, while FFmpeg/mpv put the alpha plane as plane 1. In theory, 2. could be avoided, since FFmpeg actually doesn't have a any 2 plane formats (alpha is either packed, or plane 3). But having to skip "empty" planes would break expectations. zplanes is not equivalent to the mpv plane count (actually it was always used this way), while zimg does not really have a plane count, but does, in this case, only use plane 0 and 3, while 2 and 3 are unused and unset. z_planes[] (not zplanes) is now always valid for all 4 array entries (because it uses zimg indexes), but a -1 entry means it's an unused plane. I wonder if these conventions taken by mpv/zimg are not just causing extra work. Maybe component IDs should just be indexes by the "natural" order (e.g. R-G-B-A, Y-U-V-A, Y-A), and alpha should be represented as a field that specifies the component ID for it, or just strictly assume that 2/4 component formats always use the last component for alpha.
* zimg: fix some confusion about plane permutationwm42020-02-101-4/+9
| | | | | | | | | | | | | We reorder the planes between mpv and zimg conventions. It turns out the code still confused when which convention was used. So the way it actually works is that the _only_ place where zimg order is used is the zimg_image_buffer.plane[] array. plane_aligned[] and zmask[] were accessed incorrectly, although I guess it rarely had a reason to fail (plane reordering is mostly for RGB, which has planes of all the same size). Adjust some comments accordingly too.
* img_format: add gray/alpha planar formatswm42020-02-103-2/+88
| | | | | | | | | | | | The zimg wrapper "needs" these formats as intermediary when repacking the normal gray/alpha packed format. The packed format is used by the png decoder and encoder, and is thus interesting. Unfortunately, mpv-only formats are a mess right now, because all the existing code is focused around using the FFmpeg metadata for pixel formats. This should be improved, but not now, so make the mess worse. This commit doesn't add support for it to the zimg wrapper yet.
* zimg: add alpha supportwm42020-02-092-18/+69
| | | | | | | | | | | libzimg recently added direct alpha support and new API for it. (The API change is rather minimal, and it turns out we can easily support old and new zimg versions.) This does not support _all_ alpha formats. For example, gray + alpha is not supported yet, because my stupid design in the zimg wrapper would require a planar gray + alpha format, while ffmpeg provides only a packed one.
* vo: fix typo in commentwm42020-02-091-1/+1
|
* vf_format: add w, h parameterswm42020-02-092-3/+15
| | | | Yes, this thing became vf_scale through the back door.
* sub: enhance SDH filteringDan Oscarsson2020-02-091-0/+8
| | | | | It is not uncommon with a speaker label with [xxxx] inside. They should also be filtered out.
* github: fix a typo in the contact links infoder richter2020-02-091-2/+2
|
* github: ask users to first reproduce the issue with --no-configder richter2020-02-094-0/+12
|
* mac: always include the macOS config when cocoa is availableder richter2020-02-091-1/+1
| | | | | | | | | | the macOS config was only used in cocoa-cb before and only included when it was available. since this config is meant for general macOS options and backend independent options we include it when cocoa is available. one of the options is already used in the old cocoa backend, which broke using it when build without swift or cocoa-cb support. Fixes #7449
* bash completion: complete ao/af/vo/vf optionsPhilip Langdale2020-02-081-1/+1
| | | | | I didn't handle these originally, but it turns out that they can be handled with the samel logic as Choice options.
* bash completion: Cache the options listPhilip Langdale2020-02-081-8/+11
| | | | | | The bash completion seems to be working decently at this point, so I feel comfortable caching the options output to improve the performance of the completion.
* sub: fix SDH filtering after changeDan Oscarsson2020-02-081-1/+1
| | | | | | | | The change, in an earlier commit, in format for ass to handle results in a different number of fields to skip. Correct that so SDH filtering works. Should fix issue #7188
* player: add ab-loop-count option/propertywm42020-02-086-1/+21
| | | | | | | | | | | | 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
* DOCS/interface-changes.rst: mention it's for incompatible changeswm42020-02-081-1/+3
| | | | | | This is not really a changelog, but rather a list of potentially breaking changes API- and normal users should be aware of, and to help with migration from older mpv releases.
* DOCS/interface-changes.rst: mention OSX bundle loggingwm42020-02-081-0/+1
|
* cocoa-cb: fix auto-selection of title bar style with older SDKsder richter2020-02-081-0/+4
| | | | | returning a nil value only works when build with a +10.14 SDK otherwise we need to fallback to the old mechanism.
* cocoa-cb: simplify cursor hiding and make it less greedyder richter2020-02-083-12/+7
| | | | | | | | | | | | | | | | | | for reasons unknown to me the NSCursor (un)hide functions can be completely unreliable and the cursor can have an unknown state. this only happens on some system and wasn't able to reproduce this. it's probably some dumb race condition that might be possible to work around, though because of the lack of reproducibility on my end it's hard to test. i decided to rework the cursor hiding code yet again and make it a lot less greedy. the cursor will now always unhide when moved and there will never be a situation again the cursor can't be unhidden again. on the other hand there might be edge cases now where the cursor won't hide immediately and you have to move it slightly to make it disappear again. this should be an acceptable tradeoff. Fixes #6886
* mac: activate logging when started from the bundleder richter2020-02-084-7/+50
| | | | | | | | | | this creates a default log for the last mpv run when started from the bundle. that way one can get a log of what happened even after an issue occurred. also add a menu entry under Help to show the current log, but only when the bundle is used. Fixes #7396 Fixes #2547
* mac: remove stdout and stderr redirect for loggingder richter2020-02-081-11/+0
| | | | | | | this was kinda useless anyway since the bundle was started with terminal=no and no logging was done anyway. Fixes #1590
* wayland: adjust vo_wayland_wait_frame logicDudemanguy2020-02-071-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Wayland uses vo_wayland_wait_frame plus some polling with a timeout for blocking on vsync. Here are a couple of changes that seem to be improvements. First, the poll time is always rounded up instead of truncated. When rendering frames longer than the standard 16.666 ms timeout, it seems that truncating the poll time slightly early may cause some vsync jitter spikes. Waiting longer, even if it's too long, appears to behave better. The second change is to use wl_display_roundtrip instead of wl_display_dispatch_pending. wl_display_dispatch_pending dispatches all events immediately. This is good to avoid blocking, but it's not guaranteed to wait long enough for all events to be processed on the display fd. The preceding wl_display_read_events routine ensures that all events on the display fd are queued. We just need a semi-blocking routine to dispatch them for the most reliable vsync. wl_display_roundtrip will dispatch any events for us, but also wait for a reply from the display server. This makes it ideal for this role. If the compositor doesn't reply to the client something else is probably horribly broken and wrong anyway. It's also not a permanently blocking call like wl_display_dispatch. If there's no frame callback (i.e. the window is hidden), then it does not dispatch any events and returns immediately.
* DOCS: js: minor update for requireAvi Halachmi (:avih)2020-02-071-5/+5
|
* js: require: directory-scripts: first look at <dir>/modules/Avi Halachmi (:avih)2020-02-074-1/+16
| | | | | Also, add the function mp.get_script_directory() to let scripts know if they're loaded as a directory and where.
* js: require: don't use ~~/scripts/modules.js/Avi Halachmi (:avih)2020-02-072-12/+26
| | | | | | | | | Directories inside ~~/scripts/ are now loaded as scripts, so don't use it also for modules. Now there are no default module paths. To compensate, we now try to run ~~/.init.js right after defaults.js, so the user may extend the js init procedure via this script, e.g. for adding default paths to mp.module_paths .
* osc: use cache state cache-duration fieldwm42020-02-071-1/+1
| | | | Avoids an additional property access; see previous commit.
* command: add cache-duration to cache state propertywm42020-02-072-0/+6
| | | | Convenience; see following commit.
* demux: add option to disable "sharing" between back and forward bufferswm42020-02-072-2/+18
| | | | | | | As requested. I guess option name and manpage text could be better and clearer. Closes: #7442
* console: fix typo in previous commitwm42020-02-071-1/+1
| | | | Now keypad enter actually works.
* console: manually map numeric keypad (KP*) bindingswm42020-02-071-0/+7
| | | | | | | | | | | | | | | While mpv normally uses the text a key produces (as opposed to physical key mappings), this is different with the keypad. This is for the sake of making it possible to distinguish between these keys and the normal number keys on the left side of a full size keyboard. There were complaints that the keypad doesn't interact with console.lua, so manually map them. This ignores numlock (behaves as if it's always on), and maps KP_DEC to "." (even though it's mapped to "," on some keyboards). The /*-+ keys produce ASCII on mpv (at least with X11) as an inexplicable inconsistency, so there are no mappings for these. Fixes: #7431
* screenshot: fix typo in commentwm42020-02-071-1/+1
| | | | | It was not meant to imply that screenshots are male. Female (and other) screenshots are also welcome to this project.
* player: make screenshot each-frame mode more accuratewm42020-02-074-5/+11
| | | | | | | | | | | | | | | | | | | | | | | Due to asynchronicity, we generally can't guarantee that a video frame matches up with other events such as playback time change exactly (since decoding, presentation, and property update all happen at different times). This is a complaint in the referenced bug report, where screenshot filenames in each-frame screenshot did not use the correct timestamp, and instead was lagging behind by 1 frame. But in this case, synchronicity was already pretty much forced with wait calls. The only problem was that the playback time was updated at a later time, which results in the observed 1 frame lag. Fix this by moving the place where the screenshot is triggered in this mode. Normal screenshots may still have the old problem. There is no effort made to guarantee the timestamps absolutely line up, same as with the OSD. (If you want a guarantee, you need to use a video filter, such as libavfilter's drawtext. These will obviously use the proper timestamp, instead of going through the somewhat asynchronous property etc. system in the player frontend.) Fixes: #7433
* options: disable vsfilter blur compat by defaultwm42020-02-072-2/+2
| | | | | | | | | | | | | | | | | | | See #7435 and related for context. Basically, it seems that while the original vsfilter processed subtitles like with this option set to "yes", many current players (mpc-hc default, vlc, probably most libass users) treat them like with "no". In the linked issue, this makes rendering severely slower, and can consume a lot of memory (or just overflow libass memory calculations). It seems that changing this to "no" will lead to more good than bad, especially because newer subtitles may be authored for the "no" behavior. Most libass users seem to use "no" exactly because they do not call ass_set_storage_size() at all. This API was needed because the scaling of the subtitles depends on the video size (vsfilter bugs, or something). In addition, it's my personal opinion that rendering should not depend on the video at all, so I like setting the default of this to "no".
* lua: fix typo in commentwm42020-02-061-1/+1
|
* options.lua: avoid unnecessary on_update callsOscar Manglaras2020-02-061-1/+1
| | | | | | | The script was set up to only call on_update when the changelist was non-empty. However, since the size operator does not operate on dicts, it always returned 0 (which is truthy), thus on_update would always be called when the script-opts property changed.
* stats: fix incorrect ass formatting on 3rd page when vo was switchedsfan52020-02-061-0/+1
| | | | | | When switching between having a video visible or not, stats.lua now picks up the required formatting changes for the cache stats page to display correctly.
* scripting: give proper name to scripts using a directorywm42020-02-061-2/+8
| | | | | | | | | | | | | | | | | The recently added feature to load scripts from a sub-directory. A problem was that the script name was still derived from the actual script source file that was loaded, which was always "main.lua" (or similar), resulting in "main" as name. Fix this by using the directory name. One odd corner case is that you can do "--script=/path/foo////". As by POSIX semantics, the extra "/" are ignored. However, the newly added code strips only one separator, so mp_basename() returns "" (as it should), and the empty name makes mp_new_client() fail in turn. I don't really care about this, just don't do it. But mp_new_client() failure was silent (since it normally never happens), so add at least an error message for that, instead of being entirely silent.
* wayland: toplevel config fixesDudemanguy2020-02-062-3/+18
| | | | | | | | | | | | | | | | | | | | | | | There were a couple of erroneous things in the handle_toplevel_config function. Firstly, looping through the different states was not handled correctly. Launching a window as maximized (can happen in sway for example) was always stuck on true and would never be set to false. Fix this by always checking if XDG_TOPLEVEL_STATE_MAXIMIZED is found or not. Also do a similar thing for the fullscreen state. Additionally, there were some issues with resizing windows and window-scale going back to old sizes. The root of this problem is that the width and height arguments of handle_toplevel_config aren't actually guarenteed to be the actual width and height of the surface. There are times when mpv will set the surface size on its own (like with window-scale) which will be unknown to the toplevel listener. To complicate matters, there are times when we do want to use the width and height arguments (like when resizing with the mouse). Fix this by checking if the width and height arguments reported by handle_toplevel_config changed from the previous call of the function. If the value is different, then we go ahead and use them when setting mpv's geometry. If not, then we just ignore it.
* lua: use mp_path_is_absolute() for checking package pathswm42020-02-061-1/+1
| | | | | This makes it work with the shitty OS. Behavior on Linux should be the same.
* path: add mp_path_is_absolute()wm42020-02-063-10/+41
| | | | Just move it from mp_path_join_bstr() to this new function.
* path: change win32 semantics for joining drive-relative pathswm42020-02-062-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | win32 is a cursed abomination which has "drive letters" at the root of the filesystem namespace for no reason. This requires special handling beyond tolerating the idiotic "\" path separator. Even more cursed is the fact that a path starting with a drive letter can be a relative path. For example, "c:billsucks" is actually a relative path to the current working directory of the C drive. So for example if the current working directory is "c:/windowsphone", then "c:billsucks" would reference "c:/windowsphone/billsucks". You should realize that win32 is a ridiculous satanic trash fire by the point you realize that win32 has at least 26 current working directories, one for each drive letter. Anyway, the actual problem is that mpv's mp_path_join() function would return a relative path if an absolute relative path is joined with a drive-relative path. This should never happen; I bet it breaks a lot of assumptions (maybe even some security or safety relevant ones, but probably not). Since relative drive paths are such a fucked up shit idea, don't try to support them "properly", and just solve the problem at hand. The solution produces a path that should be invalid on win32. Joining two relative paths still behaves the same; this is probably OK (maybe). The change isn't very minimal due to me rewriting parts of it without strict need, but I don't care. Note that the Python os.path.join() function (after which the mpv function was apparently modeled) has the same problem.
* test: add some path handling testswm42020-02-064-0/+51
| | | | | Exhaustive tests would be nice, but I'm only adding a test for a function I'm going to change.
* lua: fix highly security relevant arbitrary code execution bugwm42020-02-061-14/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears Lua's package paths try to load .lua files from the current working directory. Not only that, but also shared libraries. WHAT THE FUCK IS WHOEVER IS RESPONSIBLE FOR THIS FUCKING DOING? mpv isn't setting this package path; currently it's only extending it. In any sane world, this wouldn't be a default. Most programs use essentially random working directories and don't change it. I cannot comprehend what bullshit about "convenience" or whatever made them do something this broken and dangerous. Thousands of programs using Lua out there will try to randomly load random code from random directories. In mpv's case, this is so security relevant, because mpv is normally used from the command line, and you will most likely actually change into your media directory or whatever with the shell, and play a file from there. No, you don't want to load a (probably downloaded) shared library from this directory if a script try to load a system lib with the same name or so. I'm not sure why LUA_PATH_DEFAULT in luaconf.h (both upstream and the Debian version) put "./?.lua" at the end, but in any case, trying to load a module that doesn't exist nicely lists all package paths in order, and confirms it tries to load files from the working directory first (anyone can try this). Even if it didn't, this would be problematic at best. Note that scripts are _not_ sandboxed. They're allowed to load system libraries, which is also why we want to keep the non-idiotic parts of the package paths. Attempt to fix this by filtering out relative paths. This is a bit fragile and not very great for something security related, but probably the best we can do without having to make assumptions about the target system file system layout. Also, someone else can fix this for Windows. Also replace ":" with ";" (for the extra path). On a side note, this extra path addition is just in this function out of laziness, since I'd rather not have 2 functions with edit the package path. mpv in default configuration (i.e. no external scripts) is probably not affected. All builtin scripts only "require" preloaded modules, which, in a stroke of genius by the Lua developers, are highest priority in the load order. Otherwise, enjoy your semi-remote code execution bug. Completely unrelated this, I'm open for scripting languages and especially implementations which are all around better than Lua, and are suited for low footprint embedding.
* lua: add mp.get_script_directory() functionwm42020-02-042-5/+27
| | | | And add some clarifications/suggestions to the manpage.
* player: partially fix backward playback display of cached text subtitleswm42020-02-042-5/+4
| | |