Message ID | CAB0OVGo6ujgf7+y4YBRGw7Gs+BNcOnco0vVJogPR4Lfp2L5p7A@mail.gmail.com |
---|---|
State | Rejected |
Headers | show |
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.
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
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.
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
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
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
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.
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.
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
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.
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
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?
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
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.
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
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.
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
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.
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
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