summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* vf_gpu: vulkan and egl implementationsShreesh Adiga4 days4-80/+294
| | | | | | | | Abstract out EGL, and allow choosing between EGL and vulkan at runtime. vf_gpu_egl.c contains GL specific context and creation/destroy code, vf_gpu_vulkan.c contains Vulkan specific. This allows vf_gpu being built in systems where EGL is not available and where Vulkan is available.
* vf_format: add hdr10plus sub-parameter to format video filterKacper Michajłow2024-03-091-0/+10
|
* mp_image: add Dolby Vision metadata mappingKacper Michajłow2024-03-091-2/+21
| | | | | Remove side-loading metadata in vo_gpu_next.c and remove unneded side-data duplication.
* mp_image: add mp_image_params_static_equal for finer comparisionKacper Michajłow2024-03-092-3/+5
| | | | In case of dynamic HDR metadata is present.
* video/filter: add field order support for built in deinterlacers1nsane0002024-03-045-3/+43
| | | | | | refqueue gets the field of the frame from mp_image which almost always(if not always) assumes bottom field order first. By default this behavior should not change but specifying the field order should bypass this.
* options: add --deinterlace-field-parity option1nsane0002024-03-041-0/+4
| | | | | | | | Previously there was no way to specify the field order of interlaced videos when deinterlacing with inbuilt filters. Lavfi deinterlacers seemed to prefer top field order while inbuilt ones (vdpaupp, vavpp, d3d11vpp) seemed to prefer bottom field order. The default "auto" option should work exactly as before while specifying either "tff" or "bff" should force the specified field order
* all: add missing repr assignmentsKacper Michajłow2024-01-261-0/+1
| | | | Fixes: 66e451f4
* csputils: replace mp_chroma_location with pl_chroma_locationKacper Michajłow2024-01-222-2/+2
|
* csputils: replace mp_alpha_type with pl_alpha_modeKacper Michajłow2024-01-221-2/+2
|
* csputils: replace mp_colorspace with pl_color_spaceKacper Michajłow2024-01-225-21/+22
|
* vo_gpu: don't pass ra_fbo by valueKacper Michajłow2023-11-281-1/+1
| | | | Make it easier on compiler, no need to alloca and copy things around.
* various: replace some OOM handlingsfan52023-11-241-2/+1
| | | | | | We prefer to fail fast rather than degrade in unpredictable ways. The example in sub/ is particularly egregious because the code just skips the work it's meant to do when an allocation fails.
* ALL: use pl_hdr_metadata and nuke sig_peakKacper Michajłow2023-11-051-5/+3
| | | | | | | | This commit replaces all uses of sig_peak and maps all HDR metadata. Form notable changes mixed usage of maxCLL and max_luma is resolved and not always max_luma is used which makes vo_gpu and vo_gpu_next behave the same way.
* csputils: add pl_hdr_metadata to mp_colorspace and deprecate sig_peakKacper Michajłow2023-11-051-1/+3
| | | | | Note this commit does not change all uses of sig-peak, this is for future refactoring.
* 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
|
* options: remove ancient option fallbacks/deprecationDudemanguy2023-09-211-2/+0
| | | | | | | | | | | | | We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting around in the code. This is harmless, but the vast majority of these are ancient. 26f4f18c0629998a9b91e94722d166866d8b80a3 is the last commit that touched the majority of these and of course that only changed how options were declared so all of this stuff was deprecated even before that. No use in keeping these, so just delete them all. As an aside, there was actually a cocoa_opts but it had only a single option which was replaced by something else and empty otherwise. So that entire thing was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were added in 0.35 or later were kept as is.
* 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
* mp_image: abort on av_buffer_ref() failureNRK2023-06-281-1/+0
| | | | | | | | | | | | | | this changes mp_image_new_ref() to handle allocation failure itself instead of doing it at its many call-sites (some of which never checked for failure at all). also remove MP_HANDLE_OOM() from the call sites since this is not necessary anymore. not all the call-sites have been touched, since some of the caller might be relying on `mp_image_new_ref(NULL)` returning NULL. Fixes: https://github.com/mpv-player/mpv/issues/11840
* f_hwtransfer: disable vulkan multiplane images when uploading from cudaPhilip Langdale2023-05-281-1/+2
| | | | | | | | | | | | | | | | Although we can support vulkan multiplane images, cuda lacks any such support, and so cannot natively import such images for interop. It's possible that we can do separate exports for each plane in the image and have it work, but for now, we can selectively disable multiplane when we know that we'll be consuming cuda frames. As a reminder, even though cuda is the frame source, interop is one way so the vulkan images have to be imported to cuda before we copy the frame contents over. This logic here is slightly more complex than I'd like but you can't just set the flag blindly, as it will cause hwframes ctx creation to fail if the format is packed or if it's planar rgb. Oh well.
* 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/