summaryrefslogtreecommitdiffstats
path: root/TOOLS
Commit message (Collapse)AuthorAgeFilesLines
* TOOLS/matroska.py: support outputting to fileDudemanguy2021-11-141-2/+7
| | | | | Like the previous commit, it's better to just output it to a file for meson.
* TOOLS/file2string.py: support outputting to fileDudemanguy2021-11-141-1/+6
| | | | | | | Another modification for the upcoming meson build. Meson can capture the stdout and redirect it to a file. However, this is considered a hack. It's better to just add a few lines to this script and write a file directly.
* TOOLS: add macos-swift-lib-directory.py scriptDudemanguy2021-11-141-0/+42
| | | | | | | Apple is great and forces us to do a lot of weird checks because they randomly move the location of the swift libraries around. Make a specific python script for checking various locations and write the output to stdout for meson.
* TOOLS: add macos-sdk-version.py scriptDudemanguy2021-11-141-0/+68
| | | | | | | | Building for macos requires us to check the macos sdk path as well as the sdk version that is on the system. To do this, let's steal the logic that's in the compiler_swift.py check from the waf build. This returns a comma-delinated string. The first entry is the absolute path to the sdk. The second entry is the detected macos sdk version.
* 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.
* osxbundle: use python3Kiracus2021-07-172-3/+2
|
* 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.
* osxbundle: fix slow and wasteful memory allocationder richter2021-05-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | when using the bundle with activated big enough cache, very slow and wasteful memory allocations lead to jittery playback and lot of dropped frames. the cache had to have a certain size so it would constantly allocate new memory to reproduce this. this never happens when started from the terminal. the source of the problem is a different malloc allocation policy, MALLOC_NANO, that allocated a huge amount of virtual memory without actually using it. the usage was between 0% to 25% of that virtual memory. the binaries allocation policy on the other hand used >80% of that allocated virtual memory and was a lot more efficient, it would use MALLOC_TINY instead. this is fixed by setting the MallocNanoZone environment variable to 0 to use the V1 of the allocation policy. when started from the bundle via launchd this is forced to 1 and V2 policy which causes this problem. some more info can be found in following file and its comments on the Apple open source site: https://opensource.apple.com/source/libmalloc/libmalloc-317.40.8/src/nano_malloc_common.c.auto.html Fixes #7405
* build: move website rebuild into Linux/clang travis jobsfan52021-05-161-1/+1
| | | | The mingw ones will be removed in the next commit.
* umpv: Use generator expression for filesjimman20032021-03-031-1/+1
| | | Instead of list. potential memory savings.
* appveyor: Use MSYS2's spirv-cross package instead of building itBiswapriyo Nath2021-02-231-9/+1
|
* umpv: remove unused importsJim Manos2021-01-191-2/+0
| | | | | | | * fcntl usage was replaced by socket usage in 518bd4c306d50e6772c39c5d7395b9d10b9386da * stat usage was removed in 51a3f13705f8b65b3bfcef5b991903d225759014 as the socket was created under the user's HOME.
* appveyor: use MSYS2 shaderc packageJames Ross-Gowan2020-12-191-11/+1
| | | | | There's a shaderc package in MSYS2 now. Using it should shave ten minutes off the appveyor build.
* matroska.py: remove python2 supportLaserEyess2020-11-271-6/+2
| | | | | | | | | | Since 0.33.0 mpv does not support python2. This commit removes python2 support from the file completely with the following changes: - __future__ import of print_function is python2 only - unicode literals are legacy in python3 - 'sys.version_info.major < 3' check is redundant
* file2string: remove question mark from safe charssfan52020-11-221-8/+3
| | | | | | | | | | Trigraphs such as "??=" (which are enabled by default with -std=c11) can mess up strings, so avoid them entirely by escaping question marks. This also drops Python 2 compatibility from file2string, making the change to the waf rule necessary. The input file is now opened in binary mode which is also more correct versus the old text mode which just happened to work even on binary files.
* stream_lavf: enable SRT protocol support through FFmpegAlexandre Iooss2020-10-151-0/+1
| | | | | Additionally, announce support for the protocol in Mac and Linux application metadata.
* 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/file2string: change to python3wm42020-08-121-1/+1
| | | | | | The same was done to matroska.py before, so at least it's consistent. Doesn't matter for waf, because it imports this script (rather than executing it).
* TOOLS/autocrop.lua: automatically crop at startupヒカリ2020-06-011-84/+292
|
* umpv: convert to python 3wm42020-04-031-2/+2
| | | | Sigh.
* umpv: change from legacy FIFO to socketwm42020-03-281-23/+14
| | | | --input-file is deprecated, and the JSON IPC is saner anyway.
* ci: remove libass enablementJan Ekström2020-03-221-1/+0
| | | | This is no longer a configurable option.
* 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.)
* *.py: cosmetic changesjnozsc2020-02-273-5/+5
|
* 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.
* mac: activate logging when started from the bundleder richter2020-02-081-0/+1
| | | | | | | | | | 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
* osxbundle: simplify process_libraries() to eliminate leafs()Down Thomas2019-12-151-22/+8
| | | | | | | | | | | | | | Instead of traversing across leafs() which can lead to an infinite loop issue with cross-linked libraries, use the dictionary (libs_dict) created by libraries() to create a set (libs_set) of every unique library. Every value in libs_dict is also a key in libs_dict, so every unique library linked to mpv will be a key in libs_dict. Use set() on libs_dict to return a set of the keys from libs_dict, and remove binary from the set so that a duplicate of the binary is not added to the libs directory. Iterate over libs_set to bundle dylibs while using the libs_dict to determine which install_names to change.
* osc: use custom symbols for window controlsPhilip Langdale2019-12-115-1/+94
| | | | | | | | | | | | | | | | | | | | | | | | I was recently informed that unicode has official symbols for window controls, and I put together a change to use them, which worked, as long as a suitable font was installed. However, it's not that hard to get a normal system that lacks an appropriate font, and libass wants to print warnings if the symbols aren't in the default font, which will almost always be true. So, I gave up and added the symbols to the custom osd font that we already have. This ensures they are always available, and that they are aligned consistently on all platforms. I took the symbols from the `symbola` font, as this has a suitable licence and the symbols look nice enough. Symbola Licence: Fonts are free for any use; they may be opened, edited, modified, regenerated, packaged and redistributed. Finally, as we now have access to an un-maximize symbol, I added logic to use it when the window is maximized.
* 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
* zsh completion: move generation to runtime and improvePhilip Sequeira2019-09-271-283/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The completion function itself now parses --list-options on the first tab press and caches the results. This does mean a slight delay on that first tab press, but it will only do this if the argument being completed looks like an option (i.e. starts with "-"), so there is never a delay when just completing a file name. I've also put some effort into making it reasonably fast; on my machine it's consistently under 100 ms, more than half of which is mpv itself. Installation of zsh completion is now done unconditionally because it's nothing more than copying a file. If you really don't want it installed, set zshdir to empty: `./waf configure --zshdir= ...` Improvements in functionality compared to the old script: * Produces the right results for mpv binaries other than the one it was installed with (like a dev build for testing changes). * Does not require running mpv at build time, so it won't cause problems with cross compilation. * Handles aliases. * Slightly nicer handling of options that take comma-separated values and/or sub-options: A space is now inserted at the end instead of a comma, allowing you to immediately start typing the next argument, but typing a comma will still remove the automatically added space, and = and : will now do that too, so you can immediately add a sub-option. * More general/flexible handling of values for options that print their possible values with --option=help. The code as is could handle quite a few more options (*scale, demuxers, decoders, ...), but nobody wants to maintain that list here so we'll just stick with what the old completion script already did.
* osxbundle: remove rpath definitions towards dev toolsder richter2019-09-221-1/+22
| | | | | | | | since the loading order of rpaths is system wide lib path, dev tool path and then bundle lib path it's possible for the xcode swift libs to be incompatible with the libs the bundle was build with. this leads to possible segfaults. if we distribute the bundle we don't want to load the libs from the dev tools anyway.
* build: fix swift linking with upcoming xcode 11der richter2019-09-221-0/+8
| | | | | | | in xcode 11 the dynamic swift libraries were moved to a separated versioned swift folder, which can't be used for linking and only for distribution. additional to the std dynamic swift lib folder the system wide folder is needed for linking too.
* 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
* TOOLS/travis-rebuild-website: update condition after docker transitionRicardo Constantino2019-07-301-1/+1
| | | | Closes #6822
* osxbundle: bundle the dynamic swift std library when neededder richter2019-07-211-1/+20
|
* osxbundle: print the output of the dylib-unhell callder richter2019-07-211-2/+2
|
* appveyor: remove broken packages, install libplaceboJames Ross-Gowan2019-07-032-3/+1
| | | | | | | | Support for Ada and Objective-C was removed from MSYS2, which made pacman refuse to update GCC while the gcc-ada and gcc-objc packages were installed. Remove those packages before updating the others. Also remove ANGLE, which has been removed from MSYS2, and add libplacebo, which is now needed for the Vulkan VO.
* vo_gpu: d3d11: use the SPIRV-Cross C API directlyJames Ross-Gowan2019-06-122-5/+6
| | | | | | | | | | When the D3D11 backend was first written, SPIRV-Cross only had a C++ API and no guarantee of API or ABI stability, so instead of using SPIRV-Cross directly, mpv used an unofficial C wrapper called crossc. Now that KhronosGroup/SPIRV-Cross#611 is resolved, SPIRV-Cross has an official C API that can be used instead, so remove crossc and use SPIRV-Cross directly.
* appveyor: fix shaderc dependenciesJames Ross-Gowan2019-04-161-4/+3
| | | | | | Shaderc comes with a Python script that automatically fetches "known-good" versions of its dependencies. Use that instead of manually cloning dependencies to third-party.
* 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 abortablewm42018-05-241-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, they could be aborted only by ending playback, and calling mpv_abort_async_command didn't do anything. This requires furthering the mess how playback abort is done. The main reason why mp_cancel exists at all is to avoid that a "frozen" demuxer (blocked on network I/O or whatever) cannot freeze the core. The core should always get its way. Previously, there was a single mp_cancel handle, that could be signaled, and all demuxers would unfreeze. With external files, we might want to abort loading of a certain external file, which automatically means they need a separate mp_cancel. So give every demuxer its own mp_cancel, and "slave" it to whatever parent mp_cancel handles aborting. Since the mpv demuxer API conflates creating the demuxer and reading the file headers, mp_cancel strictly need to be created before the demuxer is created (or we couldn't abort loading). Although we give every demuxer its own mp_cancel (as "enforced" by cancel_and_free_demuxer), it's still rather messy to create/destroy it along with the demuxer.
| *