[FFmpeg-devel] [FFmpeg-cvslog] lavf/cafenc: Allow muxing opus.

James Almer jamrial at gmail.com
Wed Oct 18 05:07:57 EEST 2017


On 10/17/2017 10:10 PM, Carl Eugen Hoyos wrote:
> 2017-10-17 23:48 GMT+02:00 James Almer <jamrial at gmail.com>:
>> On 10/17/2017 6:20 PM, Carl Eugen Hoyos wrote:
>>> 2017-10-17 22:20 GMT+02:00 James Almer <jamrial at 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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 



More information about the ffmpeg-devel mailing list