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

Michael Niedermayer michaelni
Thu Jun 12 05:24:12 CEST 2008


On Wed, Jun 11, 2008 at 03:29:42PM -0700, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > On Wed, Jun 11, 2008 at 12:56:29PM -0700, Baptiste Coudurier wrote:
> >> Michael Niedermayer wrote:
> >>> On Wed, Jun 11, 2008 at 11:46:47AM -0700, Baptiste Coudurier
> >>> wrote:
> >>>> Michael Niedermayer wrote:
> >>>>> On Wed, Jun 11, 2008 at 02:55:47AM -0700, Baptiste Coudurier
> >>>>> wrote: [...]
> >>>>>>> That doesnt mean ipod tags should be in -f mp4 or -f mov
> >>>>>>> but that there is a -f foobar that contains all tags of
> >>>>>>> all variants. I prefer if i dont need to have each video
> >>>>>>> 3 times so it can be played on 3 different players.
> >>>>>> I understand the need, Im afraid it's complicated.
> >>>>>> 
> >>>>>> Unfortunately, it is so brainded to deal with all iso media
> >>>>>> variants and their fields having different meaning values
> >>>>>> that I tend to prefer constraining specific features to
> >>>>>> specific formats. I think that adding this ipod format was
> >>>>>> a good thing.
> >>>>> Could you point at a few examples were fields have different
> >>>>> meaning between mp4 types (not mp4 vs. mov)?
> >>>> mp4/3gp channels field in stsd for example, which is reserved
> >>>> to 2 while in mj2/mov it is actual channels number.
> >>> hmm, soo many specs to read and compare :(
> >> Yes, that was I was saying.
> > 
> >>> [...]
> >>> 
> >>> So we may have multiple stsd boxes and ones with unknown
> >>> "codingname" must be ignored.
> >> Im strongly against created files with 2 stsd.
> > 
> > fine, iam not really suggesting that anyway
> > 
> > 
> >>> --- class AudioSampleEntry(codingname) extends SampleEntry
> >>> (codingname){ const unsigned int(32)[2] reserved = 0; template
> >>> unsigned int(16) channelcount = 2;
> >> ^^^^^^^^
> >> 
> >>> [...]
> >>> 
> >>> ... 8.16.3 Semantics version is an integer that specifies the
> >>> version of this box entry_count is an integer that gives the
> >>> number of entries in the following table SampleEntry is the
> >>> appropriate sample entry. data_reference_index is an integer that
> >>> contains the index of the data reference to use to retrieve data
> >>> associated with samples that use this sample description. Data
> >>> references are stored in Data Reference Boxes. The index ranges
> >>> from 1 to the number of data references. ChannelCount is either 1
> >>> (mono) or 2 (stereo) 
> >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ --- So if i
> >>> understand the base format does not require ChannelCount to be 2 
> >>> but says=2 in the table
> >> What if channels are 6 ? This is unclear.
> > 
> > yes, somewhat, but my arguing would be
> > 
> > 6 != stereo -> not 2 6 != mono   -> not 1 the count of channels being
> > 6 -> ChannelCount= 6
> 
> I do not agree here, ChannelCount value is either 1 or 2, means that any
> other value is allowed IMHO.

you mean "disallowed" ?


> 
> > 
> >>> 3gp which is based on the iso base format says reserved_2 for the
> >>> field but does not say anything about channels. Thus it appears
> >>> it has been copy and pasted but the description has not.
> >>> 
> >>> Neither does specify what the word "reserved" means.
> >> IMHO "reserved" is fixed value.
> > 
> > I do not agree here. "reserved" means "set aside for the use of a
> > particular person or party" (first link in google for definition
> > reserved)
> > 
> > they could have written "fixed" or "constant" if they meant that. In
> > no specs ive read, reserved meant that one could assume it to be
> > always that value.
> 
> Well, from any ISO/SMPTE I could read "reserved" meant that the
> value had to be fixed to the value mentioned.

No, let me quote mpeg1 video.
----
reserved: The term "reserved" when used in the clauses defining the
coded bitstream indicates that the value may be used in the future
for ISO defined extensions.
----

If we simply assume ISO uses the same definition in mp4 (not unreasonable)
then a reserved field in the 3gp spec and the same field being the channel
count in mj2 do not contradict.
3GP does not specify what value the field should contain except that muxers
could use 2.
MJ2 specifies it should be the channel count

Just compare this to the wording of the base ISO format spec, the intent
is very clearly to have specs about the format to be compatible.


> 
> > [...]
> >> Anyway it is not necessary to relaunch this discussion about these 
> >> standards, we already had it many times and it always end badly.
> > 
> > yes, maybe we should do what i suggested mans, simply fork the code 
> > in svn and then each can implement their (de)muxer as they see fit.
> > 
> 
> Well, actually many people are requesting some patches I have, off-list
> to get timecode writing in .mov, to get imx support in .mov, to have
> features I use.

Why are these things not in svn?


> 
> This is always the same thing, features useful add values, but this is
> another debate and will lead to problems I fear, and I think there had
> been too many problems these recent days.

what problem can it cause if we set the channel count field to the number
of channels?

[...]
-- 
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/20080612/da6fb8bc/attachment.pgp>



More information about the ffmpeg-devel mailing list