summaryrefslogtreecommitdiffstats
path: root/player
Commit message (Collapse)AuthorAgeFilesLines
* player: add ab-loop-count option/propertywm42020-02-083-1/+9
| | | | | | | | | | | | 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
* js: require: directory-scripts: first look at <dir>/modules/Avi Halachmi (:avih)2020-02-072-0/+10
| | | | | 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-071-1/+6
| | | | | | | | | 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-071-0/+3
| | | | Convenience; see following commit.
* 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
* 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.
* 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.
* 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-041-0/+11
| | | | And add some clarifications/suggestions to the manpage.
* player: partially fix backward playback display of cached text subtitleswm42020-02-042-5/+4
| | | | | | | | | | | | | | This simply didn't set the direction flag in most situations, which meant the timestamps used in the subtitle renderer were nonsense, leading to invisible subtitles. This works only for text subtitles that are cached in the ASS_Track state. Reading new subtitles is broken because the demuxer layer has trouble returning subtitle packets backwards, and I think for rendering bitmap subtitles, the pruning direction would have to be adjusted. (Not sure if reversing the timestamps before the subtitle renderer backend is even the right thing to do. At least for sd_ass.c, it seems to make sense, because it caches subtitles with "normal" timestamps.)
* lua: set package path if loaded from a script directorywm42020-02-011-0/+29
| | | | | | And document the shit. This uses code from commit bc1c024ae032e5b5c.
* scripting: load scripts from directorieswm42020-02-016-52/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | The intention is to provide a slightly nicer way to distribute scripts. For example, you could put multiple source files into the directory, and then import them from the actual script file (this is still unimplemented). At first I wanted to require a config file (because you need to know at least which scripting backend it should use). This wouldn't have been too hard (could have reused/abused the mpv config file parsing mechanism, and I already had working code that was just 2 function calls). But probably better to do this without new config files, because it might become a pain in the distant future. So this just probes for "main.lua", "main.js", etc., until an existing file is found. Another important change is that this skips all directory entries whose name starts with ".". This automatically excludes the "." and ".." special directories, and is probably useful to exclude random crap that might be lying around in the directory (such as editor temporary files, or OSX, in its usual hrmful, annoying, and idiotic modus operandi, sharting all over any directories opened by "Finder"). Although the changelog mentions the docs, they're added only in a later commit.
* lua: stop setting bogus package pathwm42020-01-261-25/+0
| | | | | Scripts are not supposed to be able to "import" anything from mpv's scripts directory, because all these files are loaded by mpv itself.
* player: fix minor coding style issuewm42020-01-261-1/+2
|
* player: check if file is URL before attempting to get mtimeChris Down2020-01-261-2/+5
| | | | | | I noticed an oversight when using ytdl-hook -- if the path is a URL, we try to `stat()` it, which obviously doesn't work. To mitigate that, don't check or update mtimes for URLs.
* cocoa-cb: add support for forcing the dedicated GPU for renderingder richter2020-01-261-1/+1
| | | | | | | | this deprecates the old cocoa backend only option and moves it to the general macos ones. add support for the new option in the cocoa-cb layer creation and use the new option in the olde cocoa backend. Fixes #7272
* player: make failure to load scripts non-fatal againwm42020-01-201-2/+1
| | | | | Restore the behavior from a few commits ago. I decided that it's strange that this is fatal, since e.g. config file errors are also non-fatal.
* scripting: make player error when attempting to load unknown scriptswm42020-01-193-7/+15
| | | | | | It's ridiculous that --script=something.dumb does not cause an error. Make it error, and extend this behavior to the scripts/ sub-dir in the mpv config dir.
* player: write watch-later config even for unseekable streamswm42020-01-171-5/+7
| | | | | | | | | | | | I think there was a user complaint that this does not restore the playlist position. There's no reason not to save the "state" for unseekable streams; what we probably don't want is to make restoring trying to issue a seek. So just don't save the position. (Although we probably could anyway, since seek requests on unseekable streams are ignored now.) Fixes: issue number forgotten, if it even exists.
* osc: more frequent cache updates: from 10% diff to 5% or 5sAvi Halachmi (:avih)2020-01-141-2/+2
| | | | | | | | Cache display updates, especially when it's bigger than few minute, could have been be very infrequent to the point that one is not sure if it updates at all. Reduce the 10% change-threshold to 5% and add another threshold of 5s.
* osc: usability improvements for pseudo-csd title barPhilip Langdale2020-01-131-4/+21
| | | | | | | | | | | | | | | | | | | There are two improvements here: 1) Correct the right-side padding on the title box. This was messed up previously because I was passing the title box width when I should be passing the x coordinate. I've also increased the spacing to separate the title from the window controls more clearly. 2) I'ved added a mouse tracking area over the title bar so that the osc doesn't disappear if you hover over the title box. This didn't work previously because the input area only covers the actual window controls. The implementation here is simplified in that it's only a mouse area and not an input area. This is enough to keep the osc visible, but it won't stop the mouse pointer disappearing. Fixing that requires a full input area which, for now, I will say isn't worth the effort.
* osc: when fullscreened, un-maximise window control should un-fullscreenPhilip Langdale2020-01-121-2/+8
| | | | | | | | | | | | | | | It's a bit unintuitive today when you use the un-maximise control while fullscreened. Depending on the VO in use, this might silently change the maximise state without any visible effect, or it might do nothing. It's less surprising if the control exits the fullscreen state. Note that the exact behaviour is still VO dependent. If the window was maximised before being fullscreened, it might exit fullscreen back to maximised or back to regular window mode. I thought about trying to explicitly control that behaviour but it makes the osc code weird and probably wouldn't work all the time.
* Revert "options: move cursor autohiding opts to mp_vo_opts"dudemanguy2020-01-122-5/+5
| | | | This reverts commit 65a317436df05000366af2738bdbb834e95e33db.
* command, vo: add a mechanism for runtime DPI scale changeswm42020-01-093-1/+7
| | | | | Follow up to commit a58585d5e063. It turned out that the OSX backend needs this.
* client API: fix property notification from non-playloop sourceswm42020-01-091-2/+4
| | | | | | | | | | | | | | | This code assumed that the function is only called from the playloop itself (and since property notification is done at the end of it, i.e. before sleeping, it obviously would not have needed to wake up the core). But this function is actually called from some comments (such as playlist-move), so this assumption was incorrect. Use the same method as the other function. Untested. Fixes: #7339 (probably)
* client API: change event mask to event number in one placewm42020-01-091-4/+5
| | | | Cosmetic change. Slightly more convenient/readable.
* js: use osd-dimentions for mp.get_osd_{size,margins}Avi Halachmi (:avih)2020-01-082-14/+7
| | | | | | | | | | | This matches lua's 11b9315b but with the lagacy field names which the js code used previously. Currently the property always returns an object (with dummy/last/null field values if there are no dimensions), but the code is ready for a future case where it might return null if there are no dimensions - at which case it will forward the null, breaking backward compatibility for a better API.
* osc: don't delay updates on resizewm42020-01-081-4/+19
| | | | | | | | | | | The idea is that if the player is resized, we do not delay redrawing (which is normally done to limit the redraw rate to something reasonable). Not sure if this even does anything. For one, reacting to osd-dimensions changes is cleaner than just polling the screen size with the next tick event, and hoping that resizes generate tick events for whatever logically unrelated reasons.
* osd: fix possible misses of osd-dimensions property updateswm42020-01-082-0/+14
| | | | | | | | | | | | | check_obj_resize() in sub/osd.c calls mp_client_broadcast_event(), which calls notify_property_events(). This is pretty unexpected, because check_obj_resize() may be called from the VO thread. While that's sort of awful, it seems to be OK locking-wise. But it breaks an assumption in notify_property_events() that the core doesn't need to be woken up, which could possibly lead to a missed/delayed property update (although rather unlikely). Fix this by explicitly waking up the core when it's called from the OSD code.
* 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.
* lua: use new OSD propertywm42020-01-082-21/+6
| | | | | | | | See previous commit. A nice side-effect is that mp.get_osd_margins() is not a special Lua-only thing anymore. I didn't test whether this function still works as expected, though.
* 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.)
* osc: reset input handling state on a change in visibility modePhilip Langdale2020-01-021-0/+7
| | | | | | | | | | | | | | | | | Currently, the activation and deactivation of input handling is done inside the render() loop, but this does not run when the osc mode is `never` - which does make sense. That means that if you are cycling the visibility mode, the input state will be whatever it was at the time of the mode change. And, as our modes are ordered `auto` -> `always` -> `never`, the input state will be enabled when you cycle to `never`. There are various ways you can imagine fixing this, and in this change I propose we reset the input state to disabled on a mode change, and then let render() re-enable input if that's appropriate. Fixes #7298.
* configfiles: Fix utime retcode checkChris Down2019-12-311-1/+1
| | | | | In final fixups for #7139 it seems I managed to screw up utime error checks. Everything still works, but we MP_WARN when we don't need to.
* player: make unpausing directly after seek work with --keep-openwm42019-12-301-0/+3
| | | | | | | | | | | | | | | When using --keep-open, and the end of the file is reached, the player's "pause" property is set to true. Attempting to set it to false reverts it back to true immediately. That's how it's designed, for better or worse. Running "seek -10 ; set pause no" did not work, because the seek is first queued and pause is unset, but then the decoding functions determine that EOF is still a thing, and "mpctx->stop_play = AT_END_OF_FILE;" is set again. handle_keep_open() then sets pause again. Only then the seek is actually run. Fix this by not setting stop_play if a seek is queued.
* 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-285-55/+30
| | | | | | | | | | | | | | | | | | | 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.
* lua: fix mp.file_info for large filesSai Ke WANG2019-12-281-2/+2
| | | | | | `size` field with `unsigned int` was truncated to 4GB Signed-off-by: wm4 <wm4@nowhere>
* console: add a basic help commandwm42019-12-241-1/+50
| | | | | | | | | | | | | | | It's not really great. But I think it's good enough to save someone who's lost. Most importantly, it should become obvious _what_ the console expects (input commands), and how to exit it. Would be nice if we could show some documentation, or give a link to documentation, but that's out of scope and/or not easy. I considered implementing the "help" command as builtin command in command.c. On the other hand, this could not show console.lua specific help, so I implemented it in console.lua. The ad-hoc command parsing (that sort-of mirrors mpv input command syntax) for the "help" command is probably the worst part of this.
* console: do not strip leading spaceswm42019-12-241-0/+3
| | | | As suggested by TheAMM and avih.
* command: extend command-list outputwm42019-12-241-0/+14
| | | | Add some very basic information about arguments.
* stats: do not use "tick" eventwm42019-12-241-2/+6
| |