summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* various: fix typosHarri Nieminen2023-03-281-1/+1
| | | | Found by codespell
* vf_gpu: initialize depth=1 on target texturesaverne2023-02-281-0/+1
| | | | | According to internal documentation, 2D textures should have d=1. This fixes the correctness of the API usage, not any bug.
* options: transition commands from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-0/+1
|
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-215-33/+30
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-203-6/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* mp_image: forward AV_FRAME_DATA_DOVI_RPU_BUFFER side dataquietvoid2023-02-191-1/+3
| | | | When available, and ignored if `vf=format:dolbyvision=no`.
* vf_sub: undeprecateDudemanguy2023-02-111-2/+0
| | | | | | | | | | 3a9e661e929c34d25810fa903abbd9961f73ecef officially made this video filter deprecated roughly 6 years ago. Every other video filter in that commit has actually been removed since then except for vf_sub. ffmpeg does have its own subtitles filter, but it doesn't have the same control over scale like vf_sub does. That's probably why wm4 never actually removed it. Let's stop scaring users with a warning since this filter probably won't ever get removed. Closes #9254.
* various: replace if + abort() with MP_HANDLE_OOM()sfan52023-01-123-8/+4
| | | | | MP_HANDLE_OOM also aborts but calls assert() first, which will result in an useful message if compiled in debug mode.
* filters: lavfi: allow hwdec_interop selection for filtersPhilip Langdale2022-09-212-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, lavfi filters are provided a hw_device from the first hwdec_interop that was loaded, regardless of whether it's the right one or not. In most situations where a hardware based filter is used, we need more control over the device. In this change, a `hwdec_interop` option is added to the lavfi wrapper filter configuration and this is used to pick the correct hw_device to inject into the filter or graph (in the case of a graph, all filters get the same device). Note that this requires the use of the explicit lavfi syntax to allow for the extra configuration. eg: ``` mpv --vf=hwupload ``` becomes ``` mpv --vf=lavfi=[hwupload]:hwdec_interop=cuda-nvdec ``` or ``` mpv --vf=lavfi-bridge=[hwupload]:hwdec_interop=cuda-nvdec ```
* vo: hwdec: do hwdec interop lookup by image formatPhilip Langdale2022-09-213-3/+3
| | | | | | | | | | | | | | It turns out that it's generally more useful to look up hwdecs by image format, rather than device type. In the situations where we need to find one, we generally know the image format we're dealing with. Doing this avoids us having to create mappings from image format to device type. The most significant part of this change is filling in the image format for the various hw interops. There is a hw_imgfmt field today today, but only a couple of the interops fill it in, and that seems to be because we've never actually used this piece of metadata before. Well, now we have a good use for it.
* vf_format: support forwarding/stripping film grain metadataLynne2022-04-051-0/+6
|
* vo_gpu[_next]: hwdec: fix logging regression when probingPhilip Langdale2022-03-211-1/+5
| | | | | | | | | When I introduced the concept of lazy loading of hwdecs by img format, I did not propagate the probing flag correctly, leading to the new normal loading path not runnng with probing set, meaning that any errors would show up, creating unnecessary noise. This change fixes this regression.
* vo_gpu: hwdec: load hwdec interops on-demand by defaultPhilip Langdale2022-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, we have treated hwdec interop loading as a completely separate step from loading the hwdecs themselves. Some hwdecs need an interop, and some don't, and users generally configure the exact hwdec they want, so interops that aren't relevant for that hwdec shouldn't be loaded to save time and avoid warning/error spam. The basic approach here is to recognise that interops are tied to hwdecs by imgfmt. The hwdec outputs some format, and an interop is needed to get that format to the vo without read back. So, when we try to load an hwdec, instead of just blindly loading all interops as we do today, let's pass the imgfmt in and only load interops that work for that format. If more than one interop is available for the format, the existing logic (whatever it is) will continue to be used to pick one. We also have one callsite in filters where we seem to pre-emptively load all the interops. It's probably possible to trace down a specific format but for now I'm just letting it keep loading all of them; it's no worse than before. You may notice there is no documentation update - and that's because the current docs say that when the interop mode is `auto`, the interop is loaded on demand. So reality now reflects the docs. How nice.
* vf_format: simplify frame type checking after addition of DoVi optionJan Ekström2022-02-061-1/+5
| | | | | | | | | | | We only wish to touch actual video frames, which should have an allocated image attached to them, so just check the frame type early, and exit by passing through such non-video frames to further filters in the chain without attempting to process them. Fixes a crash in case of non-video (EOF/NONE) frames being passed onto the filter when the dovi option was set to false since 05ccc51d53424a771ece5bb818713d474d7874ce .
* vf_format: add dolbyvision sub-optionNiklas Haas2022-01-091-2/+8
| | | | | | | | | | Useful to strip dolbyvision from the output, in cases where the user does not want it applied. Doing this as a video filter gives users the abiilty to easily toggle this stripping at runtime in a way that properly propagates to any (potentially stateful) VO. It also thematically fits the rest of the options in vf_format, which are similarly concerned with modifying the video image parameters.
* vf_sub: restore OSD if removedYour Name2021-05-071-0/+9
| | | | | | | When inserting vf_sub, the VO OSD is directed not to draw itself. But this flag was never unset, even when removing vf_sub. The fix is pretty shit, but appears to work.
* draw_bmp: rewritewm42020-05-091-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | draw_bmp.c is the software blender for subtitles and OSD. It's used by encoding mode (burning subtitles), and some VOs, like vo_drm, vo_x11, vo_xv, and possibly more. This changes the algorithm from upsampling the video to 4:4:4 and then blending to downsampling the OSD and then blending directly to video. This has far-reaching consequences for its internals, and results in an effective rewrite. Since I wanted to avoid un-premultiplying, all blending is done with premultiplied alpha. That's actually the sane thing to do. The old code just didn't do it, because it's very weird in YUV fixed point. Essentially, you'd have to compensate for the chroma centering constant by subtracting src_alpha/255*128. This seemed so hairy (especially with correct rounding and high bit depths involved) that I went for using float. I think it turned out mostly OK, although it's more complex and less maintainable than before. reinit() is certainly a bit too long. While it should be possible to optimize the RGB path more (for example by blending directly instead of doing the stupid float conversion), this is probably slower. vo_xv users probably lose in this, because it takes the slowest path (due to subsampling requirements and using YUV). Why this rewrite? Nobody knows. I simply forgot the reason. But you'll have it anyway. Whether or not this would have required a full rewrite, at least it supports target alpha now (you can for example hard sub transparent PNGs, if you ever wanted to use mpv for this). Remove the check in vf_sub. The new draw_bmp.c is not as reliant on libswscale anymore (mostly uses repack.c now), and osd.c shows an error message on missing support instead now. Formats with chroma subsampling of 4 are not supported, because FFmpeg doesn't provide pixfmt definitions for alpha variants. We could provide those ourselves (relatively trivial), but why bother.
* vf:format: don't error when using convert=yes and not specifying fmtwm42020-05-061-1/+1
|
* video: add alpha type metadatawm42020-04-241-0/+4
| | | | | | | | | This is mostly for testing. It adds passing through the metadata through the video chain. The metadata can be manipulated with vf_format. Support for zimg alpha conversion (if built with zimg after it gained alpha support) is implemented. Support premultiplied input in vo_gpu. Some things still seem to be buggy.
* 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.
* vf_format: add gross mechanism for forcing scaler for testingwm42020-04-131-0/+7
| | | | | | | | | | | This sucks, but is helpful for testing. Obviously, it would be much nicer if there were a way to specify _all_ scaler options per filter (if the user wanted), instead of always using the global options. But this is "too hard" for now. For testing, it is extremely convenient to select the scaler backend, so add this option, but make clear that it could go away. We'd delete it once there is a better mechanism for this.
* options: change option macros and all option declarationswm42020-03-188-62/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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_format: add w, h parameterswm42020-02-091-3/+11
| | | | Yes, this thing became vf_scale through the back door.
* vf_gpu: render subtitleswm42019-11-301-1/+9
| | | | | | | Pretty annoying affair. The vo_gpu code could of course not trigger rendering from filters yet, so it needed to be extended. Also, this uses some icky stuff made for vf_sub (and this was the reason I marked vf_sub as deprecated), so everything is terrible.
* vf_gpu: add video filter using vo_gpu's rendererwm42019-11-291-0/+364
| | | | | | | | | Probably pretty useless in this form (see: the wall of warnings), but someone wanted this. I think this should be useful to perform some automated tests, maybe. Fixes: #7194
* sws_utils, zimg: destroy vo_x11 and vo_drm performancewm42019-10-311-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
* filters: extend vf_format so that it can convert color parameterswm42019-10-211-36/+52
| | | | | | | | | | | | | | | | | | | | | | | | | Form some reason (and because of my fault), vf_format converts image formats, but nothing else. For example, setting the "colormatrix" sub-parameter would not convert it to the new value, but instead overwrite the metadata (basically "reinterpreting" the image data without changing it). Make the historical mistake worse, and go all the way and extend it such that it can perform a conversion. For compatibility reasons, this needs to be requested explicitly. (Maybe this would deserve a separate filter to begin with, but things are messed up anyway. Feel free to suggest an elegant and simple solution.) This demonstrates how zimg can properly perform some conversions which swscale cannot (see examples added to vf.rst). Stupidly this requires 2 code paths, one for conversion, and one for overriding the parameters. Due to the filter bullshit (what was I thinking), this requires quite some acrobatics that would not be necessary without these abstractions. On the other hand, it'd definitely be more of a mess without it. Oh whatever.
* vf_fingerprint: don't print fallback warning on each framewm42019-10-211-2/+0
| | | | | | | | f_reset, which is called on seeks, was a good place for resetting the warning flag (so the warning would be print again). Except some other code abused f_reset when all metadata was read (in both cases you want to clear the metadata). Instead of spending more time on getting this flag reset correctly, just never reset it.
* vf_fingerprint: remove single-plane optimizationwm42019-10-201-31/+1
| | | | | | | | | | | | | | According to the zimg author, YUV->GREY conversion does not even read the chroma planes, as long as no matrix conversion is involved. Since we try to avoid the latter anyway by forcing the source parameters on the target image, passing only the Y plane will not help with anything. An unscientific test seems to confirm this, so remove this. This would probably help with libswscale (I didn't test this), but on the other hand, libswscale will rarely be used in cases where we can extract the Y plane. (Except nv12, which should probably be added to the zimg wrapper's unpacking.)
* vf_fingerprint: use generic zimg wrapperwm42019-10-201-79/+29
| | | | | Don't duplicate the API usage. The result should be approximately the same.
* video, demux: rip out unused spherical metadata codewm42019-10-171-14/+0
| | | | | | This was preparation into something that never happened. Spherical video is a shit idea anyway.
* video: remove mp_image_params.hw_flags fieldwm42019-10-171-1/+0
| | | | | | | | This was speculatively added 2 years ago in preparation for something that apparently never happened. The D3D code was added as an "example", but this too was never used/finished. No reason to keep this.
* vf_d3d11vpp: remove RGB conversion hackwm42019-10-161-49/+5
| | | | | | | With the previous commit, this is dead code. This also makes the f_autoconvert.c code for this dead code (fortunately). Will probably remove this later.
* vf_fingerprint: fix an obvious memory leakwm42019-10-031-4/+12
| | | | | | Leaks the entire zimg state on filter deinit. Not sure what I was thinking; with some luck, I just didn't give a shit about this case, but most likely I was thinking the same thing as always: nothing.
* 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.
* video: remove vf_vavpp from automatic deinterlace propertywm42019-10-021-9/+0
| | | | | | | | | | | | | | This reverts commit 6385a5fd1b8a67c051b82d48c993a6591e8f93c6, and in addition removes the code that automatically inserts the vavpp filter. The reason is the same as the commit that is being reverted: this filter seems to trigger driver bugs. It can cause GPU freezes or just doesn't work. This variant of disabling the filter is better. There was no way to add the "force" parameter to the automatically inserted filter, so the old approach just made manual filter insertion (with the --vf option or "vf" command) more cumbersome.
* vf_fingerprint: remove extraneous single quote from descriptionJan Ekström2019-09-211-1/+1
| | | | | | This happened to break ZSH completion and seemed to be extraneous. Reported by LaserEyess on IRC.
* vf_fingerprint: use aligned_alloc instead of posix_memalignwm42019-09-191-2/+2
| | | | | | | | | | | I was assuming posix_memalign was the most portable function to use, but MinGW does not provide it for some reason. Switch to C11 aligned_alloc() which someone suggested was provided by MinGW (but actually isn't, someone probably confused it with the incompatible _aligned_malloc), and add a configure check. Even though it turned out that MinGW doesn't provide it, the function is slightly more elegant than posix_memalign(), so stay with it.
* video: add vf_fingerprint and a skip-logo scriptwm42019-09-191-0/+293
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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_vavpp: disable this filterwm42019-09-151-0/+9
| | | | | Might be unreasonable, but I'm angry at the shit driver freezing my machine.
* 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: remove internal stereo_out flagwm42018-04-291-5/+1
| | | | | | Also rename stereo3d to stereo_in. The only real change is that the vo_gpu OSD code now uses the actual stereo 3D mode, instead of the --video-steroe-mode value. (Why does this vo_gpu code even exist?)
* 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_vavpp: select best quality deinterlacing algorithm by defaultwm42018-02-131-5/