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

[Baptiste Coudurier]

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.

> Besides, quoting ISO/IEC 14496-12:2005(E)
> ---------------
> A media-file structured to this part of this specification may be compatible with more than one detailed
>                                                                                   ^^^^^^^^^^^^^ 
> specification, and it is therefore not always possible to speak of a single type or brand for the file. This
> means that the utility of the file name extension and mime type are somewhat reduced.
> 
> This box must be placed as early as possible in the file (e.g. after any obligatory signature, but before any
> significant variable-size boxes such as a Movie Box, Media Data Box, or Free Space). It identifies which
> specification is the best use of the file, and a minor version of that specification; and also a set of other
>                                                                                       ^^^^^^^^^^^^^^^^^^^^^^^
> specifications to which the file complies. Readers implementing this format should attempt to read files that
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> are marked as compatible with any of the specifications that the reader implements. Any incompatible change
> in a specification should therefore register a new brand identifier to identify files conformant to the new
> specification.
> ---------------
> 
> The ftyp we currently store does not correctly list the specifications to
> which it complies, it just stores one spec. Probably duplicating what the
> person implementing it saw in some hex editor from some similar file from
> somewhere ...

Well we are not conform to "mp41" nor "mp42" because we do not have iods
nor crappy useless tracks like odsm.

Well, atm the code write correct ones, it might not be as exhaustive as
it could be though.

> The correct way to do it IMHO is to first make a list of specs the current
> instance conforms to (based on streams -f and so on)
> and then store them ALL with the "best" as major brand
> That is what the spec says IMHO

Yes, I agree with that.

[...]

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