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

[Michael Niedermayer]

On Thu, Jun 12, 2008 at 08:17:02PM -0700, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > On Thu, Jun 12, 2008 at 04:56:33PM -0700, Baptiste Coudurier wrote:
> >> Michael Niedermayer wrote:
[...]
> > 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.

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

But you are doing that. The specs state many times that they are compatible
you claim that channel count would have to be set to different incompatible
values in 3gp and mj2 or what it was.


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

it is not


> Since when QT is compatible with isom ?

I dont know if it is, maybe it is not.


> I never saw any file with "qt  " as major brand have "isom" as
> compatible brand.

I didnt either but that doesnt mean that it wouldnt work, i would have
to read and compare the specs side by side ...


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

what 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

And i didnt ask you to change it, are we just fighting each other over
nothing? Or is there some actual disagreement left?


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

good, what about adding 3gp* to our mp4s? (i of course would remove them
again if they cause problems for some players)

Besides, its offtopic but we need to fix our muxer to add these "tracks"
one day a well. I wonder how hard it is to generate some empty dummy tracks
to conform to the spec ...


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

I have a ipod, a psp and a phone as well, and they do play .mp4 i did
never try 3gp IIRC.


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

I wont test against QT, that iam pretty sure.


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

We have users who can do all the testing ...

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- 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/ac935489/attachment.pgp>