On 10/17/2017 10:10 PM, Carl Eugen Hoyos wrote: > 2017-10-17 23:48 GMT+02:00 James Almer <jamr...@gmail.com>: >> On 10/17/2017 6:20 PM, Carl Eugen Hoyos wrote: >>> 2017-10-17 22:20 GMT+02:00 James Almer <jamr...@gmail.com>: >>>>> ffmpeg | branch: master | Carl Eugen Hoyos <ceffmpeg at gmail.com >>>>> <http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog>> | Tue Oct 17 21:35:28 >>>>> 2017 +0200| [a3accd0c3768933f15422c9dec596da0f436d786] | committer: Carl >>>>> Eugen Hoyos >>>>> >>>>> lavf/cafenc: Allow muxing opus. >>>>> >>>>> QuickTime does not require the (unknown) kuki chunk for decoding. >>>> >>>> This at the very least requires limiting muxing to mono and stereo >>>> streams (The only kind of streams that work without channel mapping >>>> information in extradata), >>> >>> Done, thank you! >>> >>>> and a check for -strict experimental. >>> >>> Why? >> >> Because we're creating these files blindly > > This is not correct (and offending, no matter the issue > with the original patch).
I don't see how it can be offending. But in any case, would "without understanding all the encapsulation details" instead of blindly be less offensive? > >> without a proper RE attempt > > How do you know? You specifically called the contents of the kuki chunk "unknown" in the commit message. That pretty much implies there has been no concrete attempt to RE it. Not to mention you'd have added support for it otherwise. > >> or following any kind of encapsulation spec. And considering the >> official encoder/muxer adds a codec specific chunk we don't, the more >> reason to consider a muxing as barebones as this as something >> potentially non-compliant. > > Imo, this is not a helpful approach: > The "official" demuxer/decoder accept the files, how does > it make sense to argue they are potentially non-compliant? It happening to work or be accepted isn't the same as being spec compliant. Some specs can be very pedantic in the most silly of ways with small details and declare something that pretty much any implementation accepts as non-compliant. See things like MPEG/WebM DASH. In this case, the spec says "If the audio data format contained in a CAF file requires magic cookie data, the file must have this chunk", which is apparently followed by the official muxer application, but not by Quicktime since according to your tests it ignores its absence. > >>>> Also, I'd have rather waited for Apple to update their docs about Opus >>>> in CAF. >>> >>> As in: Until Godot arrives? >>> >>> Sorry, I don't think it makes much sense to wait for a >>> specification that to best of our knowledge may never >>> appear. >> >> Apple published the spec for CAF > >> detailing encapsulation details for the codecs it supports > > Depending on the definition of "detailing": > Yes. > (For most codecs, the encapsulation details had to be > guessed.) > >> including the contents of the kuki chunk for most of them. > > Could you elaborate? This is not how I remember it. The spec mentions that for AAC, the kuki chunk contains the same data as the esds atom in ISOBMFF. And then there's https://github.com/macosforge/alac/blob/master/ALACMagicCookieDescription.txt for ALAC. So at least the two most important ones. I want to believe the same will be done for Opus, if anything by Xiph (like they did with ISOBMFF). > > Carl Eugen > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
