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

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Thu, Jun 12, 2008 at 04:56:33PM -0700, Baptiste Coudurier wrote:
>> 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.
> 
> Please dont troll. Thank you
> 
> This is not about simplifying code it is about our mp4 muxer generating
> mp4 3gp 3g2 ipod god knows what files where each is incompatible with the
> other.

Created files work for what they are meant, people wanting .mp4 can play
them in flash/quicktime/whatever. People wanting .3gp can play them in
phones, the extension mechanism works well for now.

> While it would be perfectly fine to create files which are compliant to
> all these specs at the same time.

Sorry but it seems you're the only one wanting that.

>>>> 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)"
> 
> I cannot help you if you do not want to understand the spec.

Me neither, if you want to hack specs and make them stating what they do
not.

>>> 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.
> 
> I also cannot help you if each of your claims contradicts the previous.
> Didnt you just claim it is 1 (mono) or 2 (stereo) ?
> 
> Besides that,
> "channel count" by itself is quite clear already.
> and theres the QT spec which defines it at least

Since when qt is an ISO format ? Since when QT is compatible with isom ?
I never saw any file with "qt  " as major brand have "isom" as
compatible brand.

> And above all even if no spec defined it, that would not affect that
> its default value of 2 would be valid for all specs then (as none
> defined it otherwise).
> Its kinda simple either one defines it or none defines it. Either way
> there the incompatibility you claimed does not exist.
> Whats even more ridiculous is that you insist to only support a ancient
> revission of the 3gp spec because the later REQUIRE all 3gp files to
> claim to be iso media compatible. And you seem to prefer if they are
> not compatible.

This is false. 3gp4 can be supported by all later releases, being
ancient or not. What I don't not want to is to change major brand, you
can add more compatible brands if you want like "isom", but not "mp41"
nor "mp42", since those files wouldn't be, we miss crappy tracks.

>>>> 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.
> 
> If there are players not following the standards then special formats
> like -f psp can be added for them. It does not mean that we should
> only support such castrated output formats (like movenc currently does)
> Because these definitly do not work on 2/3 of the spec compliant devices.

These castrated formats works.

Which devices are you talking about ? Your claims are not based on
anything serious, only specs, while I worked with many devices (my
phone, quicktime, ipod), and I worked on the code since many years to
make it working, before I did work it was creating broken and non
playable files.

You are the only one thinking that unfortunately, all people are quite
happy with the muxers.

> They cannot, simply because a .mp4 wont work on a 3gp device and a .3gp
> wont work on a .mp4 device. You explicitly claim in the compatible brands
> in ftyp that the other one isnt supported.

Please tell me how do you put amr in .mp4 ? Playable by Quicktime.
Will you test your code against Quicktime ? Phones ?

> What i suggested would create files that would work on all spec compliant
> devices 3gp as well as mp4. With a single file.

This would be cool, Im not sure if this is possible, and how much
testing it needs.

[...]

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