[FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

[Carl Eugen Hoyos]

2019-01-29 10:10 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
> On 1/29/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>> 2019-01-28 19:40 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>> On 1/28/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>> 2019-01-28 16:17 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>> On 1/28/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>>>> 2019-01-28 15:20 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>>>> On 1/28/19, Carl Eugen Hoyos <ceffmpeg at 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?

Carl Eugen