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

Baptiste Coudurier baptiste.coudurier
Thu Jun 12 21:37:18 CEST 2008


Michael Niedermayer wrote:
> On Thu, Jun 12, 2008 at 11:35:18AM -0700, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> On Thu, Jun 12, 2008 at 10:13:49AM -0700, Baptiste Coudurier wrote:
>>>> Hi Michael,
>>>>
>>>> Michael Niedermayer wrote:
>>> [...]
>>>>> Additionally 3gpp says: ----------------------- The file-type brands
>>>>> defined in this specification are used to label 3GP files belonging
>>>>> to Release 6 and conforming to one or more profiles. 3GP files may
>>>>> also conform to earlier Releases or even to other file formats, such
>>>>> as MP4, which is also derived from the ISO base media file format
>>>>> [7]. Table 5.1 contains a non-exhaustive list of examples with 3GP
>>>>> files for various purposes. All 3GP files of Release 5 
>>>> AFAIK We are using Release 4 !
>>> release 4 is from 2000/2001
>>>
>>> I really think we should try to be conformant to a recent version of it!
>>> Especially if one considers that the mp4 and iso base formats arent
>>> that old themselfs.
>>>
>>> Iam a little puzzled why you refuse to accept the more recent versions.
>>> Versions that clarify that iso base compatibility and thus a valid
>>> channel count is mandatory.
>> What about old devices ? 
> 
> No device reads and depends on a reserved field that contains no
> information.

Im pretty sure that devices (specially phones), check brands and
compatible brands, first 3GP release is very old, and files we create
are still compliant.

>> Should we drop old features like psp atoms
>> because new firmwares work without it ? No.
> 
> no of course not

Thank you.

>>> Besides id like to repeat that you ignored my objections to the change
>>> of the channel count to a fixed 2.
>>>
>>> So I request that this change is reverted, unless you can show that it
>>> has to be 2 for some demuxer hardware of software.
>> All software I know put 2 here (including gpac which is a very strong
>> reference).
> 
> I do not care at all if all software violates the specs.
> 
> 
>> MPEG-4 says template field has to be used:
>> "In MPEG-4 both visual and aural composition are done using the BIFS
>> system.  Therefore structures marked as ?template? in the ISO Base Media
>> Format which pertain to composition, including fields such as matrices,
>> layers, graphics modes (and their opcolors), volumes, and balance
>> values, from the MovieHeaderBox and TrackHeaderBox, are all set to their
>>                                                     ^^^^^^^^^^^^^^^^^^^^
>> default values in the file format.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> These fields do not define visual or audio composition in MPEG-4; in
>> MPEG-4, the BIFS system defines the composition."
>>
>> Are you stubborn or ?
> 
> No but you quote mpeg4 systems, neither 3gp nor the iso base claim to be
> compatible with mpeg4 systems.
> We arent storing BIFS last time i checked and most important 
> "Therefore structures marked as ?template? in the ISO Base Media
>  Format which pertain to composition, including fields such as matrices,
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  layers, graphics modes (and their opcolors), volumes, and balance
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  values, from the MovieHeaderBox and TrackHeaderBox,"
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> does NOT cover channel count in any way no matter what part of this
> sentance you consider. channel count is not in MovieHeaderBox nor
> TrackHeaderBox nor does it pertain to composition.
> 

Well, then why quoting VisualSampleEntry width and height just under
this paragraph (I forgot to quote) ?

Furthermore, they DO NOT override anything except:
width and height in semantics.

Besides, I have finally found it:

"  7. Template fields used

In the section ?Data Types and Fields? of the ISO Base Media File
Format, the concept of ?template? fields is defined.  This specification
derives from the base, and it is required that any derived specification
state explicitly which template fields are used.  This format uses no
template fields.

When a file is created as a pure MPEG-4 file, those fields shall be set
to their default values.  If a file is multi-purpose and also complies
with other specifications, then those fields may have non-default values
as required by those other specifications.

When a file is read as an MPEG-4 file, the values in the template fields
shall be ignored."

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.

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.

> all 3gp specs ive seen mark the field as reserved not fixed=2. reserved is
> not the same as fixed. A demuxer depending on the value of a reserved field
> is broken.

This is false.

The official 3gp spec is TS 26.244, and this document call this field
Reserved_2, and set its value to 2 (check the value for All SampleEntry
structures), since a long time (I checked your version which defines
Release 5).

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




More information about the ffmpeg-devel mailing list