summaryrefslogtreecommitdiffstats
path: root/video/filter
Commit message (Collapse)AuthorAgeFilesLines
* 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
| | | | If you can call this a "stdlib".
* vf_ilpack: remove this filterwm42015-01-272-183/+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-273-713/+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-272-310/+0
| | | | If you really want it, it's in libavfilter and can be used via vf_lavfi.
* vf_swapuv: remove this filterwm42015-01-272-66/+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-273-194/+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.
* vf_pullup: remove builtin implementationwm42015-01-273-920/+10
| | | | | Now it requires libavfilter. The wrapper is left in place, so FFmpeg users will not notice any change. On Libav, the filter stops working.
* ta: rename MP_TALLOC_ELEMS to MP_TALLOC_AVAILBen Boeckel2015-01-271-2/+2
| | | | | The macro actually returns the *available* space in the array, not how much is actually filled in.
* video: separate screenshot modeswm42015-01-232-3/+2
| | | | | | | | | Use different VOCTRLs for "window" and normal screenshot modes. The normal one will probably be removed, and replaced by generic code in vo.c, and this commit is preparation for this. (Doing it the other way around would be slightly simpler, but I haven't decided yet about the second one, and touching every VO is needed anyway in order to remove the unneeded crap. E.g. has_osd has been unused for a long time.)
* vf_vavpp: add more deinterlacing algorithmswm42015-01-231-7/+22
| | | | | | These are untested due to lack of hardware. From what I've heard, the drivers are pretty buggy, so it's not clear how well this works, if at all.
* video: have a generic context struct for hwdec backendswm42015-01-222-2/+6
| | | | | | | | | | | Before this commit, each hw backend had their own specific struct types for context, and some, like VDA, had none at all. Add a context struct (mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec context around. Some things get slightly better, some slightly more verbose. mp_hwdec_info is still around; it's still needed, but is reduced to its role of handling delayed loading of the hwdec backend.
* vaapi: minor simplificationwm42015-01-211-1/+1
|
* video: remove vfcap.hwm42015-01-215-22/+6
| | | | | | | | | | | | | | | | | 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_scale: replace ancient fallback image format selectionwm42015-01-211-141/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If video output and VO don't support the same format, a conversion filter needs to be insert. Since a VO can support multiple formats, and the filter chain also can deal with multiple formats, you basically have to pick from a huge matrix of possible conversions. The old MPlayer code had a quite naive algorithm: it first checked whether any conversion from the list of preferred conversions matched, and if not, it was falling back on checking a hardcoded list of output formats (more or less sorted by quality). This had some unintended side- effects, like not using obvious "replacement" formats, selecting the wrong colorspace, selecting a bit depth that is too high or too low, and more. Use avcodec_find_best_pix_fmt_of_list() provided by FFmpeg instead. This function was made for this purpose, and should select the "best" format. Libav provides a similar function, but with a different name - there is a function with the same name in FFmpeg, but it has different semantics (I'm not sure if Libav or FFmpeg fucked up here). This also removes handling of VFCAP_CSP_SUPPORTED vs. VFCAP_CSP_SUPPORTED_BY_HW, which has no meaning anymore, except possibly for filter chains with multiple scale filters. Fixes #1494.
* 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.
* win32: request UTF-16 API variants, Vista+ APIs, and COM C macroswm42015-01-071-1/+1
| | | | | Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into the build system, instead of defining them over and over in the code.
* vf_vapoursynth: autodetect CPU countwm42015-01-051-3/+8
| | | | | | | | This adds an "auto" choice to the concurrent-frames suboption, and makes it the default. I'm not so sure about making this the default, though. It could lead to excessive buffering with large CPU counts. But we'll see.
* vf_vapoursynth: fix Lua backendwm42015-01-031-0/+3
| | | | It couldn't handle the newly added float variable.
* vf_vapoursynth: pass through container FPS valuewm42015-01-032-0/+3
| | | | | | | | This is basically a hack; but apparently a needed one, since many vapoursynth filters insist on having a FPS set. We need to apply the FPS override before creating the filters. Also change some terminal output related to the FPS value.
* video: better pipelining with vf_vapoursynthwm42015-01-033-8/+73
| | | | | | | | | | 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
| | | | | | |