[FFmpeg-devel] [PATCH] swresample/resample: speed up build_filter

Ganesh Ajjanagadde gajjanag at mit.edu
Wed Nov 4 16:07:20 CET 2015


On Wed, Nov 4, 2015 at 9:44 AM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> On Wed, Nov 04, 2015 at 01:11:45AM -0500, Ganesh Ajjanagadde wrote:
>> This speeds up build_filter by ~ 50%. This gain should be pretty
>> consistent across all architectures and platforms.
>>
>> Essentially, this relies on a observation that the filters have some
>> even/odd symmetry that may be exploited during the construction of the
>> polyphase filter bank. In particular, phases (scaled to [0, 1]) in [0.5, 1] are
>> easily derived from [0, 0.5] and expensive reevaluation of function
>> points are unnecessary. This requires some rather annoying even/odd
>> bookkeeping as can be seen from the patch.
>>
>> I vaguely recall from signal processing theory more general symmetries allowing even greater
>> optimization of the construction. At a high level, "even functions"
>> correspond to 2, and one can imagine variations. Nevertheless, for the sake
>> of some generality and because of existing filters, this is all that is
>> being exploited.
>>
>> Currently, this patch relies on phase_count being even or (trivially) 1,
>> though this is not an inherent limitation to the approach. This
>> assumption is safe as phase_count is 1 << phase_bits, and is hence a
>> power of two. There is no way for user API to set it to a nontrivial odd
>> number. This assumption has been placed as an assert in the code.
>>
>> To repeat, this assumes even symmetry of the filters, which is the most common
>> way to get generalized linear phase anyway and is true of all currently
>> supported filters.
>>
>> As a side note, accuracy should be identical or perhaps slightly better
>> due to this "forcing" filter symmetries leading to a better phase
>> characteristic. As before, I can't test this claim easily, though it may
>> be of interest.
>>
>> Patch tested with FATE.
>>
>> Sample benchmark (x86-64, Haswell, GNU/Linux):
>>
>> test: swr-resample-dblp-44100-2626
>>
>> new:
>> 527376779 decicycles in build_filter(loop 1000),     256 runs,      0 skips
>> 524361765 decicycles in build_filter(loop 1000),     512 runs,      0 skips
>> 516552574 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
>>
>> old:
>> 974178658 decicycles in build_filter(loop 1000),     256 runs,      0 skips
>> 972794408 decicycles in build_filter(loop 1000),     512 runs,      0 skips
>> 954350046 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
>>
>> Note that lower level optimizations are entirely possible, I focussed on
>> getting the high level semantics correct. In any case, this should
>> provide a good foundation.
>>
>> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde at gmail.com>
>> ---
>>  libswresample/resample.c | 56 +++++++++++++++++++++++++++++++++++++++++-------
>>  1 file changed, 48 insertions(+), 8 deletions(-)
>>
>> diff --git a/libswresample/resample.c b/libswresample/resample.c
>> index 235c9a9..d5fc5e7 100644
>> --- a/libswresample/resample.c
>> +++ b/libswresample/resample.c
>> @@ -144,7 +144,7 @@ static int build_filter(ResampleContext *c, void *filter, double factor, int tap
>>                          int filter_type, int kaiser_beta){
>>      int ph, i;
>>      double x, y, w;
>> -    double *tab = av_malloc_array(tap_count,  sizeof(*tab));
>> +    double *tab = av_malloc_array(tap_count+1,  sizeof(*tab));
>>      const int center= (tap_count-1)/2;
>>
>>      if (!tab)
>> @@ -154,9 +154,10 @@ static int build_filter(ResampleContext *c, void *filter, double factor, int tap
>>      if (factor > 1.0)
>>          factor = 1.0;
>>
>> -    for(ph=0;ph<phase_count;ph++) {
>> +    av_assert0(phase_count == 1 || phase_count % 2 == 0);
>> +    for(ph = 0; ph <= phase_count / 2; ph++) {
>>          double norm = 0;
>> -        for(i=0;i<tap_count;i++) {
>> +        for(i=0;i<=tap_count;i++) {
>>              x = M_PI * ((double)(i - center) - (double)ph / phase_count) * factor;
>>              if (x == 0) y = 1.0;
>>              else        y = sin(x) / x;
>> @@ -180,26 +181,65 @@ static int build_filter(ResampleContext *c, void *filter, double factor, int tap
>>              }
>>
>>              tab[i] = y;
>> -            norm += y;
>> +            if (i < tap_count)
>> +                norm += y;
>>          }
>>
>>          /* normalize so that an uniform color remains the same */
>>          switch(c->format){
>>          case AV_SAMPLE_FMT_S16P:
>> -            for(i=0;i<tap_count;i++)
>> +            for(i=0;i<tap_count;i++) {
>>                  ((int16_t*)filter)[ph * alloc + i] = av_clip(lrintf(tab[i] * scale / norm), INT16_MIN, INT16_MAX);
>> +            }
>> +            if (tap_count % 2 == 0) {
>> +                for (i = 0; i < tap_count; i++)
>> +                    ((int16_t*)filter)[(phase_count-ph) * alloc + tap_count-1-i] = ((int16_t*)filter)[ph * alloc + i];
>> +            }
>> +            else {
>> +                for (i = 1; i <= tap_count; i++)
>> +                    ((int16_t*)filter)[(phase_count-ph) * alloc + tap_count-i] =
>> +                        av_clip(lrintf(tab[i] * scale / (norm - tab[0] + tab[tap_count])), INT16_MIN, INT16_MAX);
>> +            }
>>              break;
>>          case AV_SAMPLE_FMT_S32P:
>
>> -            for(i=0;i<tap_count;i++)
>> +            for(i=0;i<tap_count;i++) {
>>                  ((int32_t*)filter)[ph * alloc + i] = av_clipl_int32(llrint(tab[i] * scale / norm));
>> +            }
>
> this and similar changes look uneeded
>
> otherwise LGTM

Artifacts left over from testing, sorry. Will push later to make sure
there are no further comments on this. I am particularly interested in
comments from API users: does this speed matter to them? Clement
seemed to care about it, but it seems to me quite rare to call this
multiple times on a stream.

>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Freedom in capitalist society always remains about the same as it was in
> ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


More information about the ffmpeg-devel mailing list