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

[Carl Eugen Hoyos]

2019-01-29 22:36 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
> On 1/29/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>> 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?
>>
>
> 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