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

Paul B Mahol onemda at gmail.com
Tue Jan 22 14:47:21 EET 2019


On 1/22/19, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 2019-01-22 12:21 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 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.
>
> But the CAF structure is the relevant talking point for caf files, no?
>
>>> Is my explanation sufficient for you now?
>>
>> You still claim 2 things in your patch which are lie.
>
> So you claim I am a liar? Does that mean we can
> finally drop the CoC?
>
> Please elaborate, Carl Eugen

You claim that:
1. There is junk data after end of data chunk as set in that file.
2. No useful data is being discarded.

Both are not true.


More information about the ffmpeg-devel mailing list