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

Baptiste Coudurier baptiste.coudurier
Thu Jun 12 00:29:42 CEST 2008


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.

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

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

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.

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




More information about the ffmpeg-devel mailing list