summaryrefslogtreecommitdiffstats
path: root/player/video.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2016-01-06 18:35:01 +0100
committerwm4 <wm4@nowhere>2016-01-06 18:46:56 +0100
commit3909e4cdfcb982187f351ca928c0b89172b81885 (patch)
tree252aec6671e515618188a6128ea037f62482158d /player/video.c
parent3e90a5fe81229e4c0acd8e5afa8d59efaf942fa9 (diff)
downloadmpv-3909e4cdfcb982187f351ca928c0b89172b81885.tar.bz2
mpv-3909e4cdfcb982187f351ca928c0b89172b81885.tar.xz
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file: http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h The intention is that filter_kernels.c can be relicensed to LGPL or BSD. Because the AGG author died, full replacement is the only way to achieve it. This affects only some filter functions. These are exclusively mathematical functions for computing filter coefficients. (Other parts in filter_kernel.c were originally written by me, with heavy additions and refactoring done by other mpv contributors.) While the code is mostly just well-known mathematical formulas written down in C form, AGG copyright could perhaps be claimed anyway. To remove the AGG code, I replaced it with the filter functions from: https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py These functions conveniently compute exactly the same thing in mpv, Glumpy, AGG (and about anything that will filter images using the same mathematical principles). First I ported the Python code in the file to C. Then I replaced all functions in filter_kernels.c with this code that could be replaced. Then I investigated whether the remaining functions were based on AGG code and took appropriate action: hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(), spline16(), spline36(), gaussian(), sinc() were taken straight from Glumpy. For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit 586dc557 for unknown reasons. gaussian() loses its filter parameter for some reason. (Well, who cares, not my problem.) The really awkward thing is that the text for hanning() and hamming() does not change. In theory these functions are now based on Glumpy code, but it seems like this can be neither proven nor denied. (The same happened in some other cases with at least a few lines of code.) sphinx() was added in commit 586dc557, and looks suspiciously like sinc() as well. Replace the first 3 lines of the body with the ported function (of which 2 lines do not change; the first uses code only in mpv, and the second is just "return 1.0;"). The 4th line is only similar on an abstract level (and that because of the mathematical relation between these functions). Although the original sinc() was probably used as template for it, with the other lines replaced, I don't think you could make the claim that it falls under AGG copyright. jinc() was added in commit 26baf5b9, but the code for it might be based on sinc(). Rewrite it based on the "new" sinc(). Some of the same remarks as with sphinx() apply. cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware, with the default parameters it's called "the" Mitchell-Netravali filter, but in mpv this function is used to generate a whole group of filters.) spline64() was added in commit a8b67c66, and was probably derived from spline36(). Re-derive it from the "new" spline36(). triangle() could be considered derived from the original bilinear(). This is this in the original commit: static double bilinear(kernel *k, double x) { return 1.0 - x; } This _might_ be based on AGG's image_filter_bilinear: struct image_filter_bilinear { static double radius() { return 1.0; } static double calc_weight(double x) { return 1.0 - x; } }; Considering that the "framework" was written by me, and the only part from AGG taken is "return 1.0 - x;", and this part is trivial and was later thoroughly replaced, this is probably not under the AGG copyright. I'm hoping this doesn't introduce regressions. But the main focus is not being productive anyway, and I didn't rigorously check unintended changes in functionality.
Diffstat (limited to 'player/video.c')
0 files changed, 0 insertions, 0 deletions