summaryrefslogtreecommitdiffstats
path: root/video/filter/vf_vapoursynth.c
Commit message (Collapse)AuthorAgeFilesLines
* csputils: replace mp_chroma_location with pl_chroma_locationKacper Michajłow2024-01-221-1/+1
|
* csputils: replace mp_colorspace with pl_color_spaceKacper Michajłow2024-01-221-3/+4
|
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-051-37/+37
|
* vf_vapoursynth: set crop metadata after mapping vapoursynth frameKacper Michajłow2023-10-311-0/+2
| | | | | | | | Vapoursynth does not provide crop metadata and input one is likely to be invalidated during filtering. Set crop to full frame if image dimensions were changed during filtering. Fixes: #12780
* vf_vapoursynth: set nominal_fps after the filterchainikdn2023-10-211-1/+4
|
* vf_vapoursynth: save display resolution as a variableDudemanguy2023-08-131-0/+8
| | | | | | | | | | | | | | mpv has a generic method for getting the display resolution, so we can save it in vf_vapoursynth without too much trouble. Unfortunately, the resolution won't actually be available in many cases (like my own) because the windowing backend doesn't actually know it yet. It looks like at least windows always returns the default monitor (maybe we should do something similar for x11 and wayland), so there's at least some value. Of course, this still has a bunch of pitfalls like not being able to cope with multi monitor setups at all but so does display_fps. As an aside, the vapoursynth API this uses apparently requires R26 (an ancient version anyway), so bump the build to compensate for this. Fixes #11510
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-201-2/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* video: change chroma_w/chroma_h fields to use shift instead of sizewm42020-04-231-17/+17
| | | | | | | | | | When I added mp_regular_imgfmt, I made the chroma subsampling use the actual chroma division factor, instead of a shift (log2 of the actual value). I had some ideas about how this was (probably?) more intuitive and general. But nothing ever uses non-power of 2 subsampling (except jpeg in rare cases apparently, because the world is a bad place). Change the fields back to use shifts and rename them to avoid mistakes.
* options: change option macros and all option declarationswm42020-03-181-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* vf_vapoursynth: fix crashing memory management mistakewm42019-10-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As pointed out by @olifre in #7016, this line of code was wrong. p->opts at this point is a struct allocated and managed by m_config. opts->file is a string, and m_config explicitly frees it on destruction. The line of code in question replaced the opts->file value, and made both the old and new value children of the talloc allocation, so they were _also_ freed on destruction. This crashed due to a double-free. First, talloc auto-freeing freed the string, then m_config explicitly called talloc_free() on the stale pointer again. As @v-fox pointed out, commit 36dd2348a1e1 seems to have triggered the crash. I suspect this code merely worked out of coincidence, since it allowed m_config to free the value first. This removed it from the auto-free list, and thus did not result in a double-free. The change in order of calling alloc destructors changed the order of these calls. There is no strong reason why new behavior (as introduced by commit 36dd2348a1e1) would be wrong (it feels like cleaner behavior). On the other hand, what the vf_vapoursynth code did is clearly unclean and going by the m_config API, you're not at all supposed to do this. m_config manages all memroy referenced by option structs, the end. @olifre's suggested fix also would have been correct (not just hiding the issue), I prefer my fix, as it doesn't mess with the option struct in tricky ways. This wouldn't have happened if mpv were written in Haskell.
* vf_vapoursynth: do not call vsscript_finalize() if init failedwm42019-10-031-1/+5
| | | | | If vsscript_finalize() is not matched by a successful vsscript_init(), an assert in the vsscript library triggers. Makes sense, I guess.
* vf_vapoursynth: remove some Lua backend remainswm42019-10-031-6/+0
| | | | Pretty funny.
* vf_vapourynth: remove Lua backendwm42019-09-191-241/+1
| | | | | | | | | | | | | | | I once created this because someone wanted to use vapoursynth without the Python dependency. No idea if anyone ever actually used it. It's sort of icky (it calls itself "lazy" to preempt complaints about how much it sucks), and complicates the build process. Kill it. It seems much more promising to have something like this: https://github.com/vapoursynth/vapoursynth/issues/386 This would either solve the build distribution problem by relaxing the Python dependency, and/or allow a Lua backend to be included without pain.
* vf_vapoursynth: allow multithreaded writing of source framesChainik2019-07-081-0/+3
|
* vf_vapoursynth: allow multithreaded reading of returned framesChainik2019-07-081-8/+9
|
* vf_vapoursynth: correctly signal error on script init failurewm42018-04-291-0/+1
| | | | Otherwise it will do nothing, waiting on nothing forever.
* video: pass through container fps to filterswm42018-04-191-6/+4
| | | | | | | | | | | | This means vf_vapoursynth doesn't need a hack to work around the filter code, and libavfilter filters now actually get the frame_rate field on input pads set. The libavfilter doxygen says the frame_rate field is only to be set if the frame rate is known to be constant, and uses the word "must" (which probably means they really mean it?) - but ffmpeg.c sets the field to mere guesses anyway, and it looks like this normally won't lead to problems.
* vf_vapoursynth: fix freezewm42018-02-201-5/+7
| | | | | | | Commit 59f9547fb56b missed this case, in which we can't make new progress and have to exit. Fixes #5548.
* vf_vapoursynth: always keep input frame array filledwm42018-02-031-1/+3
| | | | | | | | In theory (and practice), this is not needed, because the VS filter get frame callback will cause the process function to be called again if there's not enough data. But it's still a bit weird to just add one more frame on each iteration, so make it cleaner and make it request frames until the input array is full.
* vf_vapoursynth: fix lockingwm42018-02-031-1/+2
| | | | | | | | This was obviously nonsense, and a previous "fix" to this code was nonsense too. What is really needed here is temporarily dropping the lock while calling destroy_vs()/reinit_vs(). Fixes #5470.
* vf_vapoursynth: fix obscure/impossible leakwm42018-02-031-0/+1
| | | | | | | Unknown frames were not freed properly. Although this doesn't really happen anyway, because we're never going to feed audio frames to a video filter chain. Since it's theoretically possible, and all other filters handle this consistently, fix it anyway.
* vf_vapoursynth: fix output colorspace flags and other attributeswm42018-02-031-0/+2
| | | | | | | Properly initialize the output frame parameters other than image format and size. This includes colorspace hints. (We're still not reading them back from VapourSynth if it sets them, though. Usually it doesn't anyway.)
* vf_vapoursynth: fix potential deadlock on init failurewm42018-02-031-1/+1
| | | | | When VS initialization failed, it could hang due to forgetting to release the mutex.
* vf_vapoursynth: initialize start timestamp properlywm42018-02-031-1/+1
| | | | | | | | | VapourSynth can't pass through timestamps, only frame durations. So we need to remember the timestamp of the very first frame passed to it. This was accidentally set to 0 instead of NOPTS on init, so inserting the filter during playback could show strange behavior. Might be part of #5470.
* video: rewrite filtering glue codewm42018-01-301-336/+346
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Get rid of the old vf.c code. Replace it with a generic filtering framework, which can potentially handle more than just --vf. At least reimplementing --af with this code is planned. This changes some --vf semantics (including runtime behavior and the "vf" command). The most important ones are listed in interface-changes. vf_convert.c is renamed to f_swscale.c. It is now an internal filter that can not be inserted by the user manually. f_lavfi.c is a refactor of player/lavfi.c. The latter will be removed once --lavfi-complex is reimplemented on top of f_lavfi.c. (which is conceptually easy, but a big mess due to the data flow changes). The existing filters are all changed heavily. The data flow of the new filter framework is different. Especially EOF handling changes - EOF is now a "frame" rather than a state, and must be passed through exactly once. Another major thing is that all filters must support dynamic format changes. The filter reconfig() function goes away. (This sounds complex, but since all filters need to handle EOF draining anyway, they can use the same code, and it removes the mess with reconfig() having to predict the output format, which completely breaks with libavfilter anyway.) In addition, there is no automatic format negotiation or conversion. libavfilter's primitive and insufficient API simply doesn't allow us to do this in a reasonable way. Instead, filters can use f_autoconvert as sub-filter, and tell it which formats they support. This filter will in turn add actual conversion filters, such as f_swscale, to perform necessary format changes. vf_vapoursynth.c uses the same basic principle of operation as before, but with worryingly different details in data flow. Still appears to work. The hardware deint filters (vf_vavpp.c, vf_d3d11vpp.c, vf_vdpaupp.c) are heavily changed. Fortunately, they all used refqueue.c, which is for sharing the data flow logic (especially for managing future/past surfaces and such). It turns out it can be used to factor out most of the data flow. Some of these filters accepted software input. Instead of having ad-hoc upload code in each filter, surface upload is now delegated to f_autoconvert, which can use f_hwupload to perform this. Exporting VO capabilities is still a big mess (mp_stream_info stuff). The D3D11 code drops the redundant image formats, and all code uses the hw_subfmt (sw_format in FFmpeg) instead. Although that too seems to be a big mess for now. f_async_queue is unused.
* msg: reinterpret a bunch of message levelsNiklas Haas2017-12-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
* vf_vapoursynth: fix inverted sign and restore 10 bit supportwm42017-08-071-1/+1
| | | | Fixes #4720, I think.
* video: drop some more IMGFMT aliaseswm42017-06-291-23/+52
| | | | | | | | | | | For vo_opengl and vo_direct3d, these are supported in a generic way. For vf_vapoursynth, we could probably map its VSFormat struct in a generic way, but for now do some bullshit. vf_eq.c actually loses support for these formats. We could add generic support too (anything that has 8 bit planes will work), but why bother. The filter is deprecated anyway.
* options: add M_OPT_FILE to some more file optionsPhilip Sequeira2017-03-061-1/+1
| | | | (Helps shell completion.)
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-031-3/+3
| | | | | | | | | | | | | | | | | | This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
* vf_vapoursynth: fix everythingwm42015-12-201-17/+13
| | | | | | | Broken by commit 0a0bb905. The changes to this filter were accidentally simply not tested, and it was obviously broken in a bunch of ways. Fixes #2616.
* video: switch from using display aspect to sample aspectwm42015-12-191-6/+1
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* vf: remove old config() callbackwm42015-12-191-16/+15
|
* vf_vapoursynth: relicense to LGPL 2.1+wm42015-07-191-7/+7
| | | | | | | | | This was requested by someone. All code was written by myself; some minor changes by 2 contributors who agreed to general LGPL relicensing. 1 line of code is by someone unknown who possibly wasn't asked (setting the "display_fps" variable), and which can be reasonably ignored as it makes up only 0.1% of the file.
* vf_vapoursynth: reject unaligned video sizeswm42015-05-151-0/+7
| | | | Leads to some nice memory corruption otherwise.
* vf_vapoursynth: update _FieldBased semanticswm42015-04-231-4/+4
| | | | These changed in VapourSynth. Also, "_Field" is now unused.
* vf_vapoursynth: stupid hack to unbreak with recent API changewm42015-04-201-0/+6
| | | | | | | | Vapoursynth made an incompatible API change: clips with unknown length are not supported anymore. In fact, Vapoursynth abort()s the program (which by the way invalidate all of its claims of API/ABI stability). So add some nonsense to make it work again.
* vf_vapoursynth: handle approximate EOF drainingwm42015-03-251-9/+28
| | | | | | | | | | | | | Handling this perfectly with VapourSynth is probably not possible: you either need to tell it the total number of input frames in advance, or deliver an infinite stream. With playback, EOF can happen at an unpredictable point, for which the VapourSynth API has no mechanism at all. We handle EOF by returning an error to the filter, which will the filter return all pending frame callbacks. We still can try to handle it approximately: if the filter requests a frame past EOF, then send it an error. This seems to work relatively well with filters which don't request future frames.
* vf_vapoursynth: replace a hack with a newer VS API functionwm42015-02-161-1/+1
| | | | | The new function does exactly what we need. Replaces the old hack, which created the vscore by running an empty script.
* vf_vapoursynth: add display refresh rate propertyJulian2015-02-131-0/+1
| | | | | This value is not necessarily trustworthy (it might change) and can be 0.
* vf_vapoursynth: load Lua stdlib in Lua modewm42015-01-291-0/+1
| | | | If you can call this a "stdlib".
* ta: rename MP_TALLOC_ELEMS to MP_TALLOC_AVAILBen Boeckel2015-01-271-2/+2
| | | | | The macro actually returns the *available* space in the array, not how much is actually filled in.
* video: remove vfcap.hwm42015-01-211-1/+1
| | | | | | | | | | | | | | | | | And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is supposed to reduce conversions if many filters are used (with many incompatible pixel formats), and also for preferring the VO's natively supported pixel formats (as opposed to conversion). This is worthless by now. Not only do the main VOs not use software conversion, but also the way vf_lavfi and libavfilter work mostly break the way the old MPlayer mechanism worked. Other important filters like vf_vapoursynth do not support "proper" format negotation either. Part of this was already removed with the vf_scale cleanup from today. While I'm touching every single VO, also fix the query_format argument (it's not a FourCC anymore).
* vf_vapoursynth: autodetect CPU countwm42015-01-051-3/+8
| | | | | | | | This adds an "auto" choice to the concurrent-frames suboption, and makes it the default. I'm not so sure about making this the default, though. It could lead to excessive buffering with large CPU counts. But we'll see.
* vf_vapoursynth: fix Lua backendwm42015-01-031-0/+3
| | | | It couldn't handle the newly added float variable.
* vf_vapoursynth: pass through container FPS valuewm42015-01-031-0/+1
| | | | | | | | This is basically a hack; but apparently a needed one, since many vapoursynth filters insist on having a FPS set. We need to apply the FPS override before creating the filters. Also change some terminal output related to the FPS value.
* video: better pipelining with vf_vapoursynthwm42015-01-031-0/+14
| | | | | | | | | | Most of this is explained in the code comments. This change should improve performance with vapoursynth, especially if concurrent requests are used. This should change nothing if vf_vapoursynth is not in the filter chain, since non-threaded filters obviously can not asynchronously finish filtering of frames.
* vf_vapoursynth: add debug message when returning error from GetFramewm42014-10-131-0/+1
| | | | | Some filters still (or will) behave badly on these errors, so explicitly log when it happens.
* vf_vapoursynth: don't error if invoke() doesn't return a clipwm42014-10-121-3/+2
| | | | | Not all functions are for creating filters. Consider for example LoadPlugin.
* vf_vapoursynth: resolve paths relative to home/configwm42014-10-121-0/+3
| | | | | This affects the script filename passed to the filter. Resolve "~" (and some other variants) as described in the "Paths" section of mpv.rst.
* vf_vapoursynth: add standalone Lua scriptingwm42014-10-121-0/+257
|
* vf_vapoursynth: abstract scripting backendwm42014-10-121-28/+87
| | | | | | In theory, vsscript should be doing it, but it's not there yet, neither did there seem to be any interest in making it flexible enough to handle more than 1 scripting language.
* vf_vapoursynth: return dummy frames if frames are requested during initwm42014-10-111-1/+12
| | | | | | An attempt at fixing #1168. I see black frames flashing, so it's certainly not perfect.
* vf_vapoursynth: factor stuffwm42014-10-111-13/+25
|
* vf_vapoursynth: when seeking, recreate only if it's already createdwm42014-10-111-1/+2
|
* vf_vapoursynth: fail gracefully if filter init requests frameswm42014-10-111-0/+10
| | | | | | | | | | | | | | | | | Some VS filters will requests frames from their parent filters while they're initialized. Thy do this in a blocking manner, and initialization will not succeed until the frame request is satisfied. This deadlocked mpv, because we can feed frames to the filter only after initialization is finished. Return an error instead of deadlocking. Note that we (probably) can handle frames being requested during init fine, as long as the requests don't block initialization. But we can distinguish this situation, and a simple test seems to indicate VS usually doesn't do this. See #1168.
* vf_vapoursynth: make it possible