2019-01-28 19:40 GMT+01:00, Paul B Mahol <one...@gmail.com>: > On 1/28/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >> 2019-01-28 16:17 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>> On 1/28/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>> 2019-01-28 15:20 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>> On 1/28/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>> Hi! >>>>>> >>>>>> Attached patch fixes the actual output duration for AMR-WB samples >>>>>> with NO_DATA frames. >>>>>> A follow-up patch also skips corrupted frames, making the output of >>>>>> the sample in ticket #7113 very similar to the reference decoder. >>>>> >>>>> Very similar does not mean much! >>>> >>>> Since some frames are broken (and not just corrupted) and the >>>> codec uses floats internally, I don't think this is relevant. >>>> >>>> In addition, this patch is not about similarity in the output but >>>> duration, so your comment does not apply here. >>>> >>>> Is this patch ok? >>> >>> Only if you can confirm that output is same as reference decoder >>> expect rounding. >> >> Sorry for the misunderstanding: >> This patch does not aim to make the output more similar to >> any other decoder, it only fixes the actual output duration >> when decoding. > > Than patch is incorrect.
I don't understand: We have a sample that decodes with too short duration with current FFmpeg, the patch fixes this: Why is the patch incorrect? I realize now that by fixing the "missing" parts in the output file, it of course does make the file (significantly) more similar to the reference output - but it does not change the parts of the output that were already there. Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel