| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
This is essentially what it is, and it's a useful for windowing or
downscaling. For upscaling we already have bilinear, no need to cause
extra confusion between biliner and bilinear_slow.
Also made it a bit more well-behaved.
|
| |
|
|
|
|
|
|
| |
These are EWA-based versions of the keys B/C splines, of which mitchell
is already a member. They are slightly softer and slightly sharper than
mitchell, respectively.
Very easy to define in terms of things we already have.
|
| |
|
|
|
|
| |
mitchell, hermite and catmull_rom are all B/C splines and can share the
code which was already written for mitchell. This just redefines them in
terms of that.
|
| |
|
|
|
| |
This is essentially a preconfigured version of ewa_lanczos, with the
"best" parameters for general purpose usage.
|
| |
|
|
|
| |
This affects all filters that use it, eg. ewa_lanczos. Setting it to
something like 0.95 can be done to make the filter a bit less blurry.
|
| |
|
|
|
|
|
|
|
| |
Previously, this was based on some arbitrary range 1-100, cut off for
no particular reason, and also defined in such a way that higher values
= *less* smoothness. Since it wasn't multiplied by e in the code, the
default had to be 10*e = 28.8539...
Now, it's sane: 1.0 = default, higher = blurrier.
|
| |
|
|
|
|
|
|
| |
This filter isn't supposed to have a second parameter in the first
place, all literature only uses a single parameter alpha in both places.
The second parameter doesn't even do anything other than adding a
constant factor, which is normalized by the LUT calculation either way.
|
| |
|
|
|
|
| |
This is done mainly for consistency, since all of the EWA filters share
similar properties and it's important to distinguish them for
documentation purposes.
|
| |
|
|
|
| |
This is suggested in a thesis by Andreas Gustafsson, and seems to
produce very a bit less ringing than lanczos at high radius.
|
| |
|
|
|
|
| |
No point in duplicating this check all over the place. No point in
really having it in the first place, to be perfectly honest, j1 should
not be THAT badly behaved.
|
| |
|
|
|
|
|
|
|
|
|
| |
The original filter window was design for a radius based on the true
zero, but we always cut it off at our selection of radius either way (by
necessity, due to the square matrix we sample from).
This window is tweaked from the original (true radius) to our actual
cut-off radius, and hence improves the result in a few edge cases. The
main win is the reduction of code complexity, since we no longer need to
know what the true radius actually is.
|
| |
|
|
|
|
|
|
|
| |
This is a variation of ewa_lanczos that is sinc-windowed instead of
jinc-windowed. Results are pretty similar, but the logic is simpler.
This could potentially replace the ugly ewa_lanczos code.
It's hard to tell, but from comparing stills I think this one has
slightly less ringing than regular ewa_lanczos.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somehow, the default radius for filters with variable radius was set in
mp_init_filter(). gl_video.c used NAN as default value for the radius,
which would make the filter use the default radius. Simplify this, and
set the default radius directly in the gl_video options. It also makes
the options easier to understand, because the default value listed in
--vo=opengl:help actually shows the default value.
Remove the function can_use_filter_kernel(), because it doesn't set a
radius if none is set. The function is worthless anyway (something about
making filter_kernels.c reusable to other VOs, and trying to deal with
the possibility that it could provide filters not supported by
vo_opengl.)
|
| |
|
|
| |
Just set the radius with scale-radius if it's really needed
|
| |
|
|
|
|
| |
This fixes compatibility with GLES 2.0 and makes the code a bit neater
in general. It also properly forces indirect scaling for subsampled
video regardless of the lscale setting.
|
| |
|
|
|
|
|
| |
This also fixes the maximum range to 16.0, which was previously set to
32.0 and incorrectly documented as 8.0. 16 taps should be more than
anybody will ever need, but it's the highest radius that's supported by
all affected filters.
|
| |
|
|
|
|
|
| |
Broke operation with GLSL.
Since 1D texture usage was apparently (and mysteriously) good for speed,
it might be added back, but it's unknown how to do so in a clean way.
|
| |
|
|
|
| |
This is the polar (elliptic weighted average) version of lanczos.
This introduces a general new form of polar filters.
|
| |
|
|
|
|
|
|
|
|
|
| |
This gives better results with fancy-downscaling. The issue here is that
fancy-downscalign "extends" the filter radius by some amount, which
requires using a larger filter size and shader. Then most of the filter
is "unused", but some filters still return non-0 coefficients, which
create heavy artifacts. Just clamp them off.
I'm not sure if this is the right solution, but at least it's better
than before.
|
| |
|
|
|
|
|
|
|
|
| |
Add a new parameter 'p' to gaussian filter. The new formula used
a different base taken from fmtconv plugin, so that the
new parameter is exactly same as the one used in Avisynth and
Vapoursynth.
The new default value is 2 / log(2) * 10, with the default value it
conforms to the original kernel taken from vector-agg.
|
| |
|
|
|
|
|
| |
Add two new options, make it possible for user to set the radius
for some of the filters with no fixed radius.
Also add three new filters with the new radius parameter supported.
|
| |
|
|
|
|
|
|
| |
The coefficients are taken from fmtconv plugin for vapoursynth:
https://github.com/vapoursynth/fmtconv/blob/master/src/fmtc/ContFirSpline64.cpp
The package is licensed under WTFPL, and it's from the same author
of Dither plugin for avisynth.
|
| |
|
|
|
|
|
|
|
|
| |
The previous commit assumed the filter would be 1x1 (then constant
weight is correct) - but our code in fact uses at least a 2x2 filter. A
1x1 filter would generally be useless, except for nearest scaling - so
it didn't exist.
Insteasd of adding such a 1x1 filter, just turn the nearest weight
function into a scare function, which should take care of the issue.
|
| |
|
|
|
|
| |
This is useful for playing content containing pixel art that hasn't been
pre-scaled, such as TASVideos' high quality encodes. The implementation is
lifted from <https://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py#413>.
|
|
|
Tis drops the silly lib prefixes, and attempts to organize the tree in
a more logical way. Make the top-level directory less cluttered as
well.
Renames the following directories:
libaf -> audio/filter
libao2 -> audio/out
libvo -> video/out
libmpdemux -> demux
Split libmpcodecs:
vf* -> video/filter
vd*, dec_video.* -> video/decode
mp_image*, img_format*, ... -> video/
ad*, dec_audio.* -> audio/decode
libaf/format.* is moved to audio/ - this is similar to how mp_image.*
is located in video/.
Move most top-level .c/.h files to core. (talloc.c/.h is left on top-
level, because it's external.) Park some of the more annoying files
in compat/. Some of these are relicts from the time mplayer used
ffmpeg internals.
sub/ is not split, because it's too much of a mess (subtitle code is
mixed with OSD display and rendering).
Maybe the organization of core is not ideal: it mixes playback core
(like mplayer.c) and utility helpers (like bstr.c/h). Should the need
arise, the playback core will be moved somewhere else, while core
contains all helper and common code.
|
