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

[Michael Niedermayer]

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.
While it would be perfectly fine to create files which are compliant to
all these specs at the same time.


> 
> >> 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.


> 
> > 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

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.


> 
> >> 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.
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.

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


> 
> > 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.

of course. Noone suggested that it would be major brand, it just
has to be listed in the compatible brands as is mandatory for 3gp rel5+
a least. But even for rel4 it should be there.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080613/cd2fbc5a/attachment.pgp>