2019-01-22 13:47 GMT+01:00, Paul B Mahol <one...@gmail.com>: > On 1/22/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >> 2019-01-22 12:21 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>> On 1/22/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>> 2019-01-22 12:04 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>> On 1/22/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>> 2019-01-22 11:56 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>>>> 2019-01-22 11:38 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>>>>>> 2019-01-22 11:28 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>>>>>>>> On 1/22/19, Paul B Mahol <one...@gmail.com> wrote: >>>>>>>>>>>> On 1/22/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>>>>>>>>> 2019-01-15 13:17 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>>>>>>>>>>> 2019-01-15 12:53 GMT+01:00, Paul B Mahol <one...@gmail.com>: >>>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>>>>>>>>>>>>>>>> 2019-01-15 10:23 GMT+01:00, Paul B Mahol >>>>>>>>>>>>>>>>> <one...@gmail.com>: >>>>>>>>>>>>>>>>>> On 1/15/19, Carl Eugen Hoyos <ceffm...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
