On Tue, Jun 5, 2018 at 8:59 PM, Pavel Koshevoy <pkoshe...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
