diff mbox

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

Message ID CAB0OVGo6ujgf7+y4YBRGw7Gs+BNcOnco0vVJogPR4Lfp2L5p7A@mail.gmail.com
State Rejected
Headers show

Commit Message

Carl Eugen Hoyos Jan. 14, 2019, 11:25 p.m. UTC 
Hi!

A user provided a real-life caf file ending with junk after the data
chunk, QuickTime reads such files.

Please comment, Carl Eugen

Comments

Paul B Mahol Jan. 15, 2019, 9:23 a.m. UTC | #1 
On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> Hi!
>
> 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.
Carl Eugen Hoyos Jan. 15, 2019, 11:45 a.m. UTC | #2 
2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.

Carl Eugen
Paul B Mahol Jan. 15, 2019, 11:53 a.m. UTC | #3 
On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.
Carl Eugen Hoyos Jan. 15, 2019, 11:55 a.m. UTC | #4 
2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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?

Carl Eugen
Paul B Mahol Jan. 15, 2019, 12:17 p.m. UTC | #5 
On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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
Carl Eugen Hoyos Jan. 22, 2019, 10:14 a.m. UTC | #6 
2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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
Paul B Mahol Jan. 22, 2019, 10:27 a.m. UTC | #7 
On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.
Paul B Mahol Jan. 22, 2019, 10:28 a.m. UTC | #8 
On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.

Also you can not claim there is junk. There is real sound there.
Carl Eugen Hoyos Jan. 22, 2019, 10:33 a.m. UTC | #9 
2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.

> Also you can not claim there is junk. There is real sound there.

So you want me to change the commit message, is that
correct?

Carl Eugen
Paul B Mahol Jan. 22, 2019, 10:38 a.m. UTC | #10 
On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.

>> Also you can not claim there is junk. There is real sound there.
>
> So you want me to change the commit message, is that
> correct?

I mentioned just one issue of many.
Carl Eugen Hoyos Jan. 22, 2019, 10:42 a.m. UTC | #11 
2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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?

>>> Also you can not claim there is junk. There is real sound there.
>>
>> So you want me to change the commit message, is that
>> correct?
>
> I mentioned just one issue of many.

That is unfortunately not helpful: Please explain what is
wrong with the patch.

Carl Eugen
Paul B Mahol Jan. 22, 2019, 10:56 a.m. UTC | #12 
On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.

>
>>>> Also you can not claim there is junk. There is real sound there.
>>>
>>> So you want me to change the commit message, is that
>>> correct?
>>
>> I mentioned just one issue of many.
>
> That is unfortunately not helpful: Please explain what is
> wrong with the patch.

I already said what is wrong in my previous mails, why should I repeat
myself all over again?
Carl Eugen Hoyos Jan. 22, 2019, 10:59 a.m. UTC | #13 
2019-01-22 11:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.

Carl Eugen
Paul B Mahol Jan. 22, 2019, 11:04 a.m. UTC | #14 
On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2019-01-22 11:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.
Carl Eugen Hoyos Jan. 22, 2019, 11:12 a.m. UTC | #15 
2019-01-22 12:04 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2019-01-22 11:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.
Is my explanation sufficient for you now?

Carl Eugen
Paul B Mahol Jan. 22, 2019, 11:21 a.m. UTC | #16 
On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2019-01-22 12:04 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2019-01-22 11:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.
Carl Eugen Hoyos Jan. 22, 2019, 11:24 a.m. UTC | #17 
2019-01-22 12:21 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2019-01-22 12:04 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2019-01-22 11:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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
Paul B Mahol Jan. 22, 2019, 12:47 p.m. UTC | #18 
On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
> 2019-01-22 12:21 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>> 2019-01-22 12:04 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>> 2019-01-22 11:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>>>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.
Carl Eugen Hoyos Jan. 23, 2019, 10:30 p.m. UTC | #19 
2019-01-22 13:47 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>> 2019-01-22 12:21 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>> 2019-01-22 12:04 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>> 2019-01-22 11:56 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>> On 1/22/19, Paul B Mahol <onemda@gmail.com> wrote:
>>>>>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <onemda@gmail.com>:
>>>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote:
>>>>>>>>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol
>>>>>>>>>>>>>>>>> <onemda@gmail.com>:
>>>>>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffmpeg@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.

New patch sent.

Carl Eugen
diff mbox

Patch

From 67d49072d60b95ffc8838a20cb87b33b5904dc21 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Date: Tue, 15 Jan 2019 00:22:50 +0100
Subject: [PATCH] lavf/cafdec: Do not fail hard if the file ends with junk.

QuickTime does not fail if the file contains random data after the data chunk.
---
 libavformat/cafdec.c |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
index 7652d9e..20956bc 100644
--- a/libavformat/cafdec.c
+++ b/libavformat/cafdec.c
@@ -310,6 +310,8 @@  static int read_header(AVFormatContext *s)
                    "skipping CAF chunk: %08"PRIX32" (%s), size %"PRId64"\n",
                    tag, av_fourcc2str(av_bswap32(tag)), size);
         case MKBETAG('f','r','e','e'):
+            if (size < 0 && found_data)
+                goto found_data;
             if (size < 0)
                 return AVERROR_INVALIDDATA;
             break;
@@ -325,6 +327,7 @@  static int read_header(AVFormatContext *s)
     if (!found_data)
         return AVERROR_INVALIDDATA;
 
+found_data:
     if (caf->bytes_per_packet > 0 && caf->frames_per_packet > 0) {
         if (caf->data_size > 0)
             st->nb_frames = (caf->data_size / caf->bytes_per_packet) * caf->frames_per_packet;
-- 
1.7.10.4