summaryrefslogtreecommitdiffstats
path: root/video/filter/vf.c
Commit message (Collapse)AuthorAgeFilesLines
* build: add preliminary LGPL modewm42017-09-211-4/+5
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* vf_eq: remove this filterwm42017-08-221-2/+0
| | | | | | | | | Both the video equalizer command/option glue, which drives this filter, as well as the filter itself are slightly GPL contaminated. So it goes. After this commit, "--vf=eq" will actually use libavfilter's vf_eq (if FFmpeg was compiled in GPL mode), but it has different options and will not listen to the equalizer VOCTRLs.
* video: add metadata handling for spherical videowm42017-08-211-1/+1
| | | | | | | | | | | | | | This adds handling of spherical video metadata: retrieving it from demux_lavf and demux_mkv, passing it through filters, and adjusting it with vf_format. This does not include support for rendering this type of video. We don't expect we need/want to support the other projection types like cube maps, so we don't include that for now. They can be added later as needed. Also raise the maximum sizes of stringified image params, since they can get really long.
* vf_dlopen: remove this filterwm42017-06-181-4/+0
| | | | | | | | | | | | | | | | It was an attempt to move some MPlayer filters (which were removed from mpv) to external, loadable filters. That worked well, but then the MPlayer filters were ported to libavfilter (independently), so they're available again. Also there is a more widely supported and more advanced loadable filter system supported by mpv: vapoursynth. In conclusion, vf_dlopen is not useful anymore, confusing, and requires quite a bit of code (and probably wouldn't survive the rewrite of the mpv video filter chain, which has to come at some point). It has some implicit dependencies on internal conventions, like possibly the format names dropped in the previous commit. We also deprecated it last release. Drop it.
* af, vf: improvements to libavfilter bridgewm42017-05-311-1/+7
| | | | | | Add the "lavfi-" prefix (details see manpage additons). Tag the filter name as "(lavfi)" in the verbose filter list output.
* vf.c, vf.h: change license to LGPLwm42017-05-111-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most authors have agreed. Like with vo.c, we don't take module declarations into consideration (see 0e09533c73dc0). Notable issues: 115bfb9762: the author has (probably) not agreed. The vf.c changes were removed with the removal of filter DR, though (see c54fc507da8e). 7b25afd742: the same author adds VOCTRLs for deinterlacing switching at runtime. Put them under a HAVE_GPL ifdef just to be sure. (It looks like we could remove the VOCTRLs immediately, as they're needed only for some compatibility things, but no need to do that yet.) 02b199e5e9: the author had a conditional agreement to LGPL, which doesn't allow us to change it just yet, but the code added here was completely removed anyway. (These days, the pts is passed as mp_image field, and put_image is gone.) 3532cd532e: same author, but code removed with DR removal. f0626e2f8d: same author, but code was moved to mp_image.c. e5b4b495c3: agreed to LGPLv3+ only, but the code was removed in cfa1f9e082 anyway. 086c324692: author was not asked - minor warning fix, but no mpv includes malloc.h anymore. e9d0a1d609: author was not asked - removed again in 33b62af947. c260a1139d: author could not be reached - but this code was removed when mpv changed the image allocation code to essentially use FFmpeg's pixdesc.
* vf: fix another broken case of conversion filter auto-insertionwm42017-04-051-0/+37
| | | | | | | | | | | | | | | | | | | | If the VO doesn't support a format output by vf_lavfi, no conversion filter was inserted, and filter chain creation failed. This is because vf_lavfi doesn't properly follow the format negotiation model, which means the format negotiation pass does not catch all cases where conversion is needed. Specifically, vf_lavfi supports that all output formats are supported for any given input format, but then does not actually call vf_next_query_format() in reconfig() to check which format it uses, but outputs whatever it gets from libavfilter. I think this is ok to avoid excessive complexity in vf_lavfi.c, but it also means adding more kludges to vf.c. I justify this (and the code duplication) with the idea that the current filter chain code will die anyway at some point. The .log field additions for c->first/c->last are strictly speaking not needed, but useful for debugging.
* video: add automatic libavfilter bridge to option parsingwm42017-04-021-2/+25
| | | | | | | | | | Now you can for example do "--vf=hue=h=60" - there is no "hue" filter in mpv, so libavfilter's will be used. This has certain caveats (see manpage). The point of this is providing a relatively smooth transition path to removing our own filter stuff.
* video: deprecate almost all video filterswm42017-04-021-1/+5
| | | | | | | | | | | | | The plan is to nuke the custom filter chain completely. It's not clear what will happen to the still needed builtin filters (mostly hardware deinterlacing and vf_vapoursynth). Most likely we'll replace them with different filter chain concept (whose main purpose will be providing builtin things and bridging to libavfilter). The undocumented "warn" options are there to disable deprecation warnings when the player inserts filter automatically. The same will be done to audio filters, at a later point.
* command: add better runtime filter toggling methodwm42017-03-251-0/+3
| | | | | | | | | | Basically, see the example in input.rst. This is better than the "old" vf-toggle method, because it doesn't require the user to duplicate the filter string in mpv.conf and input.conf. Some aspects of this changes are untested, so enjoy your alpha testing.
* video: support filtering hardware frames via libavfilterwm42017-01-161-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | Requires a bunch of hacks: - we access AVFilterLink.hw_frames_ctx. This is not a public API in FFmpeg and Libav. Newer FFmpeg provides an accessor (av_buffersink_get_hw_frames_ctx), but it's not available in Libav or the current FFmpeg release or Libav. We need this value after filter graph creation, so We have no choice but to access this. One alternative is making filter creation and format negotiation fully lazy (i.e. delay it and do it as filters are output), but this would be a huge change. So for now, we knowingly violate FFmpeg's and Libav's ABI and API constraints because they don't provide anything better. On newer FFmpeg, we use the (quite ugly) accessor, though. - mp_image_params doesn't (and can't) have a field for the frames context AVBufferRef. So we pass it via vf_set_proto_frame(), and even more hacks. - if a filter needs a hw context, but we haven't created one yet (because normally we create them lazily), it will fail at init. - we allow any hw format now, although this could go horrible wrong. Why all this effort? We could move hw deinterlacing filters etc. to FFmpeg, which is a very worthy goal.
* vf_vdpaurb: remove this filterwm42016-11-221-2/+0
| | | | Was deprecated, superseded by --hwdec=vdpau-copy.
* m_config: add helper function for initializing af/ao/vf/vo suboptionswm42016-09-021-4/+4
| | | | | | | | Normally I'd prefer a bunch of smaller functions with fewer parameters over a single function with a lot of parameters. But future changes will require messing with the parameters in a slightly more complex way, so a combined function will be needed anyway. The now-unused "global" parameter is required for later as well.
* video: don't discard video frames after endptswm42016-08-181-0/+7
| | | | | | | | | | | | Instead of letting it keep decoding by trying to find a new frame, "plug" the frame queue by not removing it. (Or actually, by putting it back instead of discarding it.) Matters for seamless looping (following commits), and possibly some other corner cases. The added function vf_unread_output_frame() is a bit of a sin, but still reasonable, since its implementation is trivial.
* vf, af: print filter labels in verbose modewm42016-07-061-0/+2
|
* vf: mark filter chain as uninitialized when mutating itwm42016-07-061-0/+2
| | | | | Sounds fair. Can be used to determine if the filter chain was mutated at all, and avoiding unconditional reinit if it wasn't.
* vf: don't clobber input params on reconfigure failurewm42016-07-061-1/+1
| | | | I think this is more robust, and future commits will rely on it.
* vf: fix filter auto-insertionwm42016-05-301-3/+13
| | | | | | | | | | | | | Commit 0348cd08 was too naive/simple, and always inserted the d3d11vpp filter if any d3d11 output image formats were supported, even if it makes no sense. For example --vf=format=rgb8 already breaks it. It needs to take the set of supported input formats into account. the weird format negotiation makes this hard. As a simple and cheap solution, make some assumptions about the supported formats of a filter. I hope to simplify this one day by using another format negotiation algorithm, but this can probably wait.
* video: remove d3d11 video processor use from OpenGL interopwm42016-05-291-2/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now have a video filter that uses the d3d11 video processor, so it makes no sense to have one in the VO interop code. The VO uses it for formats not directly supported by ANGLE (so the video data is converted to a RGB texture, which ANGLE can take in). Change this so that the video filter is automatically inserted if needed. Move the code that maps RGB surfaces to its own inteorp backend. Add a bunch of new image formats, which are used to enforce the new constraints, and to automatically insert the filter only when needed. The added vf mechanism to auto-insert the d3d11vpp filter is very dumb and primitive, and will work only for this specific purpose. The format negotiation mechanism in the filter chain is generally not very pretty, and mostly broken as well. (libavfilter has a different mechanism, and these mechanisms don't match well, so vf_lavfi uses some sort of hack. It only works because hwaccel and non-hwaccel formats are strictly separated.) The RGB interop is now only used with older ANGLE versions. The only reason I'm keeping it is because it's relatively isolated (uses only existing mechanisms and adds no new concepts), and because I want to be able to compare the behavior of the old code with the new one for testing. It will be removed eventually. If ANGLE has NV12 interop, P010 is now handled by converting to NV12 with the video processor, instead of converting it to RGB and using the old mechanism to import that as a texture.
* vf_d3d11vpp: add a D3D11 video processor filterwm42016-05-281-0/+4
| | | | | | | | | | | | | | | | | Main use: deinterlacing. I'm not sure how to select the deinterlacing mode at all. You can enumate the available video processors, but at least on Intel, all of them either signal support for all deinterlacers, or none (the latter is apparently used for IVTC). I haven't found anything that actually tells the processor _which_ algorithm to use. Another strange detail is how to select top/bottom fields and field dominance. At least I'm getting quite similar results to vavpp on Linux, so I'm content with it for now. Future plans include removing the D3D11 video processor use from the ANGLE interop code.
* video: refactor how VO exports hwdec device handleswm42016-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The main change is with video/hwdec.h. mp_hwdec_info is made opaque (and renamed to mp_hwdec_devices). Its accessors are mainly thread-safe (or documented where not), which makes the whole thing saner and cleaner. In particular, thread-safety rules become less subtle and more obvious. The new internal API makes it easier to support multiple OpenGL interop backends. (Although this is not done yet, and it's not clear whether it ever will.) This also removes all the API-specific fields from mp_hwdec_ctx and replaces them with a "ctx" field. For d3d in particular, we drop the mp_d3d_ctx struct completely, and pass the interfaces directly. Remove the emulation checks from vaapi.c and vdpau.c; they are pointless, and the checks that matter are done on the VO layer. The d3d hardware decoders might slightly change behavior: dxva2-copy will not use the VO device anymore if the VO supports proper interop. This pretty much assumes that any in such cases the VO will not use any form of exclusive mode, which makes using the VO device in copy mode unnecessary. This is a big refactor. Some things may be untested and could be broken.
* build: make libavfilter mandatorywm42016-02-051-2/+0
| | | | | | The complex filter support that will be added makes much more complex use of libavfilter, and I'm not going to bother with adding hacks to keep libavfilter optional.
* command: add vf-command commandwm42016-01-221-0/+11
|
* video: refactor: handle video format fixups closer to decoderwm42016-01-141-18/+6
| | | | | | | | | | Instead of handling this on filter chain reinit, do it directly after the decoder. This makes the code less entangled. In particular, this gets rid of the really weird "override params" concept in the video filter code. The last_format/fixed_formats have some redundance with decoder_output, but unfortunately the latter has a slightly different use.
* video: switch from using display aspect to sample aspectwm42015-12-191-25/+0
| | | | | | | | | | | | | | | | 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-20/+2
|
* vf: flush before reconfigwm42015-12-191-1/+1
|
* Remove some VLAswm42015-11-061-1/+4
| | | | | | | | They are evil and should be eradicated. Some of these were pretty dumb anyway. There are probably some more around in platform specific code or other code not enabled by default on Linux.
* video/filter: remove some vf_lavfi wrapperswm42015-09-111-8/+0
| | | | | | | | | | | | | | | | I see no point in keeping these around. Keeping wrappers for some select libavfilter filters just because MPlayer had these filters is not a good reason. Ultimately, all real filtering work should go to libavfilter, and users should get used to using vf_lavfi directly. We might even not require the awful double-nested syntax for using libavfilter one day. vf_rotate, vf_yadif, vf_stereo3d are kept because mpv uses them internally. (They all extend the lavfi filters or change their defaults.) vf_mirror is kept for symmetry with vf_flip. vf_gradfun and vf_pullup are probably semi-popular, so I'll remove them not yet - only after some more discussion.
* vf: vf_stereo3d depends on libavfilterwm42015-09-111-1/+1
|
* vf_vdpaurb: Add a new filter for reading back vdpau decoded framesPhilip Langdale2015-07-111-0/+2
| | | | | | | | | | | | | | | | | Normally, vdpau decoded frames are passed directly to a suitable vo (vo_vdpau or vo_opengl) without ever touching system memory. This is efficient for output purposes, but prevents any of the regular filters from being used with such frames. This new filter implements a read-back step to pull the frames back into system memory where they can be acted on by other filters. Eventually the frames will be sent to the vo as if they were normal software-decoded frames. Note that a vdpau compatible vo must still be used to ensure that the decoder is properly initialised. Signed-off-by: wm4 <wm4@nowhere>
* vaapi: drop compatibility crap and vo_vaapi deinterlacerwm42015-07-081-1/+1
| | | | | | | | | | | Drop libva versions below 0.34.0. These are ancient, so I don't care. Drop the vo_vaapi deinterlacer as well. With 0.34.0, VPP is always available, and deinterlacing is done with vf_vavpp. The vaCreateSurfaces() function changes its signature - actually it did in 0.34.0 or so, and the <va/va_compat.h> defined a macro to make it use the old signature.
* build: fix libavfilter dependency for vf_mirrorxylosper2015-04-201-1/+1
| | | | | | | Since e207c24b32a457859ab6e3a5b1f5f9eaeea36ed1, vf_mirror requires libavfilter. Signed-off-by: wm4 <wm4@nowhere>
* vf_screenshot: remove this filterwm42015-04-161-3/+0
| | | | | | It's entirely useless, especially now that vo.c handles screenshots in a generic way, and requires no special VO support. There are some potential weird use-cases, but actually I've never seen it being used.
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: uninline memcpy_pic functionswm42015-03-201-2/+0
| | | | | | | | | There's literally no reason why these functions have to be inline (they might be performance critical, but then the function call overhead isn't going to matter at all). Uninline them and move them to mp_image.c. Drop the header file and fix all uses of it.
* vf: fix indentation level of verbose outputwm42015-02-231-2/+2
| | | | | Just so that it has the same indentation as the extremely similar audio filter output.
* video/filters: simplify libavfilter bridgewm42015-02-111-8/+8
| | | | | | | | | | Remove the confusing crap that allowed a filter using the libavfilter bridge to be compiled without libavfilter. Instead, compile the wrappers only if libavfilter is enabled at compile time. The only filter which still requires it is vf_stereo3d (unfortunately). Special-case this one. (The whole filter and how it interacts with lavfi is pure braindeath anyway.)
* vf_ilpack: remove this filterwm42015-01-271-2/+0
| | | | | | | | This was apparently useful for correct interlaced scaling (although I don't know anyone who used this). It was rarely used (if at all), had an inconvenient output format (packed YUV), and now has a better solution in libavfilter (using the libavfilter "scale" filter via vf_lavfi). There is no reason to keep this filter any longer.
* vf_divtc: remove this filterwm42015-01-271-71/+0
| | | | | Better solutions are available in vf_vapoursynth and vf_lavfi. The only user I know who used this is now using vf_vapoursynth.
* vf_phase: remove this filterwm42015-01-271-2/+0
| | | | If you really want it, it's in libavfilter and can be used via vf_lavfi.
* vf_swapuv: remove this filterwm42015-01-271-2/+0
| | | | | | It's entirely useless. I left it in for a while, because the analog TV code had a transitional bug that could switch chroma planes, but it was fixed long ago. It's also available in libavfilter.
* vf_softpulldown: remove this filterwm42015-01-271-17/+0
| | | | | | | | Apparently it was completely broken and essentially did nothing. This was broken sometime in early mpv or mplayer2 times. Get rid of it. If you _really_ need it, wait until FFmpeg ports it from MPlayer, which will happen very soon.
* 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: make message less confusingwm42015-01-131-1/+1
| | | | | Well, probably still not very good, but now at least accounts for the case the decoder or a filter outputs nonsense values.
* video: better pipelining with vf_vapoursynthwm42015-01-031-8/+46
| | | | | | | | | | 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.
* command: make empty vf-metadata not an errorwm42014-12-301-3/+4
| | | | | | | | If a filter exists, but has no metadata, just return success. This allows the user to distinguish between no metadata available, and filter not inserted. See #1408.
* vf: fix crash if filter doesn't provide control entrypointwm42014-12-301-1/+1
| | | | | | | | This input command crashed: vf add @mf:format=yuv420p ; show_text "${vf-metadata/mf}" Fixes #1408.
* video/filter: kill vf_pp (libpostproc)wm42014-12-031-4/+0
| | | | | | | | | This is an ancient filter, and we assume it's not useful anymore. If you really want this, it's still available in libavfilter (e.g. via --vf=lavfi=[pp...]). The disadvantage is that mpv doesn't pass through QP information to libavfilter. (This was probably the reason vf_pp still was part of mpv - it was slightly easier to pass QP internally.)
* video: move formatting of image parameters to separate functionwm42014-11-121-21/+2
|
* vf: minor simplificationwm42014-11-121-14/+9
| | | | | | | | Remove the extra vf_chain.output field - there's absolutely no need for it, because there is always a last filter which will buffer the output. For some reason, vf_chain.last was never set, which we now need to fix too.
* vf_vapoursynth: add standalone Lua scriptingwm42014-10-121-1/+5
|
* video/filter: allow better dataflowwm42014-09-181-2/+11
| | | | | | | |