2019-01-29 22:36 GMT+01:00, Paul B Mahol <one...@gmail.com>: > 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.
Not sure I understand: This is about 4 seconds vs 16 seconds... Anyway, I will send a new patch that initializes the output frame, this improves the result. Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
