summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* af_lavfi, vf_lavfi: fix compilation on Libavwm42016-01-221-0/+1
| | | | It has no avfilter_graph_send_command().
* command: add vf-command commandwm42016-01-223-0/+22
|
* Change 3 more files to LGPLwm42016-01-201-7/+7
|
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-193-21/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* video: refactor: handle video format fixups closer to decoderwm42016-01-142-21/+7
| | | | | | | | | | 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.
* 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.
*