[FFmpeg-devel] [PATCH] lavfi/atempo: raise max tempo limit

[Pavel Koshevoy]

On Tue, Jun 5, 2018 at 8:59 PM, Pavel Koshevoy <pkoshevoy at gmail.com> wrote:
> ---
>  libavfilter/af_atempo.c | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> index 8b214bccd7..daf4693321 100644
> --- a/libavfilter/af_atempo.c
> +++ b/libavfilter/af_atempo.c
> @@ -153,7 +153,7 @@ typedef struct ATempoContext {
>
>  static const AVOption atempo_options[] = {
>      { "tempo", "set tempo scale factor",
> -      OFFSET(tempo), AV_OPT_TYPE_DOUBLE, { .dbl = 1.0 }, 0.5, 2.0,
> +      OFFSET(tempo), AV_OPT_TYPE_DOUBLE, { .dbl = 1.0 }, 0.5, 100.0,
>        AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_FILTERING_PARAM },
>      { NULL }
>  };
> @@ -439,9 +439,6 @@ static int yae_load_data(ATempoContext *atempo,
>          return 0;
>      }
>
> -    // samples are not expected to be skipped:
> -    av_assert0(read_size <= atempo->ring);
> -
>      while (atempo->position[0] < stop_here && src < src_end) {
>          int src_samples = (src_end - src) / atempo->stride;
>
> --
> 2.16.3
>


I've tested with atempo=3, 4, 5, 6, 7, 30, 100...  It sounds reasonable.
I've compared atempo=3 vs 'atempo=sqrt(3.0),atempo=sqrt(3.0)' and did
not hear any difference.

I've removed the assertion because at tempo >= 7 the assertion fails,
but I'm not concerned about it -- some samples will simply be dropped
rather than being blended in.  At that high tempo I don't think
including all samples in output is a foremost consideration.  If
someone is concerned about samples being dropped from output stream
they can still fall back to the technique of daisy-chaining several
atempo instances at lower tempo setting.

If the patch looks good to someone with commit rights -- please apply.

Thank you,
  Pavel.