Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Di., 14. Mai 2019 um 20:41 Uhr schrieb Lynne :

> Attached a version with fft-template.c's copyright and mine

Thank you!

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Reimar Döffinger]

On Tue, May 14, 2019 at 08:41:02PM +0200, Lynne wrote:
> May 14, 2019, 7:12 PM by one...@gmail.com:
> > On 5/14/19, Carl Eugen Hoyos <> ceffm...@gmail.com 
> > > > wrote:
> >>> Am 14.05.2019 um 19:17 schrieb Lynne <>>> d...@lynne.ee 
> >>> :
> >>>
> >>> I've attached the latest version.
> >>>
> >>
> >> This patch is still not ok, please do not commit.
> >>
> >
> > I will and you can not stop me.
> >
>
> Attached a version with fft-template.c's copyright and mine like James 
> suggested
> so the fighting can at least somewhat stop and I can write some SIMD.

Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[James Almer]

On 5/15/2019 2:57 PM, Lynne wrote:
> May 14, 2019, 7:41 PM by d...@lynne.ee:
> 
>> May 14, 2019, 7:12 PM by > one...@gmail.com > :
>>
>>> On 5/14/19, Carl Eugen Hoyos <> >> ceffm...@gmail.com 
>>> >>  > ceffm...@gmail.com 
>>> >> >> > wrote:
>>>



> Am 14.05.2019 um 19:17 schrieb Lynne <>>>  d...@lynne.ee 
>   >>> d...@lynne.ee 
>   >:
>
> I've attached the latest version.
>

 This patch is still not ok, please do not commit.

>>>
>>> I will and you can not stop me.
>>>
>>
>> Attached a version with fft-template.c's copyright and mine like James 
>> suggested
>> so the fighting can at least somewhat stop and I can write some SIMD.
>>
>>> +/*
>>> + * Copyright (c) 2019 Lynne <>> d...@lynne.ee >>  
>>> > d...@lynne.ee >> >>
>>> + * Power of two FFT:
>>> + * Copyright (c) 2008 Loren Merritt
>>> + * Copyright (c) 2002 Fabrice Bellard
>>> + * Partly based on libdjbfft by D. J. Bernstein
>>> + *
>>> + * This file is part of FFmpeg.
>>>
> 
> Pushed.

You also need to bump libavutil minor version, and add an entry to
doc/APIChanges listing the new symbols.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 14, 2019, 7:41 PM by d...@lynne.ee:

> May 14, 2019, 7:12 PM by > one...@gmail.com > :
>
>> On 5/14/19, Carl Eugen Hoyos <> >> ceffm...@gmail.com 
>> >>  > ceffm...@gmail.com 
>> >> >> > wrote:
>>
>>>
>>>
>>>
 Am 14.05.2019 um 19:17 schrieb Lynne <>>>  d...@lynne.ee 
   >>> d...@lynne.ee 
   >:

 I've attached the latest version.

>>>
>>> This patch is still not ok, please do not commit.
>>>
>>
>> I will and you can not stop me.
>>
>
> Attached a version with fft-template.c's copyright and mine like James 
> suggested
> so the fighting can at least somewhat stop and I can write some SIMD.
>
>> +/*
>> + * Copyright (c) 2019 Lynne <>> d...@lynne.ee >>  
>> > d...@lynne.ee >> >>
>> + * Power of two FFT:
>> + * Copyright (c) 2008 Loren Merritt
>> + * Copyright (c) 2002 Fabrice Bellard
>> + * Partly based on libdjbfft by D. J. Bernstein
>> + *
>> + * This file is part of FFmpeg.
>>

Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 14, 2019, 7:12 PM by one...@gmail.com:

> On 5/14/19, Carl Eugen Hoyos <> ceffm...@gmail.com 
> > > wrote:
>
>>
>>
>>
>>> Am 14.05.2019 um 19:17 schrieb Lynne <>>> d...@lynne.ee 
>>> :
>>>
>>> I've attached the latest version.
>>>
>>
>> This patch is still not ok, please do not commit.
>>
>
> I will and you can not stop me.
>

Attached a version with fft-template.c's copyright and mine like James suggested
so the fighting can at least somewhat stop and I can write some SIMD.

> +/*
> + * Copyright (c) 2019 Lynne mailto:d...@lynne.ee>>
> + * Power of two FFT:
> + * Copyright (c) 2008 Loren Merritt
> + * Copyright (c) 2002 Fabrice Bellard
> + * Partly based on libdjbfft by D. J. Bernstein
> + *
> + * This file is part of FFmpeg.
>From d79083b34db80e87d6cee1d22455bc8330e866ad Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Thu, 2 May 2019 15:07:12 +0100
Subject: [PATCH] libavutil: add an FFT & MDCT implementation

This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.

A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...

The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".

Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
  22353 decicycles in fftwf_execute, 1024 runs,  0 skips
  21836 decicycles in compound_fft_15x8, 1024 runs,  0 skips

128:
  22003 decicycles in   fftwf_execute,   1024 runs,  0 skips
  23132 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

384:
  75939 decicycles in  fftwf_execute,1024 runs,  0 skips
  73973 decicycles in compound_fft_3x128,1024 runs,  0 skips

640:
 104354 decicycles in   fftwf_execute,   1024 runs,  0 skips
 149518 decicycles in compound_fft_5x128,1024 runs,  0 skips

768:
 109323 decicycles in  fftwf_execute,1024 runs,  0 skips
 164096 decicycles in compound_fft_3x256,1024 runs,  0 skips

960:
 186210 decicycles in  fftwf_execute,1024 runs,  0 skips
 215256 decicycles in compound_fft_15x64,1024 runs,  0 skips

1024:
 163464 decicycles in   fftwf_execute,   1024 runs,  0 skips
 199686 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.

The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
It is unlikely that libavcodec/fft will be removed soon as there's much SIMD
written for exotic or old platforms there, but nevertheless new code
should use this new API throughout the project.

The implementation passes fate when used in Opus, AAC and Vorbis, and the output
is identical in ATRAC9 as well.
---
 libavutil/Makefile |   2 +
 libavutil/tx.c | 803 +
 libavutil/tx.h |  81 +
 3 files changed, 886 insertions(+)
 create mode 100644 libavutil/tx.c
 create mode 100644 libavutil/tx.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 53208fc587..8a7a44e4b5 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -79,6 +79,7 @@ HEADERS = adler32.h \
   version.h \
   xtea.h\
   tea.h \
+  tx.h  \
 
 HEADERS-$(CONFIG_LZO)   += lzo.h
 
@@ -159,6 +160,7 @@ OBJS = adler32.o\
xga_font_data.o  \
xtea.o   \
tea.o   

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/14/19, Carl Eugen Hoyos  wrote:
>
>
>
>> Am 14.05.2019 um 19:17 schrieb Lynne :
>
>> I've attached the latest version.
>
> This patch is still not ok, please do not commit.
>

I will and you can not stop me.

> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

> Am 14.05.2019 um 19:17 schrieb Lynne :

> I've attached the latest version.

This patch is still not ok, please do not commit.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 14, 2019, 5:55 PM by one...@gmail.com:

> On 5/10/19, Lynne <> d...@lynne.ee > > wrote:
>
>> Patch updated again.
>> Made some more cleanups to the transforms, the tables and the main context.
>> API changed again, now the init function populates the function pointer for
>> transform.
>> I decided that having a separate function would encourage bad usage (e.g.
>> calling
>> the function every time before doing a transform rather than storing the
>> pointer) when
>> we're trying to avoid the overhead of function calls.
>> Also adjusted file names to match the API.
>>
>
> LGTM, going to apply soon.
>

I've attached the latest version. Not much changed, just some cleaning up, 
twiddle
adjustments to prepare for SIMD and making the scale argument a const.
I've removed AV_TX_NB, wasn't used, if needed it can be added without breaking 
the API.
Added #include  to tx.h as ptrdiff_t is defined there.

One thing to know when using it as an MDCT is that unlike ff_mdct_init where the
window size is required (e.g. for a 1024 sample MDCT you'd put in 2048 since 
that's
your window size), here the frame size is used, so you'd put in a length of 
1024 for
a 1024 sample MDCT (which has a window size of 2048 samples).
Not sure if it makes more sense in general, but we can't change behavior after 
its
pushed as it would break the API.

I've attached a diff which replaces the MDCT in aacenc, vorbisdec/enc, 
atrac9dec and
opusdec/enc with this one for testing. Passes FATE.

>From f7a8edb8c09af61b8f993da46b98d5c9b4d2002a Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Thu, 2 May 2019 15:07:12 +0100
Subject: [PATCH] libavutil: add an FFT & MDCT implementation

This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.

A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...

The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".

Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
  22353 decicycles in fftwf_execute, 1024 runs,  0 skips
  21836 decicycles in compound_fft_15x8, 1024 runs,  0 skips

128:
  22003 decicycles in   fftwf_execute,   1024 runs,  0 skips
  23132 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

384:
  75939 decicycles in  fftwf_execute,1024 runs,  0 skips
  73973 decicycles in compound_fft_3x128,1024 runs,  0 skips

640:
 104354 decicycles in   fftwf_execute,   1024 runs,  0 skips
 149518 decicycles in compound_fft_5x128,1024 runs,  0 skips

768:
 109323 decicycles in  fftwf_execute,1024 runs,  0 skips
 164096 decicycles in compound_fft_3x256,1024 runs,  0 skips

960:
 186210 decicycles in  fftwf_execute,1024 runs,  0 skips
 215256 decicycles in compound_fft_15x64,1024 runs,  0 skips

1024:
 163464 decicycles in   fftwf_execute,   1024 runs,  0 skips
 199686 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.

The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
It is unlikely that libavcodec/fft will be removed soon as there's much SIMD
written for exotic or old platforms there, but nevertheless new code
should use this new API throughout the project.

The implementation passes fate when used in Opus and AAC, and the output
is identical in ATRAC9 as well.
---
 libavutil/Makefile |   2 +
 libavutil/tx.c | 797 +
 libavutil/tx.h |  81 +
 3 files changed, 880 insertions(+)
 create mode 100644 libavutil/tx.c
 create mode 100644 libavutil/tx.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 53208fc587..8a7a44e4b5 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -79,6 

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/10/19, Lynne  wrote:
> Patch updated again.
> Made some more cleanups to the transforms, the tables and the main context.
> API changed again, now the init function populates the function pointer for
> transform.
> I decided that having a separate function would encourage bad usage (e.g.
> calling
> the function every time before doing a transform rather than storing the
> pointer) when
> we're trying to avoid the overhead of function calls.
> Also adjusted file names to match the API.
>
>

LGTM, going to apply soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/13/19, Carl Eugen Hoyos  wrote:
> Am Mo., 13. Mai 2019 um 13:31 Uhr schrieb Paul B Mahol :
>>
>> On 5/13/19, Carl Eugen Hoyos  wrote:
>> > Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :
>> >
>> >> I'll ignore Carl's messages for now as I agree with the others that
>> >> authorship is always
>> >> preserved through git history.
>> >
>> >> If he disagrees then it becomes a project-wide issue as
>> >> copyright headers have sometimes not been preserved through
>> >> refactoring.
>> >
>> > Sorry, I forgot: Mistakes can always happen.
>> > In this case though, we all agree that a code that was committed with a
>> > copyright notice gets moved.
>> >
>> >> I can give examples _in_another_thread_.
>>
>> I have myriad examples.
>
> Please point us to them: It is important that we fix
> such issues if we get informed.
>

See all filters.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 13:31 Uhr schrieb Paul B Mahol :
>
> On 5/13/19, Carl Eugen Hoyos  wrote:
> > Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :
> >
> >> I'll ignore Carl's messages for now as I agree with the others that
> >> authorship is always
> >> preserved through git history.
> >
> >> If he disagrees then it becomes a project-wide issue as
> >> copyright headers have sometimes not been preserved through refactoring.
> >
> > Sorry, I forgot: Mistakes can always happen.
> > In this case though, we all agree that a code that was committed with a
> > copyright notice gets moved.
> >
> >> I can give examples _in_another_thread_.
>
> I have myriad examples.

Please point us to them: It is important that we fix
such issues if we get informed.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/13/19, Carl Eugen Hoyos  wrote:
> Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :
>
>> I'll ignore Carl's messages for now as I agree with the others that
>> authorship is always
>> preserved through git history.
>
>> If he disagrees then it becomes a project-wide issue as
>> copyright headers have sometimes not been preserved through refactoring.
>
> Sorry, I forgot: Mistakes can always happen.
> In this case though, we all agree that a code that was committed with a
> copyright notice gets moved.
>
>> I can give examples _in_another_thread_.
>

I have myriad examples.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :

> I'll ignore Carl's messages for now as I agree with the others that 
> authorship is always
> preserved through git history.

> If he disagrees then it becomes a project-wide issue as
> copyright headers have sometimes not been preserved through refactoring.

Sorry, I forgot: Mistakes can always happen.
In this case though, we all agree that a code that was committed with a
copyright notice gets moved.

> I can give examples _in_another_thread_.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/13/19, Carl Eugen Hoyos  wrote:
> Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :
>
>> I'll ignore Carl's messages for now as I agree with the others that
>> authorship is always
>> preserved through git history.
>
> This is not the question here.
>
>> If he disagrees then it becomes a project-wide issue as
>> copyright headers have sometimes not been preserved through refactoring. I
>> can give
>> examples _in_another_thread_.
>
> Please do, I would like to fix them.
>
> Please understand that your current patch cannot be committed, the reason
> is that the push would be a copyright violation.
>

Please, stop writing nonsense.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 13:24 Uhr schrieb Lynne :

> I'll ignore Carl's messages for now as I agree with the others that 
> authorship is always
> preserved through git history.

This is not the question here.

> If he disagrees then it becomes a project-wide issue as
> copyright headers have sometimes not been preserved through refactoring. I 
> can give
> examples _in_another_thread_.

Please do, I would like to fix them.

Please understand that your current patch cannot be committed, the reason
is that the push would be a copyright violation.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 13, 2019, 9:53 AM by one...@gmail.com:

> On 5/13/19, Carl Eugen Hoyos <> ceffm...@gmail.com 
> > > wrote:
>
>> Am Mo., 13. Mai 2019 um 00:55 Uhr schrieb James Almer <>> jamr...@gmail.com 
>> >> >:
>>
>>>
>>> On 5/12/2019 7:42 PM, Carl Eugen Hoyos wrote:
>>> > Am So., 12. Mai 2019 um 23:58 Uhr schrieb Lynne <>>> d...@lynne.ee 
>>> > :
>>> >> I need *technical* feedback about the API.
>>> >
>>> > I understand that.
>>>
>>> Then, if you can't provide technical feedback, please stop replying
>>> to this thread (After you provide the source Hendrik requested).
>>>
>>
>> Could you please stop this?
>>
>> It doesn't matter where you live, and it doesn't matter which license
>> you use, you are not allowed to remove a copyright statement that
>> was put on top of a source file.
>>
>> It is arguably not always as clear as in this case, but since it was
>> explained where the code comes from, there is really no question
>> about this.
>>
>
> Do we need yet another voting for this one?
>

Please do, then this thread can be left alone and I can get some actual 
feedback.

I'll ignore Carl's messages for now as I agree with the others that authorship 
is always
preserved through git history. If he disagrees then it becomes a project-wide 
issue as
copyright headers have sometimes not been preserved through refactoring. I can 
give
examples _in_another_thread_.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/13/19, Carl Eugen Hoyos  wrote:
> Am Mo., 13. Mai 2019 um 00:55 Uhr schrieb James Almer :
>>
>> On 5/12/2019 7:42 PM, Carl Eugen Hoyos wrote:
>> > Am So., 12. Mai 2019 um 23:58 Uhr schrieb Lynne :
>> >> I need *technical* feedback about the API.
>> >
>> > I understand that.
>>
>> Then, if you can't provide technical feedback, please stop replying
>> to this thread (After you provide the source Hendrik requested).
>
> Could you please stop this?
>
> It doesn't matter where you live, and it doesn't matter which license
> you use, you are not allowed to remove a copyright statement that
> was put on top of a source file.
>
> It is arguably not always as clear as in this case, but since it was
> explained where the code comes from, there is really no question
> about this.

Do we need yet another voting for this one?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Hendrik Leppkes]

On Mon, May 13, 2019 at 8:57 AM Reimar Döffinger
 wrote:
>
> On 13.05.2019, at 04:54, Pedro Arthur  wrote:
>
> > Em dom, 12 de mai de 2019 às 18:11, Hendrik Leppkes
> >  escreveu:
> >>
> >> On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos  
> >> wrote:
> >>>
> >>> But seriously: We are of course not allowed to remove copyright
> >>> statements, no matter if we consider them relevant or not.
> >>>
> >>
> >> Please provide a source for such claims.
> > The GPL license included in the header states that.
> >
> > GPL2 [1] - "keep intact all the notices that refer to this License"
> > GPL3 [2]  - "Requiring preservation of specified reasonable legal
> > notices or author attributions in that material"
> > MIT [3] (for completeness) - "The above copyright notice and this
> > permission notice shall be included in all copies or substantial
> > portions of the Software."
> >
> > [1] - https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
> > [2] - http://www.gnu.org/licenses/gpl.html
> > [3] - https://opensource.org/licenses/MI
>
> Besides the direct legals and ethics of it, please note that it also creates a
> serious (even if unlikely) risk to us and our users.
> In any kind of legal case, whether to defend against some "copyright troll" 
> or to
> enforce the license it might become necessary to find the author of the code.
> Not properly taking care of the license and copyright statement side exposes 
> our
> users to unnecessary risk and makes it harder to enforce our license.
> Even if nothing happens, the work companies have to do to show compliance
> (because their customers require it or to reduce their risk) becomes much 
> harder.
> Which is why the Linux kernel currently is working on cleaning up their 
> license
> header mess.
>

This argument is not really applicable because the headers do not
actually let you identify who holds all the copyright over the code in
the file. You need to go dig through years of Git history.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Reimar Döffinger]

On 13.05.2019, at 04:54, Pedro Arthur  wrote:

> Em dom, 12 de mai de 2019 às 18:11, Hendrik Leppkes
>  escreveu:
>> 
>> On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos  wrote:
>>> 
>>> But seriously: We are of course not allowed to remove copyright
>>> statements, no matter if we consider them relevant or not.
>>> 
>> 
>> Please provide a source for such claims.
> The GPL license included in the header states that.
> 
> GPL2 [1] - "keep intact all the notices that refer to this License"
> GPL3 [2]  - "Requiring preservation of specified reasonable legal
> notices or author attributions in that material"
> MIT [3] (for completeness) - "The above copyright notice and this
> permission notice shall be included in all copies or substantial
> portions of the Software."
> 
> [1] - https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
> [2] - http://www.gnu.org/licenses/gpl.html
> [3] - https://opensource.org/licenses/MI

Besides the direct legals and ethics of it, please note that it also creates a
serious (even if unlikely) risk to us and our users.
In any kind of legal case, whether to defend against some "copyright troll" or 
to
enforce the license it might become necessary to find the author of the code.
Not properly taking care of the license and copyright statement side exposes our
users to unnecessary risk and makes it harder to enforce our license.
Even if nothing happens, the work companies have to do to show compliance
(because their customers require it or to reduce their risk) becomes much 
harder.
Which is why the Linux kernel currently is working on cleaning up their license
header mess.

Best regards,
Reimar Döffinger
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Pedro Arthur]

Em dom, 12 de mai de 2019 às 18:11, Hendrik Leppkes
 escreveu:
>
> On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos  wrote:
> >
> > But seriously: We are of course not allowed to remove copyright
> > statements, no matter if we consider them relevant or not.
> >
>
> Please provide a source for such claims.
The GPL license included in the header states that.

GPL2 [1] - "keep intact all the notices that refer to this License"
GPL3 [2]  - "Requiring preservation of specified reasonable legal
notices or author attributions in that material"
MIT [3] (for completeness) - "The above copyright notice and this
permission notice shall be included in all copies or substantial
portions of the Software."

[1] - https://www.gnu.org/licenses/old-licenses/gpl-2.0.html
[2] - http://www.gnu.org/licenses/gpl.html
[3] - https://opensource.org/licenses/MIT
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Mo., 13. Mai 2019 um 00:55 Uhr schrieb James Almer :
>
> On 5/12/2019 7:42 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Mai 2019 um 23:58 Uhr schrieb Lynne :
> >> I need *technical* feedback about the API.
> >
> > I understand that.
>
> Then, if you can't provide technical feedback, please stop replying
> to this thread (After you provide the source Hendrik requested).

Could you please stop this?

It doesn't matter where you live, and it doesn't matter which license
you use, you are not allowed to remove a copyright statement that
was put on top of a source file.

It is arguably not always as clear as in this case, but since it was
explained where the code comes from, there is really no question
about this.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[James Almer]

On 5/12/2019 7:42 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Mai 2019 um 23:58 Uhr schrieb Lynne :
>> I need *technical* feedback about the API.
> 
> I understand that.

Then, if you can't provide technical feedback, please stop replying to
this thread (After you provide the source Hendrik requested).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 23:58 Uhr schrieb Lynne :
> I need *technical* feedback about the API.

I understand that.

Please understand that the patch cannot be committed as-is.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 12, 2019, 10:04 PM by ceffm...@gmail.com:

>
> Yes, and this is the reason why we must not remove the names
> of those present (they also hold a copyright, not just those whose
> names are missing).
>
>

Please go and discuss the project and the world's attitude and policy towards 
copyright
notices in another thread.

I need *technical* feedback about the API. I would also like to have someone 
take a quick
look at the implementation, although I'm confident its okay and as optimal as a 
generic
software implementation could be. Accuracy-wise its slightly better than 
libfftw3f, due to
the use of reordering for nptwo transform direction and the compound 15-point 
FFT
(less operations due to the lack of inter-stage twiddles).
Can provide a benchmarking test program on IRC.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Hendrik Leppkes]

On Sun, May 12, 2019 at 11:05 PM Carl Eugen Hoyos  wrote:
>
> But seriously: We are of course not allowed to remove copyright
> statements, no matter if we consider them relevant or not.
>

Please provide a source for such claims.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 22:59 Uhr schrieb Hendrik Leppkes :
>
> On Sun, May 12, 2019 at 10:38 PM Carl Eugen Hoyos  wrote:
> >
> > Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
> > >
> > > On 5/12/19, Carl Eugen Hoyos  wrote:
> > > > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
> > > >>
> > > >> Patch updated again.
> > > >> Made some more cleanups to the transforms, the tables and the main
> > > >> context.
> > > >> API changed again, now the init function populates the function pointer
> > > >> for transform.
> > > >> I decided that having a separate function would encourage bad usage 
> > > >> (e.g.
> > > >> calling
> > > >> the function every time before doing a transform rather than storing 
> > > >> the
> > > >> pointer) when
> > > >> we're trying to avoid the overhead of function calls.
> > > >> Also adjusted file names to match the API.
> > > >
> > > > As said, this patch is not ok as long as the copyright statements are
> > > > missing.
> > > >
> > >
> > > You are mislead. No statements are necessary.
> >
> > Why do you think so?
> >
> > The commit message states that a part of the code is coming
> > from a file with an extensive copyright statement: Why would
> > it be ok to remove it?
>
> The names at the top of the file are always going to be inaccurate,

Possibly.

> and as such meaningless,

(Impossible to parse)

> because everyone that changed the file in a
> meaningful way holds a copyright over those changes,

Of course!

> and not everyone is added to that list

True.

> (typically, no-one beyond the original author is present there).

Depending on the meaning of "typically" this may be true
(but is probably "meaningless").

> Since the list is not complete, and as such does not allow you to
> identify who actually holds all the copyright in such a file, its not
> legally relevant.

This is - to quote a Viennese scientist - not even wrong;-)

But seriously: We are of course not allowed to remove copyright
statements, no matter if we consider them relevant or not.

> Everyone of the authors still hold a copyright no matter if the name
> is present there, or not.

Yes, and this is the reason why we must not remove the names
of those present (they also hold a copyright, not just those whose
names are missing).

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Hendrik Leppkes]

On Sun, May 12, 2019 at 10:38 PM Carl Eugen Hoyos  wrote:
>
> Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
> >
> > On 5/12/19, Carl Eugen Hoyos  wrote:
> > > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
> > >>
> > >> Patch updated again.
> > >> Made some more cleanups to the transforms, the tables and the main
> > >> context.
> > >> API changed again, now the init function populates the function pointer
> > >> for transform.
> > >> I decided that having a separate function would encourage bad usage (e.g.
> > >> calling
> > >> the function every time before doing a transform rather than storing the
> > >> pointer) when
> > >> we're trying to avoid the overhead of function calls.
> > >> Also adjusted file names to match the API.
> > >
> > > As said, this patch is not ok as long as the copyright statements are
> > > missing.
> > >
> >
> > You are mislead. No statements are necessary.
>
> Why do you think so?
>
> The commit message states that a part of the code is coming
> from a file with an extensive copyright statement: Why would
> it be ok to remove it?
>

The names at the top of the file are always going to be inaccurate,
and as such meaningless, because everyone that changed the file in a
meaningful way holds a copyright over those changes, and not everyone
is added to that list (typically, no-one beyond the original author is
present there).
Since the list is not complete, and as such does not allow you to
identify who actually holds all the copyright in such a file, its not
legally relevant.

Everyone of the authors still hold a copyright no matter if the name
is present there, or not.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 22:40 Uhr schrieb Paul B Mahol :
>
> On 5/12/19, Carl Eugen Hoyos  wrote:
> > Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
> >>
> >> On 5/12/19, Carl Eugen Hoyos  wrote:
> >> > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
> >> >>
> >> >> Patch updated again.
> >> >> Made some more cleanups to the transforms, the tables and the main
> >> >> context.
> >> >> API changed again, now the init function populates the function pointer
> >> >> for transform.
> >> >> I decided that having a separate function would encourage bad usage
> >> >> (e.g.
> >> >> calling
> >> >> the function every time before doing a transform rather than storing
> >> >> the
> >> >> pointer) when
> >> >> we're trying to avoid the overhead of function calls.
> >> >> Also adjusted file names to match the API.
> >> >
> >> > As said, this patch is not ok as long as the copyright statements are
> >> > missing.
> >> >
> >>
> >> You are mislead. No statements are necessary.
> >
> > Why do you think so?
> >
> > The commit message states that a part of the code is coming
> > from a file with an extensive copyright statement: Why would
> > it be ok to remove it?
>
> Are you  sure white-space is copyright-able?

I am sure that white-space is generally not copyrightable but
Lynne claimed he copied actual code from libavcodec.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/12/19, Carl Eugen Hoyos  wrote:
> Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
>>
>> Patch updated again.
>> Made some more cleanups to the transforms, the tables and the main
>> context.
>> API changed again, now the init function populates the function pointer
>> for transform.
>> I decided that having a separate function would encourage bad usage (e.g.
>> calling
>> the function every time before doing a transform rather than storing the
>> pointer) when
>> we're trying to avoid the overhead of function calls.
>> Also adjusted file names to match the API.
>
> As said, this patch is not ok as long as the copyright statements are
> missing.
>

You are mislead. No statements are necessary.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
>
> On 5/12/19, Carl Eugen Hoyos  wrote:
> > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
> >>
> >> Patch updated again.
> >> Made some more cleanups to the transforms, the tables and the main
> >> context.
> >> API changed again, now the init function populates the function pointer
> >> for transform.
> >> I decided that having a separate function would encourage bad usage (e.g.
> >> calling
> >> the function every time before doing a transform rather than storing the
> >> pointer) when
> >> we're trying to avoid the overhead of function calls.
> >> Also adjusted file names to match the API.
> >
> > As said, this patch is not ok as long as the copyright statements are
> > missing.
> >
>
> You are mislead. No statements are necessary.

Why do you think so?

The commit message states that a part of the code is coming
from a file with an extensive copyright statement: Why would
it be ok to remove it?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Paul B Mahol]

On 5/12/19, Carl Eugen Hoyos  wrote:
> Am So., 12. Mai 2019 um 22:37 Uhr schrieb Paul B Mahol :
>>
>> On 5/12/19, Carl Eugen Hoyos  wrote:
>> > Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
>> >>
>> >> Patch updated again.
>> >> Made some more cleanups to the transforms, the tables and the main
>> >> context.
>> >> API changed again, now the init function populates the function pointer
>> >> for transform.
>> >> I decided that having a separate function would encourage bad usage
>> >> (e.g.
>> >> calling
>> >> the function every time before doing a transform rather than storing
>> >> the
>> >> pointer) when
>> >> we're trying to avoid the overhead of function calls.
>> >> Also adjusted file names to match the API.
>> >
>> > As said, this patch is not ok as long as the copyright statements are
>> > missing.
>> >
>>
>> You are mislead. No statements are necessary.
>
> Why do you think so?
>
> The commit message states that a part of the code is coming
> from a file with an extensive copyright statement: Why would
> it be ok to remove it?
>

Are you  sure white-space is copyright-able?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Fr., 10. Mai 2019 um 17:15 Uhr schrieb Lynne :
>
> Patch updated again.
> Made some more cleanups to the transforms, the tables and the main context.
> API changed again, now the init function populates the function pointer for 
> transform.
> I decided that having a separate function would encourage bad usage (e.g. 
> calling
> the function every time before doing a transform rather than storing the 
> pointer) when
> we're trying to avoid the overhead of function calls.
> Also adjusted file names to match the API.

As said, this patch is not ok as long as the copyright statements are missing.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 02:51 Uhr schrieb Pedro Arthur :
>
> Em sáb, 11 de mai de 2019 às 20:26, James Almer  escreveu:
> >
> > On 5/11/2019 8:08 PM, Carl Eugen Hoyos wrote:
> > > Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
> > >>
> > >> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
> > >>
> > >>> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> > >>> > >:
> > >>>
> > 
> >  May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
> >  >> :
> > 
> > > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> > > >>  > d...@lynne.ee 
> > > >> >> >:
> > >
> > >>
> > >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee 
> > >> >>  > d...@lynne.ee 
> > >> >> >>> :
> > >>
> > >>> Patch updated again.
> > >>> Made some more cleanups to the transforms, the tables and the main 
> > >>> context.
> > >>> API changed again, now the init function populates the function 
> > >>> pointer for transform.
> > >>> I decided that having a separate function would encourage bad usage 
> > >>> (e.g. calling
> > >>> the function every time before doing a transform rather than 
> > >>> storing the pointer) when
> > >>> we're trying to avoid the overhead of function calls.
> > >>> Also adjusted file names to match the API.
> > >>>
> > >>
> > >> Forgot to change an include, new patch attached.
> > >>
> > >
> > > If I understand the commit message correctly, some of the code
> > > in the new file you are adding comes from other parts of FFmpeg.
> > > I am surprised that there is no copyright claim on the top of this
> > > new file.
> > > Is there none on top of the files you took the code from?
> > >
> > 
> >  The project isn't consistent with updating nor putting copyright 
> >  headers on files so
> >  I'd rather keep the headers clean. Commit messages and authors are the 
> >  only way to
> >  know who authored what.
> > 
> > >>>
> > >>> I don't think this is correct, but that is not the question: Copyright
> > >>> law is (at least here)
> > >>> very clear, if somebody put his name on top of the file, you must not 
> > >>> remove it,
> > >>> especially not when moving code from one file into another.
> > >>>
> > >>
> > >> "Here"? You're probably referring to some county's laws, those don't 
> > >> apply universally,
> > >> especially not to the internet.
> > >> Either way, that rule hasn't really been respected despite the major 
> > >> refactoring that has
> > >> happened in the past so I don't see why it has to be respected now.
> > >
> > > Please point me to the commit you indicate so I can fix this (claimed) 
> > > copyright
> > > violation.
> > >
> > >> The only parts I didn't rewrite are the power of two FFT, which I can 
> > >> NIH in a week if
> > >> necessary, and in fact lately with the research papers I've recently 
> > >> read I'm thinking
> > >> I should.
> > >
> > > Why don't you simply copy the copyright statement from the file where you 
> > > copied
> > > it from instead (if there is one)?
> > > Wouldn't that be much quicker than this email exchange?
> > >
> > > Carl Eugen
> >
> > The commit message already states it takes parts of lavc's fft
> > implementation, and the git story can't be rewritten, so authorship is
> > known or can be easily figured out. Could we please focus on technical
> > matters instead of wasting time in a back and forth about stuff like this?
> >
>
> Not saying this is the case, but if one interprets it as copying the
> code, adding more code, removing some parts, and removing the
> copyrights previously present it is clearly violating the license.
> It seems wise to include copyrights from original code in the file.

Except if there never was a copyright notice in the original file.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Pedro Arthur]

Em sáb, 11 de mai de 2019 às 20:26, James Almer  escreveu:
>
> On 5/11/2019 8:08 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
> >>
> >> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
> >>
> >>> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> >>> > >:
> >>>
> 
>  May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
>  >> :
> 
> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> > >>  > d...@lynne.ee 
> > >> >> >:
> >
> >>
> >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
> >> > d...@lynne.ee >> >>> :
> >>
> >>> Patch updated again.
> >>> Made some more cleanups to the transforms, the tables and the main 
> >>> context.
> >>> API changed again, now the init function populates the function 
> >>> pointer for transform.
> >>> I decided that having a separate function would encourage bad usage 
> >>> (e.g. calling
> >>> the function every time before doing a transform rather than storing 
> >>> the pointer) when
> >>> we're trying to avoid the overhead of function calls.
> >>> Also adjusted file names to match the API.
> >>>
> >>
> >> Forgot to change an include, new patch attached.
> >>
> >
> > If I understand the commit message correctly, some of the code
> > in the new file you are adding comes from other parts of FFmpeg.
> > I am surprised that there is no copyright claim on the top of this
> > new file.
> > Is there none on top of the files you took the code from?
> >
> 
>  The project isn't consistent with updating nor putting copyright headers 
>  on files so
>  I'd rather keep the headers clean. Commit messages and authors are the 
>  only way to
>  know who authored what.
> 
> >>>
> >>> I don't think this is correct, but that is not the question: Copyright
> >>> law is (at least here)
> >>> very clear, if somebody put his name on top of the file, you must not 
> >>> remove it,
> >>> especially not when moving code from one file into another.
> >>>
> >>
> >> "Here"? You're probably referring to some county's laws, those don't apply 
> >> universally,
> >> especially not to the internet.
> >> Either way, that rule hasn't really been respected despite the major 
> >> refactoring that has
> >> happened in the past so I don't see why it has to be respected now.
> >
> > Please point me to the commit you indicate so I can fix this (claimed) 
> > copyright
> > violation.
> >
> >> The only parts I didn't rewrite are the power of two FFT, which I can NIH 
> >> in a week if
> >> necessary, and in fact lately with the research papers I've recently read 
> >> I'm thinking
> >> I should.
> >
> > Why don't you simply copy the copyright statement from the file where you 
> > copied
> > it from instead (if there is one)?
> > Wouldn't that be much quicker than this email exchange?
> >
> > Carl Eugen
>
> The commit message already states it takes parts of lavc's fft
> implementation, and the git story can't be rewritten, so authorship is
> known or can be easily figured out. Could we please focus on technical
> matters instead of wasting time in a back and forth about stuff like this?
>

Not saying this is the case, but if one interprets it as copying the
code, adding more code, removing some parts, and removing the
copyrights previously present it is clearly violating the license.
It seems wise to include copyrights from original code in the file.

> Thanks.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 01:26 Uhr schrieb James Almer :
>
> On 5/11/2019 8:08 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
> >>
> >> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
> >>
> >>> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> >>> > >:
> >>>
> 
>  May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
>  >> :
> 
> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> > >>  > d...@lynne.ee 
> > >> >> >:
> >
> >>
> >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
> >> > d...@lynne.ee >> >>> :
> >>
> >>> Patch updated again.
> >>> Made some more cleanups to the transforms, the tables and the main 
> >>> context.
> >>> API changed again, now the init function populates the function 
> >>> pointer for transform.
> >>> I decided that having a separate function would encourage bad usage 
> >>> (e.g. calling
> >>> the function every time before doing a transform rather than storing 
> >>> the pointer) when
> >>> we're trying to avoid the overhead of function calls.
> >>> Also adjusted file names to match the API.
> >>>
> >>
> >> Forgot to change an include, new patch attached.
> >>
> >
> > If I understand the commit message correctly, some of the code
> > in the new file you are adding comes from other parts of FFmpeg.
> > I am surprised that there is no copyright claim on the top of this
> > new file.
> > Is there none on top of the files you took the code from?
> >
> 
>  The project isn't consistent with updating nor putting copyright headers 
>  on files so
>  I'd rather keep the headers clean. Commit messages and authors are the 
>  only way to
>  know who authored what.
> 
> >>>
> >>> I don't think this is correct, but that is not the question: Copyright
> >>> law is (at least here)
> >>> very clear, if somebody put his name on top of the file, you must not 
> >>> remove it,
> >>> especially not when moving code from one file into another.
> >>>
> >>
> >> "Here"? You're probably referring to some county's laws, those don't apply 
> >> universally,
> >> especially not to the internet.
> >> Either way, that rule hasn't really been respected despite the major 
> >> refactoring that has
> >> happened in the past so I don't see why it has to be respected now.
> >
> > Please point me to the commit you indicate so I can fix this (claimed) 
> > copyright
> > violation.
> >
> >> The only parts I didn't rewrite are the power of two FFT, which I can NIH 
> >> in a week if
> >> necessary, and in fact lately with the research papers I've recently read 
> >> I'm thinking
> >> I should.
> >
> > Why don't you simply copy the copyright statement from the file where you 
> > copied
> > it from instead (if there is one)?
> > Wouldn't that be much quicker than this email exchange?
> >
> > Carl Eugen
>
> The commit message already states it takes parts of lavc's fft
> implementation, and the git story can't be rewritten, so authorship is
> known or can be easily figured out. Could we please focus on technical
> matters instead of wasting time in a back and forth about stuff like this?

Are you talking about wasting time with copyright violations?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[James Almer]

On 5/11/2019 8:08 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
>>
>> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
>>
>>> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
>>> > >:
>>>

 May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
 >> :

> Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> >>  > d...@lynne.ee 
> >> >> >:
>
>>
>> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
>> > d...@lynne.ee >> >>> :
>>
>>> Patch updated again.
>>> Made some more cleanups to the transforms, the tables and the main 
>>> context.
>>> API changed again, now the init function populates the function pointer 
>>> for transform.
>>> I decided that having a separate function would encourage bad usage 
>>> (e.g. calling
>>> the function every time before doing a transform rather than storing 
>>> the pointer) when
>>> we're trying to avoid the overhead of function calls.
>>> Also adjusted file names to match the API.
>>>
>>
>> Forgot to change an include, new patch attached.
>>
>
> If I understand the commit message correctly, some of the code
> in the new file you are adding comes from other parts of FFmpeg.
> I am surprised that there is no copyright claim on the top of this
> new file.
> Is there none on top of the files you took the code from?
>

 The project isn't consistent with updating nor putting copyright headers 
 on files so
 I'd rather keep the headers clean. Commit messages and authors are the 
 only way to
 know who authored what.

>>>
>>> I don't think this is correct, but that is not the question: Copyright
>>> law is (at least here)
>>> very clear, if somebody put his name on top of the file, you must not 
>>> remove it,
>>> especially not when moving code from one file into another.
>>>
>>
>> "Here"? You're probably referring to some county's laws, those don't apply 
>> universally,
>> especially not to the internet.
>> Either way, that rule hasn't really been respected despite the major 
>> refactoring that has
>> happened in the past so I don't see why it has to be respected now.
> 
> Please point me to the commit you indicate so I can fix this (claimed) 
> copyright
> violation.
> 
>> The only parts I didn't rewrite are the power of two FFT, which I can NIH in 
>> a week if
>> necessary, and in fact lately with the research papers I've recently read 
>> I'm thinking
>> I should.
> 
> Why don't you simply copy the copyright statement from the file where you 
> copied
> it from instead (if there is one)?
> Wouldn't that be much quicker than this email exchange?
> 
> Carl Eugen

The commit message already states it takes parts of lavc's fft
implementation, and the git story can't be rewritten, so authorship is
known or can be easily figured out. Could we please focus on technical
matters instead of wasting time in a back and forth about stuff like this?

Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
>
> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
>
> > Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> > > >:
> >
> >>
> >> May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
> >> >> :
> >>
> >> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> >> > >>  > d...@lynne.ee 
> >> > >> >> >:
> >> >
> >> >>
> >> >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
> >> >> > d...@lynne.ee >> >>> :
> >> >>
> >> >> > Patch updated again.
> >> >> > Made some more cleanups to the transforms, the tables and the main 
> >> >> > context.
> >> >> > API changed again, now the init function populates the function 
> >> >> > pointer for transform.
> >> >> > I decided that having a separate function would encourage bad usage 
> >> >> > (e.g. calling
> >> >> > the function every time before doing a transform rather than storing 
> >> >> > the pointer) when
> >> >> > we're trying to avoid the overhead of function calls.
> >> >> > Also adjusted file names to match the API.
> >> >> >
> >> >>
> >> >> Forgot to change an include, new patch attached.
> >> >>
> >> >
> >> > If I understand the commit message correctly, some of the code
> >> > in the new file you are adding comes from other parts of FFmpeg.
> >> > I am surprised that there is no copyright claim on the top of this
> >> > new file.
> >> > Is there none on top of the files you took the code from?
> >> >
> >>
> >> The project isn't consistent with updating nor putting copyright headers 
> >> on files so
> >> I'd rather keep the headers clean. Commit messages and authors are the 
> >> only way to
> >> know who authored what.
> >>
> >
> > I don't think this is correct, but that is not the question: Copyright
> > law is (at least here)
> > very clear, if somebody put his name on top of the file, you must not 
> > remove it,
> > especially not when moving code from one file into another.
> >
>
> "Here"? You're probably referring to some county's laws, those don't apply 
> universally,
> especially not to the internet.
> Either way, that rule hasn't really been respected despite the major 
> refactoring that has
> happened in the past so I don't see why it has to be respected now.

Please point me to the commit you indicate so I can fix this (claimed) copyright
violation.

> The only parts I didn't rewrite are the power of two FFT, which I can NIH in 
> a week if
> necessary, and in fact lately with the research papers I've recently read I'm 
> thinking
> I should.

Why don't you simply copy the copyright statement from the file where you copied
it from instead (if there is one)?
Wouldn't that be much quicker than this email exchange?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 11, 2019, 11:08 PM by ceffm...@gmail.com:

> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> > >:
>
>>
>> May 10, 2019, 8:59 PM by >> ceffm...@gmail.com >> 
>> :
>>
>> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
>> > >>  > d...@lynne.ee 
>> > >> >> >:
>> >
>> >>
>> >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
>> >> > d...@lynne.ee >> >>> :
>> >>
>> >> > Patch updated again.
>> >> > Made some more cleanups to the transforms, the tables and the main 
>> >> > context.
>> >> > API changed again, now the init function populates the function pointer 
>> >> > for transform.
>> >> > I decided that having a separate function would encourage bad usage 
>> >> > (e.g. calling
>> >> > the function every time before doing a transform rather than storing 
>> >> > the pointer) when
>> >> > we're trying to avoid the overhead of function calls.
>> >> > Also adjusted file names to match the API.
>> >> >
>> >>
>> >> Forgot to change an include, new patch attached.
>> >>
>> >
>> > If I understand the commit message correctly, some of the code
>> > in the new file you are adding comes from other parts of FFmpeg.
>> > I am surprised that there is no copyright claim on the top of this
>> > new file.
>> > Is there none on top of the files you took the code from?
>> >
>>
>> The project isn't consistent with updating nor putting copyright headers on 
>> files so
>> I'd rather keep the headers clean. Commit messages and authors are the only 
>> way to
>> know who authored what.
>>
>
> I don't think this is correct, but that is not the question: Copyright
> law is (at least here)
> very clear, if somebody put his name on top of the file, you must not remove 
> it,
> especially not when moving code from one file into another.
>

"Here"? You're probably referring to some county's laws, those don't apply 
universally,
especially not to the internet.
Either way, that rule hasn't really been respected despite the major 
refactoring that has
happened in the past so I don't see why it has to be respected now.
The only parts I didn't rewrite are the power of two FFT, which I can NIH in a 
week if
necessary, and in fact lately with the research papers I've recently read I'm 
thinking
I should.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne :
>
> May 10, 2019, 8:59 PM by ceffm...@gmail.com:
>
> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> d...@lynne.ee 
> > > >:
> >
> >>
> >> May 10, 2019, 4:14 PM by >> d...@lynne.ee >> :
> >>
> >> > Patch updated again.
> >> > Made some more cleanups to the transforms, the tables and the main 
> >> > context.
> >> > API changed again, now the init function populates the function pointer 
> >> > for transform.
> >> > I decided that having a separate function would encourage bad usage 
> >> > (e.g. calling
> >> > the function every time before doing a transform rather than storing the 
> >> > pointer) when
> >> > we're trying to avoid the overhead of function calls.
> >> > Also adjusted file names to match the API.
> >> >
> >>
> >> Forgot to change an include, new patch attached.
> >>
> >
> > If I understand the commit message correctly, some of the code
> > in the new file you are adding comes from other parts of FFmpeg.
> > I am surprised that there is no copyright claim on the top of this
> > new file.
> > Is there none on top of the files you took the code from?
> >
>
> The project isn't consistent with updating nor putting copyright headers on 
> files so
> I'd rather keep the headers clean. Commit messages and authors are the only 
> way to
> know who authored what.

I don't think this is correct, but that is not the question: Copyright
law is (at least here)
very clear, if somebody put his name on top of the file, you must not remove it,
especially not when moving code from one file into another.

> I could credit the authors fully in the commit message, then authorship can 
> still be
> tracked and the headers will be clean.

There is nothing wrong with putting the authors in the commit message, this can
not replace the notice on top of the files though.

This of course only applies if there is such a notice in existing
files from which
you move or copy code.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 10, 2019, 8:59 PM by ceffm...@gmail.com:

> Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> d...@lynne.ee 
> > >:
>
>>
>> May 10, 2019, 4:14 PM by >> d...@lynne.ee >> :
>>
>> > Patch updated again.
>> > Made some more cleanups to the transforms, the tables and the main context.
>> > API changed again, now the init function populates the function pointer 
>> > for transform.
>> > I decided that having a separate function would encourage bad usage (e.g. 
>> > calling
>> > the function every time before doing a transform rather than storing the 
>> > pointer) when
>> > we're trying to avoid the overhead of function calls.
>> > Also adjusted file names to match the API.
>> >
>>
>> Forgot to change an include, new patch attached.
>>
>
> If I understand the commit message correctly, some of the code
> in the new file you are adding comes from other parts of FFmpeg.
> I am surprised that there is no copyright claim on the top of this
> new file.
> Is there none on top of the files you took the code from?
>

The project isn't consistent with updating nor putting copyright headers on 
files so
I'd rather keep the headers clean. Commit messages and authors are the only way 
to
know who authored what.
I could credit the authors fully in the commit message, then authorship can 
still be tracked
and the headers will be clean.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne :
>
> May 10, 2019, 4:14 PM by d...@lynne.ee:
>
> > Patch updated again.
> > Made some more cleanups to the transforms, the tables and the main context.
> > API changed again, now the init function populates the function pointer for 
> > transform.
> > I decided that having a separate function would encourage bad usage (e.g. 
> > calling
> > the function every time before doing a transform rather than storing the 
> > pointer) when
> > we're trying to avoid the overhead of function calls.
> > Also adjusted file names to match the API.
> >
>
> Forgot to change an include, new patch attached.

If I understand the commit message correctly, some of the code
in the new file you are adding comes from other parts of FFmpeg.
I am surprised that there is no copyright claim on the top of this
new file.
Is there none on top of the files you took the code from?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 10, 2019, 4:14 PM by d...@lynne.ee:

> Patch updated again.
> Made some more cleanups to the transforms, the tables and the main context.
> API changed again, now the init function populates the function pointer for 
> transform.
> I decided that having a separate function would encourage bad usage (e.g. 
> calling
> the function every time before doing a transform rather than storing the 
> pointer) when
> we're trying to avoid the overhead of function calls.
> Also adjusted file names to match the API.
>

Forgot to change an include, new patch attached.
>From c20808a88d3e2acde12a5de293262ca95b92f5a5 Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Thu, 2 May 2019 15:07:12 +0100
Subject: [PATCH v3] libavutil: add an FFT & MDCT implementation

This commit adds a new API to libavutil to allow for arbitrary transformations
on various types of data.
This is a partly new implementation, with the power of two transforms taken
from libavcodec/fft_template, the 5 and 15-point FFT taken from mdct15, while
the 3-point FFT was written from scratch.
The (i)mdct folding code is taken from mdct15 as well, as the mdct_template
code was somewhat old, messy and not easy to separate.

A notable feature of this implementation is that it allows for 3xM and 5xM
based transforms, where M is a power of two, e.g. 384, 640, 768, 1280, etc.
AC-4 uses 3xM transforms while Siren uses 5xM transforms, so the code will
allow for decoding of such streams.
A non-exaustive list of supported sizes:
4, 8, 12, 16, 20, 24, 32, 40, 48, 60, 64, 80, 96, 120, 128, 160, 192, 240,
256, 320, 384, 480, 512, 640, 768, 960, 1024, 1280, 1536, 1920, 2048, 2560...

The API was designed such that it allows for not only 1D transforms but also
2D transforms of certain block sizes. This was partly on accident as the stride
argument is required for Opus MDCTs, but can be used in the context of a 2D
transform as well.
Also, various data types would be implemented eventually as well, such as
"double" and "int32_t".

Some performance comparisons with libfftw3f (SIMD disabled for both):
120:
  22353 decicycles in fftwf_execute, 1024 runs,  0 skips
  21836 decicycles in compound_fft_15x8, 1024 runs,  0 skips

128:
  22003 decicycles in   fftwf_execute,   1024 runs,  0 skips
  23132 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

384:
  75939 decicycles in  fftwf_execute,1024 runs,  0 skips
  73973 decicycles in compound_fft_3x128,1024 runs,  0 skips

640:
 104354 decicycles in   fftwf_execute,   1024 runs,  0 skips
 149518 decicycles in compound_fft_5x128,1024 runs,  0 skips

768:
 109323 decicycles in  fftwf_execute,1024 runs,  0 skips
 164096 decicycles in compound_fft_3x256,1024 runs,  0 skips

960:
 186210 decicycles in  fftwf_execute,1024 runs,  0 skips
 215256 decicycles in compound_fft_15x64,1024 runs,  0 skips

1024:
 163464 decicycles in   fftwf_execute,   1024 runs,  0 skips
 199686 decicycles in monolithic_fft_ptwo,   1024 runs,  0 skips

With SIMD we should be faster than fftw for 15xM transforms as our fft15 SIMD
is around 2x faster than theirs, even if our ptwo SIMD is slightly slower.

The goal is to remove the libavcodec/mdct15 code and deprecate the
libavcodec/avfft interface once aarch64 and x86 SIMD code has been ported.
It is unlikely that libavcodec/fft will be removed soon as there's much SIMD
written for exotic or old platforms there, but nevertheless new code
should use this new API throughout the project.

The implementation passes fate when used in Opus and AAC, and the output
is identical in ATRAC9 as well.
---
 libavutil/Makefile |   2 +
 libavutil/tx.c | 781 +
 libavutil/tx.h |  85 +
 3 files changed, 868 insertions(+)
 create mode 100644 libavutil/tx.c
 create mode 100644 libavutil/tx.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 53208fc587..8a7a44e4b5 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -79,6 +79,7 @@ HEADERS = adler32.h \
   version.h \
   xtea.h\
   tea.h \
+  tx.h  \
 
 HEADERS-$(CONFIG_LZO)   += lzo.h
 
@@ -159,6 +160,7 @@ OBJS = adler32.o\
xga_font_data.o  \
xtea.o   \
tea.o\
+   tx.o \
 
 OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
 OBJS-$(CONFIG_D3D11VA)  +=