On 1/29/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > 2019-01-29 10:10 GMT+01:00, Paul B Mahol <one...@gmail.com>: >> On 1/29/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>> 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. >> >> The patch is incomplete and thus incorrect. > > Do you mean it does not fix the duration of the NO_DATA frames? >
Duration is irrelevant. > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel