[FFmpeg-devel] [PATCH] mp4 and ipod metadata
Baptiste Coudurier
baptiste.coudurier
Thu Jun 12 06:13:20 CEST 2008
Michael Niedermayer wrote:
> 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" ?
Yes, sorry.
>>>>> 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.
Like:
2.1.46 reserved: The term "reserved", when used in the clauses defining
the coded bit stream, indicates that the value
may be used in the future for ISO defined extensions. Unless otherwise
specified within ITU-T Rec. H.222.0 |
ISO/IEC 13818-1, all reserved bits shall be set to '1'.
^^^^^^^^^^^^
We always see those paraghaphs near fields definitions.
>
> 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.
No, check TS 26.244:
Table 6.4: AMRSampleEntry fields
Field Type Details Value
Reserved_2 Const unsigned int(16) 2
Reserved_2 Const unsigned int(16) 16
respective values for channels and bits per sample. These are clearly
specified values.
> MJ2 specifies it should be the channel count
My copy just says like 14496-12, aka ChannelCount is either 1 or 2.
> 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.
>
Yes, but derivatives fail miserably to be intercompatible, unfortunately.
>>> [...]
>>>> 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?
>
Because Im tired of having to fight to get some code into svn, because
mechanism is not clean at all sometimes, like the fucking stsd
height/width in .mov, for timecode track for which we already have this
kind of discussion.
>> 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?
We changed it because someone complained that 3gp files were not
compliant. I've did much work already to create compliant files, really
Im tired.
I remember having read in ISO specs that you may override some template
fields for interroperability purpose, so, yes, we _could_ maybe set
channels correctly in mp4, but definitely not in 3gp.
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
More information about the ffmpeg-devel
mailing list