Skip to content
Snippets Groups Projects
Select Git revision
  • master default
  • n3.5-dev-tethys
  • n4.0.2-tethys
  • n3.2.12
  • n3.4.4
  • n4.0.2
  • n3.3.8
  • n2.8.15
  • n3.2.11
  • n3.4.3
  • n4.0.1
  • n4.1-dev
  • n4.0
  • n3.3.7
  • n3.0.11
  • n2.8.14
  • n3.4.2
  • n3.2.10
  • n3.3.6
  • n2.4.14
  • n3.4.1
  • n3.0.10
  • n3.2.9
23 results
Search by author
  • Any Author
  • Auri Auri aurieh
1 author
  1. Nov 06, 2015
    • Ganesh Ajjanagadde's avatar
      swresample/resample: speed up build_filter for Blackman-Nuttall filter · c8780822
      Ganesh Ajjanagadde authored 
      
This uses the trigonometric double and triple angle formulae to avoid
repeated (expensive) evaluation of libc's cos().

Sample benchmark (x86-64, Haswell, GNU/Linux)
test: fate-swr-resample-dblp-44100-2626
old:
1104466600 decicycles in build_filter(loop 1000),     256 runs,      0 skips
1096765286 decicycles in build_filter(loop 1000),     512 runs,      0 skips
1070479590 decicycles in build_filter(loop 1000),    1024 runs,      0 skips

new:
588861423 decicycles in build_filter(loop 1000),     256 runs,      0 skips
591262754 decicycles in build_filter(loop 1000),     512 runs,      0 skips
577355145 decicycles in build_filter(loop 1000),    1024 runs,      0 skips

This results in small differences with the old expression:
difference (worst case on [0, 2*M_PI]), argmax 0.008:
max diff (relative): 0.000000000000157289807188
blackman_old(0.008): 0.000363951585488813192382
blackman_new(0.008): 0.000363951585488755946507

These are judged to be insignificant for the performance gain. PSNR to
reference file is unchanged up to second decimal point for instance.

Reviewed-by: default avatarMichael Niedermayer <michael@niedermayer.cc>
Signed-off-by: default avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      c8780822
  3. Nov 04, 2015
    • Ganesh Ajjanagadde's avatar
      swresample/resample: speed up build_filter by 50% · 9bec6d71
      Ganesh Ajjanagadde authored 
      
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.

Reviewed-by: default avatarMichael Niedermayer <michael@niedermayer.cc>
Signed-off-by: default avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      9bec6d71
  5. Oct 28, 2015
  7. Oct 25, 2015
  9. Oct 22, 2015
    • Ganesh Ajjanagadde's avatar
      avfilter,swresample,swscale: use fabs, fabsf instead of FFABS · 8507b98c
      Ganesh Ajjanagadde authored 
      It is well known that fabs and fabsf are at least as fast and sometimes
faster than the FFABS macro, at least on the gcc+glibc combination.
For instance, see the reference:
http://patchwork.sourceware.org/patch/6735/

.
This was a patch to glibc in order to remove their usages of a macro.

The reason essentially boils down to fabs using the __builtin_fabs of
the compiler, while FFABS needs to infer to not use a branch and to
simply change the sign bit. Usually the inference works, but sometimes
it does not. This may be easily checked by looking at the asm.

This also has the added benefit of reducing macro usage, which has
problems with side-effects.

Note that avcodec is not handled here, as it is huge and
most things there are integer arithmetic anyway.

Tested with FATE.

Reviewed-by: default avatarClément Bœsch <u@pkh.me>
Signed-off-by: default avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      8507b98c
  11. Oct 16, 2015
  13. Oct 15, 2015
  15. Oct 10, 2015
  17. Oct 07, 2015
  19. Oct 02, 2015
  21. Sep 27, 2015
  23. Sep 03, 2015
  25. Aug 30, 2015
  27. Aug 23, 2015
  29. Aug 03, 2015
  31. Jul 26, 2015
  33. Jul 16, 2015
  35. Jun 22, 2015
  37. Jun 21, 2015
  39. Jun 08, 2015
  41. Jun 06, 2015
  43. Jun 04, 2015
  45. Jun 03, 2015
  47. Jun 02, 2015
  49. May 31, 2015
  51. May 13, 2015
  53. May 06, 2015
  55. Apr 12, 2015
  57. Apr 05, 2015
  59. Mar 30, 2015