On Fri, 30 Mar 2018 04:06:03 +0300 Timo Teras <timo.te...@iki.fi> wrote:
> On Fri, 30 Mar 2018 02:39:13 +0200 > Michael Niedermayer <mich...@niedermayer.cc> wrote: > > > git log points to > > bed4fc54c947b9e36d2103b400d438bfb4dd80dd > > > > This commit added both cpy and cprt, that makes your hypothesis not > > fit very well > > That commit adds it to three places: > - MOV mode which is basically in mov_write_udta_tag() using '\251cpy' > which published in Apple docs > - 3GP mode using 'cprt' which is in ISO standard > - mov_write_ilst_tag() is iTunes which is non-documented > > The commit adds exactly one tag to each variant. To me my hyptothesis > still looks correct. I was thinking and researching this more. It looks like: - 3GP defines 'cprt' which is completely different encoding and appears under different atom - \251cpy is the QuickTime atom documented by Apple - but it seems iTunes uses and has always used undocumented 'cprt' which similar to other iTunes atoms It seems that other software supporting iTunes support 'cprt' format. There are few other things that support also '\251cpy' variant in this context, but they are few. Now I suspect ffmpeg started writing '\251cpy' atoms also for the iTunes tag based on the assumption that the tag there would follow QuickTime format as many other iTunes tags follow. And this almost sounds like any other software supporting '\251cpy' here do it to support ffmpeg encoded incorrect streams. My preference on fixing this is as follows: 1. Just change '\251cpy' to 'cprt' as this seems to be the canonical atom 2. My previously suggested patch. Write 'cprt' by default, but have flag to write the other tag 3. Write both by default, but add flag to suppress the '\251cpy' atom Suggestions and additional input welcome. Timo _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
