[FFmpeg-devel] [PATCH]lavf/cafdec: Do not fail hard for files ending with junk

[Paul B Mahol]

On 1/22/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 2019-01-22 12:04 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>> 2019-01-22 11:56 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>>>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>>>>> On 1/22/19, Paul B Mahol <onemda at gmail.com> wrote:
>>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>>>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>>>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>>>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda at gmail.com>:
>>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A user provided a real-life caf file ending with junk after
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> data
>>>>>>>>>>>>>>>> chunk, QuickTime reads such files.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please comment, Carl Eugen
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> NACK, there is data after junk bytes, which would get simply
>>>>>>>>>>>>>>> discarded with your patch.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please elaborate: I don't think any data gets discarded
>>>>>>>>>>>>>> because
>>>>>>>>>>>>>> of this patch.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I told you already, hex edit size of data chunk to very big
>>>>>>>>>>>>> number
>>>>>>>>>>>>> and
>>>>>>>>>>>>> play file again.
>>>>>>>>>>>>
>>>>>>>>>>>> Of course.
>>>>>>>>>>>>
>>>>>>>>>>>> But how does this change the output compared to my patch?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It does change, full length of audio is:
>>>>>>>>>>>
>>>>>>>>>>> MD5=5128bc2cd0e7b0560f15dd4c0546d1a0rate=   0.0kbits/s speed=
>>>>>>>>>>> 777x
>>>>>>>>>>> size=       0kB time=00:09:18.16 bitrate=   0.0kbits/s speed=
>>>>>>>>>>> 769x
>>>>>>>>>>
>>>>>>>>>> Sorry for the delay:
>>>>>>>>>> QuickTime Player only plays the file for ~6:20.
>>>>>>>>>> Playing the file longer would be an issue since atoms after the
>>>>>>>>>> data atom are allowed.
>>>>>>>>>> And most important: This is unrelated, my patch is about playing
>>>>>>>>>> a file that is supposed to be played but currently doesn't work.
>>>>>>>>>> If there is something else to be improved, it should be a separate
>>>>>>>>>> patch.
>>>>>>>>>>
>>>>>>>>>> Please comment, Carl Eugen
>>>>>>>>>
>>>>>>>>> You can not claim it fixes playback.
>>>>>>>
>>>>>>> It does here: The file does not play without my patch, it plays
>>>>>>> (for the right duration) with my patch.
>>>>>>
>>>>>> Duration is not right at all.
>>>>>
>>>>> Does QuickTime play the file longer for you than FFmpeg
>>>>> with my patch?
>>>>> Or do I misunderstand you?
>>>>
>>>> Correct duration is one I showed it here.
>>>
>>> No, the correct duration for the given file is ~6:20 as
>>> already explained.
>>
>> Nope, you are removing actual valid audio samples this way.
>
> But the caf structure claims that the discussed data are
> not valid audio samples but other caf atoms, since valid
> files exist that have atoms there, it is correct to skip the
> atoms if they cannot be detected, that is just how caf
> works.

I'm not talking about CAF structure.

> Is my explanation sufficient for you now?

You still claim 2 things in your patch which are lie.