summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* vf_yadif: change defaultswm42015-12-211-0/+4
| | | | | | | | | | | | | | | | This is for the sake of command.c and the "deinterlace" option/property. Instead of forcing certain "better" defaults when inserting yadif, change the actual "yadif" defaults. I pondered not changing vf_yadif, and instead adding a trivial "yadif- auto" wrapper filter, which would merely have different defaults. But thinking about it, it doesn't make any sense for "deinterlace" to have different defaults from vf_yadif, with vf_yadif having the "worse" defaults. If someone wants the old behavior, the old behavior can be forced in a backward and forward compatible way by setting the suboptions. Fixes #2539 (kind of).
* 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-1911-103/+35
| | | | | | | | | | | | | | | | 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-199-96/+88
|
* vf: flush before reconfigwm42015-12-192-10/+1
|
* vf_stereo3d: add alternating modesPaul B Mahol2015-12-181-0/+4
| | | | Signed-off-by: Paul B Mahol <onemda@gmail.com>
* 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: replace vf_format outputlevels option with global optionwm42015-09-291-4/+1
| | | | | | | | | | | The vf_format suboption is replaced with --video-output-levels (a global option and property). In particular, the parameter is removed from mp_image_params. The mechanism is moved to the "video equalizer", which also handles common video output customization like brightness and contrast controls. The new code is slightly cleaner, and the top-level option is slightly more user-friendly than as vf_format sub-option.
* vf_vavpp: allocate output surfaces with the same size as inputwm42015-09-231-1/+4
| | | | | | | | | | | | | This can happen if the hw decoder allocates padded surfaces (e.g. mod16), but the VPP output surface was allocated with the exact size. Apparently VPP requires matching input and output sizes, or it will add artifacts. In this case, it added mirrored pixels to the bottom few pixels. Note that the previous commit should have fixed this. But it didn't work, while this commit does. Fixes #2320.
* va_vavpp: set input/output processing regionwm42015-09-231-2/+2
| | | | | | | | If not set, VPP will use the whole surface. This is a problem if the surfaces are padded, and especially if the surfaces are padded by different amounts. This is an attempt to fix #2320, but it appears to do nothing at all.
* vf_yadif: add hack for Libav compatibilitywm42015-09-201-3/+12
| | | | | | Libav accepts slightly different options compared to FFmpeg. Sigh... This was "broken" in 25755f5f. Fixes #2335.
* vf_vdpaurb: query_format is still requiredPhilip Langdale2015-09-181-0/+6
| | | | | | | I took this out because I thought the filter chain would auto-negotiate using nv12 without the explicit hint, and it does in the basic case with no intermediate filter, but once you start adding filters, it can end up negotiating a different format and then failing.
* vf_vdpaurb: Pass through non-hardware-decoded contentPhilip Langdale2015-09-151-9/+8
| | | | | | | | | | Today, vdpaurb will fail if it's used with non-hardware-decoded content. This created work for the user as they have to explicitly add or not add it, depending on the content. As an improvement, we can make vdpaurb pass through any frames that aren't hardware decoded, so that it can always be present in the filter chain, if desired.
* video/filter: remove some vf_lavfi wrapperswm42015-09-115-304/+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_lavfi: cosmetics: fix coding stylewm42015-09-111-11/+11
|
* vf: vf_stereo3d depends on libavfilterwm42015-09-111-1/+1
|
* vf_vdpaurb: Don't segfault if input mpi is nullPhilip Langdale2015-08-051-0/+4
| | | | | This will happen when input EOF is reached but output frames remain to be shown.
* vf_scale: cleanup log messageswm42015-07-201-12/+3
| | | | In particular, get rid of the EUSERBROKEN message.
* 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_vdpaupp: Don't crash when evaluating interlacing of NULL mpiPhilip Langdale2015-07-141-1/+1
| | | | | | | The interlaced frame test needs to be aware that the input mpi might be NULL - this happens at the end of a stream when the input frames have all been submitted but frames still need to be drained from the decoder.
* vf_vdpaurb: Add a new filter for reading back vdpau decoded framesPhilip Langdale2015-07-112-0/+114
| | | | | | | | | | | | | | | | | 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>
* vf_stereo3d: drop internal implementationwm42015-07-101-393/+15
| | | | Leave the libavfilter wrapper only.
* vf_vdpaupp: don't attempt to deinterlace progressive frameswm42015-07-081-5/+9
|
* 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.
* vf_vavpp: don't attempt to deinterlace progressive frameswm42015-07-081-0/+7
|
* vf_yadif: expose interlaced frame modewm42015-07-071-9/+5
| | | | | Also remove the enabled suboption, which did nothing. (It was probably broken at some point.)
* vf_sub: minor simplificationwm42015-06-052-5/+2
|
* vf_vavpp: provide future/past frames to driverwm42015-06-011-30/+97
| | | | | | | | | | | | | This was missing for extended deinterlacer. Unfortunately, these deinterlacer still do not work. The provided future frame (which is all the deinterlacers want) seems to be correct, though. One minor behavioral change is that this always keeps the previous frame for PTS computations. This could be avoided (in order to keep exactly the same behavior as before), but it seems more elegant and should not do any harm. (Also, if we really cared about reducing hw frame refs, a more worthy goal is producing the field output incrementally.)
* vf_vavpp: move vaMapBuffer() closer to its usewm42015-06-011-4/+4
| | | | | | | | The mapped data (pointed to by the param variable) is not needed before, so the call can be moved down. Also, this prevents that the buffer remains mapped forever if the other vaMapBuffer() call above fails (the cleanup code forgets to unmap the buffer - this commit makes it unnecessary).
* vf_vavpp: remove dummy loop, unindentwm42015-06-011-51/+61
| | | | | | | This used a do-while loop, which runs only once, as replacement for a cleanup goto. While this is ok, doing a goto directly is easier to follow and is closer to idiomatic C. But mainly remove it so that the indentation can be reduced.
* vf_vavpp: cosmeticswm42015-06-011-10/+10
| | | | Adjust coding style. Get rid of some useless consts too.
* vf_vavpp: minor simplificationwm42015-06-011-29/+24
| | | | Slightly easier to follow.
* vf_vavpp: fix bob deinterlacing for bottom field first videosFilip Milivojevic2015-05-301-0/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vf_vavpp: do not pretend to support referenceswm42015-05-291-3/+5
| | | | | | | | | | | | | | | We do not fill them, so we would pass random IDs to the driver. The code was originally written to handle bob deinterlacing only, so I guess it originally passed always 0 anyway, despite having code for reference surface list allocation. Also, move down the vaUnmapBuffer() call. This call actually "unmaps" the param pointer, so accessing it after the unmap call would be undefined behavior. The "example" in <va/vavpp.h> does this too, but it's most likely an error. (Additionally, not even bob deinterlacing worked correctly in my test, sigh.)
* vf_vavpp: simplify surface list allocationwm42015-05-291-14/+2
|
* vf_dlopen: declare as deprecatedwm42015-05-251-0/+4
| | | | | Mostly to see whether someone uses it, and if a better solution can be worked out. (It's simple enough to be supported forever.)
* vf_vapoursynth: reject unaligned video sizeswm42015-05-151-0/+7
| | | | Leads to some nice memory corruption otherwise.
* Remove trailing whitespacesMichael Vetter2015-05-151-2/+2
|
* mp_image: remove some unused interlacing flagswm42015-04-231-3/+1
| | | | | | MP_IMGFIELD_TOP/MP_IMGFIELD_BOTTOM were completely unused, and MP_IMGFIELD_ORDERED was always set (even though vf_vdpaupp.c strangely checked for the latter).
* 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.
* build: fix libavfilter dependency for vf_mirrorxylosper2015-04-201-1/+1
| | | | | | | Since e207c24b32a457859ab6e3a5b1f5f9eaeea36ed1, vf_mirror requires libavfilter. Signed-off-by: wm4 <wm4@nowhere>
* vf_crop, vf_expand: remove ancient and useless messageswm42015-04-162-19/+1
| | | | These are redundant.
* vf_mirror: replace internal implementation with libavfilterwm42015-04-161-85/+4
| | | | | Currently, libavfilter's equivalent vf_hflip is probably not faster or anything, but there's still no reason to keep the internal code.
* vf_screenshot: remove this filterwm42015-04-163-78/+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-1323-114/+92
| | | | Signed-off-by: wm4 <wm4@nowhere>
* mp_image: remove redundant chroma_x/y_shift fieldswm42015-04-102-6/+6
|
* mp_image: remove redundant plane_w/h fieldswm42015-04-101-2/+3
| | | | Seems relatively painful in this case, but they are morally wrong.
* vf_format: add gamma override optionNiklas Haas2015-04-041-0/+4
|
* vf_format: allow forcing aspect ratiowm42015-04-031-0/+4
| | | | | Makes vf_dsize completely useless. Unfortunately, even our "official" encoding profiles still use it.
* vf_format: allow forcing display sizewm42015-04-031-0/+7
|
* vf_format: allow forcing rotation flagswm42015-04-031-0/+7
|
* vf_format: allow forcing stereo mode parameterswm42015-04-031-0/+8
|
* video: cleanup stereo mode parsingwm42015-04-021-1/+1
| | | | | | | | | Use OPT_CHOICE_C() instead of the custom parser. The functionality is pretty much equivalent. (On a side note, it seems --video-stereo-mode can't be removed, because it controls whether to "reduce" stereo video to mono, which is also the default. In fact I'm not sure how this should be handled at all.)
* video: move colorspace overrides to vf_format, simplifywm42015-03-311-2/+29
| | | | | | | | | | | | | | | | | | | Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
* vf_format: don't crash if nonsense parameters are passedwm42015-03-311-3/+23
| | | | | | | It was "by design" possible to make mpv crash if the parameters didn't make enough sense, like "format=rgb24:yuv420p". While forcing the format has some minor (rather questionable) use for debugging, allowing it to crash is just stupid.
* vf_format: by default, pass through video without changewm42015-03-311-22/+17
| | | | | | Instead of forcing a useless format (packed YUV??) by default. Also cleanup.
* 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_expand: fix memory leak on memory allocation failurewm42015-03-201-1/+3
| | | | Isn't it ironic.
* video: uninline memcpy_pic functionswm42015-03-204-7/+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.
* video: replace pointless macrowm42015-03-201-6/+4
| | | | Some old absurdity.
* vf_vavpp: fix deinterlacingFilip Milivojevic2015-03-081-0/+8
| | | | | | | Add filter parameters to VAAPI deinterlacing filter to actually process bottom fields instead of deinterlacing top field twice. Signed-off-by: wm4 <wm4@nowhere>
* 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.
* 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-132-0/+2
| | | | | This value is not necessarily trustworthy (it might change) and can be 0.
* vf_lavfi: drop useless option from wrapper filterswm42015-02-121-4/+1
| | | | | | | Filters which merely wrap libavfilter (for user-compatibility) like vf_gradfun had a "lavfi-enable" suboption, which could disable libavfilter usage. Since none of these filters has an internal implementation anymore, this was completely useless.
* video/filters: simplify libavfilter bridgewm42015-02-1111-55/+45
| | | | | | | | | | 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_noise: remove internal implementationwm42015-02-111-239/+8
| | | | | It requires libavfilter now, just like many other filters. Not sure if it even makes sense to keep this wrapper.
* vf_vapoursynth: load Lua stdlib in Lua modewm42015-01-291-0/+1