summaryrefslogtreecommitdiffstats
path: root/TOOLS/lua
Commit message (Collapse)AuthorAgeFilesLines
* TOOLS/lua/autoload: fix allow extending ext sets from script-optsChristoph Heinrich12 days1-6/+18
| | | | | | https://github.com/mpv-player/mpv/commit/4eedb8710cccec719f393216f5f32b74025c7df9 has broken the normal work of this feature with --same_type=yes Co-Authored-by: dyphire <qimoge@gmail.com>
* f_auto_filters: change fallback deinterlace to bwdifDudemanguy2024-01-211-1/+1
| | | | | | | I don't actually deinterlace ever but allegedly this is better than yadif, and there's no real reason to not have this be the fallback deinterlace when we're not using hw frames. Also change various mentions of yadif to bwdif. Ref #12835.
* TOOLS/autocrop.lua: drop Libav mentionllyyr2024-01-201-1/+1
|
* scripting: don't observe properties with type nilGuido Cella2024-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | mp.observe_property('foo', nil, ...) calls the handler at least 2 times on each playlist change even when the property doesn't change. This is dangerous because if you haven't read observe_property's documentation in a long time this is easy to forget, and you can end up using it for handlers that are computationally expensive or that cause unintended side effects. Therefore, this commit discourages its use more explicitly in the documentation, and replaces its usages in scripts. For console.lua, observing focused with type nil leads to calling mp.osd_message('') when changing file while playing in the terminal with the console disabled. I don't notice issues from this, but it's safer to avoid it. For playlist and track-list this doesn't really matter since they trigger multiple changes on each new file anyway, but changing it can avoid encouraging people to imitate the code. One usage of none in stats.lua is kept because according to b9084dfd47 it is a hack to replicate the deprecated tick event.
* TOOLS/lua/autoload: skip loading when playback is abortedsunpenghao2024-01-201-0/+6
| | | | | | Quickly going through a directory with too many loadable files causes the autoload tasks to pile up and exiting the player will take forever. Avoid this by skipping loading when playback is aborted.
* TOOLS/autocrop.lua: disable hwdec when needed instead using -copy oneKacper Michajłow2023-10-181-4/+3
| | | | | | | This is more stable in practice. Avoids switching between possibly different hwdecs and avoids unnecessary init. Software decoding should be more stable and possibly faster overall for decoding this small portion of video needed for cropdetect.
* TOOLS/autocrop.lua: add support for detect_min_ratioKacper Michajłow2023-10-071-1/+9
| | | | This was lost in 6b963857c0
* TOOLS/autocrop.lua: simplify codeGuido Cella2023-10-071-30/+14
| | | | | Refactor code that is no longer necessary after replacing vf=crop with video-crop. There is no change in behavior.
* TOOLS/autocrop.lua: update commentGuido Cella2023-10-061-64/+44
|
* TOOLS/lua/autoload: bump the msg-level of some loggingDudemanguy2023-10-031-6/+6
| | | | | | | msg.info for when you're potentially adding hundreds of files is way too spammy and not really useful (autoload loads files, what?). Bump it up to msg.verbose. Also bump up the previously existing msg.verbose logs up to msg.debug to keep the difference in log levels. Fixes #12551.
* TOOLS/autocrop.lua: switch to auto-copy hwdec during cropdetectGuido Cella2023-09-211-0/+20
| | | | | | | I didn't set file-local-options/hwdec because you have to store the hwdec value to restore it after cropdetect anyway, and if the user manually changes hwdec after cropdetect, the new value isn't reset when changing file.
* TOOLS/autocrop.lua: cleanup timers correctlyGuido Cella2023-09-211-1/+1
| | | | | | | If you change file while cropdetect is active and you try to crop the next video, it fails with "Already cropdetecting!". This is because timers.detect_crop wasn't cleared correctly, only the timer variable local to the loop was being set to nil.
* TOOLS/autocrop.lua: use VO crop alwaysKacper Michajłow2023-09-201-47/+12
| | | | | There is no reason not to and this significantly reduces script complexity.
* options: make video-crop validation more strictKacper Michajłow2023-09-201-2/+2
|
* TOOLS/lua/autoload: rename local variable to lowercaseChristoph Heinrich2023-09-151-6/+6
|
* TOOLS/lua/autoload: pass extensions to recursive callChristoph Heinrich2023-09-151-1/+1
| | | | Closes #12400
* TOOLS/lua/autoload: change EXTENSIONS_TARGET to a local variabledyphire2023-09-141-3/+4
|
* TOOLS/lua/autoload: fix specify loading only one type of filesdyphire2023-09-141-1/+1
| | | | Fixes: https://github.com/mpv-player/mpv/commit/5100e7acbabd52b7ebc996e1c73df059e7664018
* TOOLS/lua/autoload: add directory_mode optionChristoph Heinrich2023-09-131-2/+14
| | | | | | This option behaves the same as the builtin one, and if it's value is anything other then recursive|lazy|ignore it will fall back on the builtin one as a sort of "auto" mode. It defaults to that auto mode.
* TOOLS/lua/autoload: add recursive directory loadingChristoph Heinrich2023-09-131-36/+63
| | | | Recursion depth has been limited to 20, the same depth the demuxer uses.
* TOOLS/lua/autoload: avoid adding entries to the playlist more then onceChristoph Heinrich2023-09-131-13/+15
| | | | | Playlist entries should be added at most once, independent of if they got added by autoload or not.
* TOOLS/lua/autoload: support directoriesChristoph Heinrich2023-09-131-8/+22
| | | | | | | | | Adds support for adding directories to the playlist in addition to files. The propertiy `directory-mode` controls if directories get added. Recursive directory loading will get added in a later commit. Directories get sorted after files to behave the same way mpv behaves when it loads directories directly.
* autocrop.lua: enable vo_crop mode by defaultKacper Michajłow2023-09-081-1/+1
| | | | | It is just better way of cropping things. Can be disabled with script-opts if needed.
* autocrop.lua: don't remove crop on startup/exitKacper Michajłow2023-09-081-1/+4
| | | | | No need to remove/clean crop unlike with filters. Allows using autocrop with auto=false and custom --video-crop.
* autocrop.lua: detect if crop is enabled based on propKacper Michajłow2023-09-081-3/+5
| | | | | Now we can have full frame crop, so to avoid checking that, just check property.
* autocrop.lua: use new --video-cropKacper Michajłow2023-08-311-0/+14
| | | | | | | Gated behind option for backward compatibility. Note that this will not magically start working with hwdec, as we do not have crop detection for hwdec.
* TOOLS/lua/autoload: Enable run-time updates of optionsChristoph Heinrich2023-08-191-12/+23
| | | | additional_*_exts get parsed and saved as sets in the options themselves
* TOOLS/lua/autoload: may specify loading only one type of filessunpenghao2023-08-191-3/+18
| | | | | | | | | | Under the current file loading logic, a video file and an external audio track next to it will both be added to the playlist, which most users don't wish to happen. Having an option that tells the script to load only one type of files (video, audio, or image) can avoid this problem. It may also come in handy for people who have different types of files mixed in a folder but wish to consume only one type of media at a time.
* TOOLS/lua/autoload: allow extending ext sets from script-optsllyyr2023-07-061-0/+16
|
* TOOLS/lua/autoload: avoid unnecessary playlist manipulation, performanceEva2023-07-031-20/+29
| | | | | | | | | | | | | | We used to sort the playlist with playlist-move after every loadfile. Instead, append all files in order and call playlist-move once to move the only entry we don't control the position of. Don't fetch every playlist item separately, reuse native property. We used to pick up on new files added to the directory, but only when playing an entry at the edge of the playlist due to an early return. New files are now added to the playlist on every file change. This still works as expected and doesn't load duplicate files on shuffled playlists or playlists with files manually added after autoload 33% faster on average for my test directory with 1371 files.
* TOOLS/autocrop.lua: log a more accurate warningGuido Cella2023-02-271-18/+12
| | | | | | | | | | | | | This reorders some code and checks the image track-list sub-property instead of the albumart one, so that when playing audio without enough playtime-remaining and images, the "autocrop only works for videos." warning is logged instead of the "Not enough time to detect crop." one. It also avoids repeating this warning twice in the code. As of e16d0dd15d current-tracks returns a video track even when lavfi-complex is used, so the track-list loop in is_cropable can be replaced with just checking current-tracks/video while still cropping videos with lavfi-complex.
* TOOLS/lua/autoload: improve alphanumeric sortingChristoph Heinrich2023-01-151-4/+4
| | | | | | | | | | | | | | | Currently filenames like `EP.1.v0.1080p.mp4` do not get sorted correctly (e.g. episode 11 right after episode 1). That is caused by the `.` in front of the episode number, making it get sorted as if it were decimals. The solution is to match the whole real number or integer instead of matching the integer part and the fractional part separately. This will regress sorting of numbers with multiple commas where the length of the individual segments differs between filenames. Since those are rather uncommon, that is unlikely to be a problem (for anyone ever).
* TOOLS/lua/autoload: optimize performance of natural sortingChristoph Heinrich2023-01-091-5/+10
| | | | | | Formatting the string on each comparison is wasteful. Formatting strings beforehand and then comparing the already formatted ones leads to a huge performance gain.
* TOOLS/lua/autoload: further optimize the natural sortingdyphire2023-01-091-35/+19
| | | | | | | | | | | | | Commits https://github.com/mpv-player/mpv/commit/257dbdf06feb366f9eb1f96ceb7026c9365dddaa uses a algorithm of splitting strings into a table of number and string values to achieve natural sorting. This approach works well in most cases, but it does not work well in some specific scenarios. Now let's implement natural sorting with a stronger algorithm. Also fixes indentation. Ref: https://github.com/jonniek/mpv-playlistmanager/commit/3cf323f3c419af77f4141119283c1ec2911491c5 Closes https://github.com/mpv-player/mpv/issues/8969
* TOOLS/lua/autoload: fix incorrect duplicate file loading behaviordyphire2022-10-241-9/+14
| | | | | | | This will correctly avoid the duplicate file loading when the playlist changes due to shuffle playback or append new files. Fixes https://github.com/mpv-player/mpv/issues/8575
* TOOLS/lua/autoload: add various extra file extensionsLeo Izen2022-09-231-4/+6
| | | | | Add to autoload.lua several extra file extensions that are unambiguously for media files.
* TOOLS/lua/autoload: alphebatize auto-loaded file extensionsLeo Izen2022-09-231-3/+4
| | | | | | Alphabetizing the extensions cleans up the code and makes it less ambiguous where newer extensions should be added. The video line also was wrapped to 72 characters for cleanliness.
* TOOLS/lua/autoload: add `m2ts` extensionDeadNews2022-09-141-1/+1
| | | | * `.m2ts` used for the Blu-ray disc container file format
* various: fix typosCœur2022-04-251-1/+1
|
* TOOLS/autocrop.lua: allow hiding OSD messagesGuido Cella2021-07-271-6/+12
| | | | | | Because having these on every video is annoying, and when you resume from watch later files, the filters are applied immediately so they hide your osd-playing-msg or equivalent show-text commands.
* TOOLS/autocrop.lua: improve enable/disable conditionGuido Cella2021-07-141-5/+6
| | | | | | | | | | | | | | | | | | The previous code tried to disable autocrop for cover-art by testing that track-list/$vid/albumart is false, however, $vid is completely unrelated to the track-list index. It only sometimes succeeded to disable for albumart, by accident, e.g. with one audio track and one video track where $vid==1 and track-list/1 happens to be the video (cover art) track. The new code detects the currently-used video track by finding a track with type=="video" and selected==true. Unlike the previous code, it also works in scenarios with many audio/video/sub tracks. Additionally, autocrop is now enabled also with lavfi-complex, which should be considered an improvement. The previous code implicitly disabled it with lavfi-complex because $vid is nil on such case.
* TOOLS/lua/autoload: load files even if current file is hiddenLaserEyess2021-06-241-1/+3
| | | | | | | When the current file is hidden and `ignore_hidden` is true, autoload will skip loading other files in the current directory. Make sure that the current file is always counted for autoloading even if it is hidden.
* TOOLS/lua/autoload: add ignore_hidden optionLaserEyess2021-06-241-2/+4
| | | | | | | | | | | | | | | In 8a7614a0fb0d4f1073057049933972bb1113c14c files that start with a '.' were blacklisted from autoload.lua. Since then 35e8710b86545849484f6544a16047792fa75bb2 was introduced and explicitly whitelisted file extensions. With this change, there is no longer a reason to blacklist all files starting with '.', because it is valid to have a file called '.hidden.mkv', and there is no chance of hidden files such as '.bashrc', '.DS_STORE', '.gitignore', etc. being autoloaded by mpv. This commit tries to keep the same behavior as before, which is to by default not load hidden files, but allows the user to optionally allow hidden files to be autoloaded.
* command: extend subprocess command stdin, change behaviorwm42020-08-161-0/+19
| | | | | | | | | | | | | | | Make it possible to feed a string to stdin of a subprocess. Out of laziness, it can't be an arbitrary byte string. (Would require adding an option type that takes in a Lua byte string.) Do not set stdin of a subprocess to fd 0 (i.e. mpv's stdin) anymore, because it makes things more consistent. Enabling stdin didn't make too much sense in the first place, so this behavior change seems justifiable. win32 support missing. Fixes: #8003
* TOOLS/autocrop.lua: automatically crop at startupヒカリ2020-06-011-84/+292
|
* client API: provide ways to finish property changes on file changeswm42020-03-071-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the current file changes (or rather, when starting/finishing playback of a playlist entry), clients tend to have the problem that it's hard to tell whether a property change notification (via mpv_observe_property() and mechanisms layered on top of it) is from the previous or new playlist entry. The previous commit probably helps, but all the asynchronity is still a bit unhelpful. Try to make this better by adding new hooks, that are run before/after playback init/deinit. This is similar to the existing hooks, except they're outside of "initialized" playback, which excludes that you might accidentally get an overlap between the current and the previous/next playlist entry. That still doesn't seem quite enough, since normally, property change notifications come after the hook event. So basically a client would have to explicitly "drain" the event queue within the hook, and make the hook continue only after that is done. Knowing when property notifications are done is another asynchronous nightmare (how exactly it works keeps changing within client.c, and an API user probably can't tell anymore when all pending properties are truly done). So introduce another guarantee: properties that were changed before the hook happens will be returned before the hook event is returned. That means the client will have received all pending property notifications from the previous playlist entry (or whatever) before the hook is entered. As another minor complication, we shouldn't just keep the hook pending until _all_ property notifications are done, since the client's hook could produce new ones. (Or just consider things like the demuxer thread hammering the client with cache update events, while the "on_preloaded" hook is run.) So there is some extra untested, fragile logic in client.c to handle this (the waiting_for_hook flag). This probably works, but was barely tested. Not sure if this helps anyone, but I think it's fine for my own purposes. (I really hated this aspect of the API whenever I used it myself.)
* command: extend osd-overlay command with bounds reportingwm42020-03-061-0/+35
| | | | | | | | | | | | | | | | | | | | This is more or less a minimal hack to make _some_ text measurement functionality available to scripts. Since libass does not support such a thing, this simply uses the bounding box of the rendered text. This is far from ideal. Problems include: - using a bitmap bounding box - additional memory waste and/or flushing caches - dependency on window size - odd small deviations with different window sizes (run osd-test.lua and resize the window after each timer update; the bounding boxes aren't adjusted in an overly useful way) - inability to query the size _after_ actual rendering But I guess it's a start. Since I'm aware that it's crap, add a threat to the manpage that this may be changed/removed again. For now, I'm interested whether anyone will have use for it in its current form, as it's an often requested feature.
* skip-logo.lua: remove lua 5.2 warning messagewm42020-02-291-1/+0
| | | | (OK, I tested it.)
* TOOLS/lua/autoload.lua: update script commentsThomas Carmichael2020-02-151-6/+6
| | | | | | | | | The example configuration uses values of true/false for the script options. As per DOCS/man/lua.rst boolean values should be represented with yes/no and using true/false will result in an error. This updates the comments and changes the true/false values under the example configuration to yes/no.
* vo_gpu, options: don't return NaN through APIwm42019-10-251-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* skip-logo.lua: fix skipping in the first two frameswm42019-10-081-15/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv typically decodes and filters at least 2 frames before starting playback. This happens during seeks, as well as when playback starts from the beginning of the file. skip-logo.lua receives notifications for all filtered frames, even during seeking. It should interrupt during seeking, so as a crude heuristic, it ignored all frames while the player was seeking. This does not mean all these frames are skipped due to seeking (thus it's a "crude hueristic"). In particular, it means that the first 2 frames of a video cannot be skipped, since they're filtered within the playback restart phase (equivalent to "seeking"). Fix this by making the heuristic slightly less crude. Since we observe the property as "none", the property is not actually read until we do it explicitly. By not reading it during seeking, we can let the frames internally queue up (vf_fingerprint discards them in a ringbuffer-like fashion if they're too many). Then, if seeking ends, we get the current playback timestamp, and check queued up frames that are at or after that timestamp. (In some ways, this duplicates what the player's seeking logic does.) A disadvantage is that this is racy. While playback-time is guaranteed to be set when seeking changes from false to true, playback could already have progressed to the next frame (or more) before the script gets time to react. In theory, we could add a seek restart hook or so, but I don't want to. A property that returns the last playback restart time would also do it, but feels to special. Not an important problem in practice anyway.
* player: "subprocess" command should stop immediately in idle modewm42019-10-041-3/+13
| | | | | | | | | | | | The description of the "playback_only" field in the "subprocess" command says "you can't start it outside of playback". This did not work correctly: if the player was started in idle mode in the first place, the subprocess was allowed to run even with playback_only=yes. This is a bug, and this change fixes it. Add a test for this to command-test.lua. For #7025.
* autoload.lua: Configurable autoload typesMarek Sebera2019-10-021-4/+42
| | | | | | | | | | | Autoload script now suppports loading of not only video, but also image and audio files, in a manner, where one can configure which of the groups (audio, videos, images) is currently enabled. Use file script-opts/autoload.conf with key=value configuration keys disabled,images,videos,audio to configure autoload script. See documentation on top of the script
* video: add vf_fingerprint and a skip-logo scriptwm42019-09-191-0/+245
| | | | | | | | | | | | | | | | | | | | | | | | | skip-logo.lua is just what I wanted to have. Explanations are on the top of that file. As usual, all documentation threatens to remove this stuff all the time, since this stuff is just for me, and unlike a normal user I can afford the luxuary of hacking the shit directly into the player. vf_fingerprint is needed to support this script. It needs to scale down video frames as part of its operation. For that, it uses zimg. zimg is much faster than libswscale and generates more correct output. (The filter includes a runtime fallback, but it doesn't even work because libswscale fucks up and can't do YUV->Gray with range adjustment.) Note on the algorithm: seems almost too simple, but was suggested to me. It seems to be pretty effective, although long time experience with false positives is missing. At first I wanted to use dHash [1][2], which is also pretty simple and effective, but might actually be worse than the implemented mechanism. dHash has the advantage that the fingerprint is smaller. But exact matching is too unreliable, and you'd still need to determine the number of different bits for fuzzier comparison. So there wasn't really a reason to use it. [1] https://pypi.org/project/dhash/ [2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-051-0/+95
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * player: make various commands for managing external tracks abortable