Paul B Mahol (12019-05-11): > It is currently separate filter for ease of testing.
Then no problem. But I insist: once it is in shape, for the convenience of the users and ease of maintenance, it should be a single filter. Of course, if you disagree, we can discuss it here. > It can not be "part" of current atempo implementation for numerous reasons, > most significant one being bad output quality with < 1 tempo scale > factor of current atempo implementation. This is one of the reasons it should be a single filter: the users should not need to know the arbitrary limits of different filters implementation. The filters are there to perform a task, and they should select the best implementation for it automatically. > Also current atempo implementation have limits for minimal scale > reduction, IIRC, the limits were rather arbitrary. But even if they are not, my point stand: the filter should select the best implementation for the requested parameters, automatically without bothering the users. > unlike rubberband filter in libavfilter. Also rubberband filter having > similar and bigger functionality. Oh, great, another filter with the same task. If I had noticed at the time, I would have insisted that it be part of atempo too at the time. > That's way I request for quality testers. > Best would be to compare this filter with rubberband and current atempo > filter. > > This filter is supposed to be current atempo full replacement. > (atempo would be just this filter but with same first two options but > with swapped positions). Swapping the position will break existing scripts. It should be avoided. > Options are self-explanatory, at least first two. > Documentation will appear later. Ok. -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".
