On Fri, Dec 4, 2015 at 4:00 AM, Paul B Mahol <one...@gmail.com> wrote:
> On 12/4/15, Ganesh Ajjanagadde <gajja...@mit.edu> wrote:
>> On Thu, Dec 3, 2015 at 5:52 PM, Paul B Mahol <one...@gmail.com> wrote:
>>> Signed-off-by: Paul B Mahol <one...@gmail.com>
>>> ---
>>> Changelog | 1 +
>>> configure | 26 ++++
>>> doc/filters.texi | 46 ++++++
>>> libavfilter/Makefile | 1 +
>>> libavfilter/af_aemphasis.c | 370
>>> +++++++++++++++++++++++++++++++++++++++++++++
>>> libavfilter/allfilters.c | 1 +
>>> libavfilter/version.h | 2 +-
>>> 7 files changed, 446 insertions(+), 1 deletion(-)
>>> create mode 100644 libavfilter/af_aemphasis.c
>>>
>>> diff --git a/Changelog b/Changelog
>>> index 2d2a92b..552fab1 100644
>>> --- a/Changelog
>>> +++ b/Changelog
>>> @@ -39,6 +39,7 @@ version <next>:
>>> - support encoding 16-bit RLE SGI images
>>> - apulsator filter
>>> - sidechaingate audio filter
>>> +- aemphasis filter
>>>
>>>
>>> version 2.8:
>>> diff --git a/configure b/configure
>>> index a30d831..10631e8 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -1051,6 +1051,21 @@ int main(void){ $func(); }
>>> EOF
>>> }
>>>
>>> +check_complexfunc(){
>>> + log check_complexfunc "$@"
>>> + func=$1
>>> + narg=$2
>>> + shift 2
>>> + test $narg = 2 && args="f, g" || args="f"
>>> + disable $func
>>> + check_ld "cc" "$@" <<EOF && enable $func
>>> +#include <complex.h>
>>> +#include <math.h>
>>> +float foo(complex float f, complex float g) { return $func($args); }
>>> +int main(void){ return (int) foo; }
>>> +EOF
>>> +}
>>> +
>>> check_mathfunc(){
>>> log check_mathfunc "$@"
>>> func=$1
>>> @@ -1768,6 +1783,11 @@ INTRINSICS_LIST="
>>> intrinsics_neon
>>> "
>>>
>>> +COMPLEX_FUNCS="
>>> + cabs
>>> + cexp
>>> +"
>>> +
>>
>> These are not inherently needed, cabs and cexp can be easily
>> implemented using hypot and sin, cos, etc. See e.g the mandelbrot
>> filter; the filter mathematically operates on complex numbers, but one
>> can always use the real value variants with a trivial amount of work.
>>
>> Don't know and it is unlikely that all our platforms have them - a
>> platform which refuses to implement simple things like llrint would
>> most likely not bother with this stuff. If you really want to use
>> complex numbers (though above demonstrates there is no inherent
>> reason), you should add the relevant compat hacks.
>
> I'm not going to add hacks nor reimplement libm/libc nor do I care for
> platforms
> which lacks complex.h
> Similar is done for dynaudnorm.
Neither do I personally, and I strongly dislike hacking around broken
libm's for which there are zero excuses in my view. However, I pointed
this out for the possible consequences to people who do care about
such things, be it for portability goals, personal investment in a
platform, etc.
It seems like Windows (the usual culprit) fails to have complex:
https://stackoverflow.com/questions/22991409/compiling-c-code-in-visual-studio-2013-with-complex-h-library.
It represents a sizable market share for FFmpeg and its users.
Also, most filters up till now were not inherently platform specific
to this degree - dynaudnorm is the exception and not the rule. Thus, I
felt this noteworthy enough and think it warrants discussion since
this is the first time complex.h is being used in FFmpeg, especially
since workarounds are not hard unlike erf. Discussing these things
early can help avoid problems later on like the pkg-config business.
All said, Hendrik's points are better, and since he deals with Windows
and I don't, he is also a far better judge of these things.
>
> I'm not going to go mandelbrot way as that is not simple approach.
> If somebody else who cares comes and do that - then fine, I'm not
> going to be against it.
>
> I just do not care..
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
