[FFmpeg-devel] [PATCH] mp4 and ipod metadata

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Thu, Jun 12, 2008 at 12:37:18PM -0700, Baptiste Coudurier wrote:
> [...]
> 
> "If the field is used in another specification, that use must be 
> conformant with its definition here" This means that if a spec is 
> using channel count it has to be the channel count. 3GP does not use 
> it in this sense thus its the default value unless another spec 
> requires it to be the channel count. aka reserved and value=2 (that 
> is set aside for another spec and if none does then set it to 2)
> 
> 
> "If the field is not used it must be copied un-inspected when boxes 
> are copied, and ignored on reading." This requires any compliant 3gp 
> demuxer to ignore channel count

So you would take the risk to break demuxing, just because you want to
simplify code ? I really don't think it is a good idea.

>> So yes, we may set ChannelCount to either 1 or 2 for MPEG-4, in the
>>  sense that we are not creating "pure" MPEG-4, but I object to set 
>> it to 6 until ISO clarify, and I really do not understand why they 
>> do not clarify.
> 
> I do understand why they do not clarify. There is nothing to clarify.
>  There is a field which can contain either 2 (the default value) or 
> the channel count.

You don't seem to be reading correctly:
"ChannelCount is either 1 (mono) or 2 (stereo)"

> Which it is depends on the brands one claims compatibility with. If 
> no spec explicitly says it uses the channel count then its value has
>  to be copied from the input unchanged by the muxer or set to the 
> default value of 2. If one or more specs say that they use the 
> channel count field then it has to be set to the true channel count.

AFAIK, no ISO specs defines channelcount.

>> Since the beginning, I really see not point forcing the specs while
>>  nothing is clear and stated, and everything else has MORE chance 
>> to break, really this is puzzling.
>> 
>>>> 3gp specs mandates value 2 for this field, like I proved many 
>>>> many times.
>>> 3gp release 5 and later mandate iso media compatiblity that 
>>> mandates this value to be 1 for mono streams beyond doubt.
>> Again we are using release 4, and there is no valid reason to use 
>> 5.
> 
> There is no reason to have a dozen variants of the mp4 format 
> generated by our muxer. 

There are reasons, to be able to produce files playable by different
hardware/player, without breaking other formats.

> We could generate one which is compliant to 
> all specs except the psp one. It would be nicer for our users and 
> would give ffmpeg an advantage over other more limited muxers.

You can create a -f isom I think and try to be conformant to all
standards, to create files that actually plays on different
devices/players, like quicktime AND phones.

This would be cool if it works.

Which mime type will you use ? Which extension ?
Besides:
"The type `isom' (ISO Base Media file) is defined in this section of
this specification, as identifying files that conform to the first
version of ISO Base Media File Format. More specific identifiers can be
used to identify precise versions of specifications providing more
detail. This brand should not be used as the major brand; this base file
format should be derived into another"

So we should not use it as major brand for mp4.

> [...]
> 
>> The official 3gp spec is TS 26.244, and this document call this 
>> field Reserved_2,
> 
> reserved_2 is 2 bytes reserved

Yes, like reserved_4 is 32 bits.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA