On 10/1/18, Marton Balint <c...@passwd.hu> wrote: > > > On Mon, 1 Oct 2018, Paul B Mahol wrote: > >> On 10/1/18, Marton Balint <c...@passwd.hu> wrote: >>> >>> >>> On Mon, 1 Oct 2018, Paul B Mahol wrote: >>> >>>> On 10/1/18, Marton Balint <c...@passwd.hu> wrote: >>>>> >>>>> >>>>> On Mon, 1 Oct 2018, Paul B Mahol wrote: >>>>> >>>>>> On 9/30/18, Marton Balint <c...@passwd.hu> wrote: >>>>>>> Signed-off-by: Marton Balint <c...@passwd.hu> >>>>>>> --- >>>>>>> libavfilter/af_afade.c | 4 ++-- >>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>>> >>>>>> >>>>>> Why? >>>>>> >>>>>> Value is too big. >>>>> >>>>> AV_OPT_TYPE_DURATION is microsecond precision, therefore 60 is 60 >>>>> usecs. >>>>> Probably you meant 60 seconds as limit. That is what the patch fixes. >>>> >>>> I do not think so. Duration is interpreted as seconds, look how >>>> variable is used in code. >>> >>> As far as I see duration is rescaled from AV_TIME_BASE (microseconds) to >>> sample_rate time base: >>> >>> if (s->duration) >>> s->nb_samples = av_rescale(s->duration, outlink->sample_rate, >>> AV_TIME_BASE); >>> >>> Duration is parsed as seconds (can be fractional as well), but internally >>> it is stored as microseconds (int64). Another example is the f_realtime >>> filter where the sleep time limit default according to the documentation >>> is 2 seconds and it is expressed as 2000000 in the code. >> >> Yes, and current patch is wrong. Simply exceding max value is not proper >> fix. > > What is the proper fix then?
Interpreting duration correctly, like trim filters do. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
