optimize and trak.udta.name about mp4v2

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I believe r13 exposes this issue:
- the atom 'name' is FullAtom when direct child of udta
- the atom 'name' is Atom when direct child of ilst

So we need context-aware NameAtom as some code already attempts to implement 
but it is not activated. eddy 
seemed to be working on this stuff; maybe he can shed some light on the 
situation.

Original comment by [email protected] on 23 Dec 2008 at 8:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm incorrect about mp4creator 1.5.0.1 not having the same error at this point 
-- I'm not sure why, but at one 
point it seemed like it didn't. 

mp4creator --optimize or mp4file --optimize on a file containing any audio 
track names will wipe out 
trak.udta.name, but will not cause crashes in MP4 utilities (atomicparsley, 
mp4creator, mp4tags, metaX, 
muxo).

mp4creator --optimize or mp4file --optimize on a file containing any audio 
track names and/or any "reverse 
DNS" style atoms (http://atomicparsley.sourceforge.net/mpeg-4files.html) which 
consist of parental rating 
(i.e. G/PG/PG-13/R) in com.apple.iTunes;iTunEXTC and 
actors/producers/directors/writers in 
com.apple.iTunes;iTunMOVI will crash the MP4 utilities mentioned above and wipe 
out trak.udta.name.

This explains why crashes were occuring only sometimes, it only happens if 
optimization is done on a file 
with the reverse DNS style atoms.

I have 7 sample files (1 clean file prefixed by 0 with an audio track name, 2 
files prefixed by 1 each run 
through mp4file or mp4creator optimization, and 4 files prefixed by 2 each run 
through optimization and one 
set of the reverse DNS tags) available at public.me.com/jpo/. Each file is only 
1.8 MB

Original comment by [email protected] on 23 Dec 2008 at 10:05

[GoogleCodeExporter]

Some more digging for '----' atoms:
        ExpectChildAtom("mean", Required, OnlyOne);
        ExpectChildAtom("name", Required, OnlyOne);
        ExpectChildAtom("data", Required, OnlyOne);

but this seems to be in slight conflict with the spec. 'name' should be 
Optional/OnlyOne and 'data' should be 
Required/Many. not sure if this is a contributor to the issue as I have no mp4 
files with these atoms.

Original comment by [email protected] on 23 Dec 2008 at 4:18

[GoogleCodeExporter]

Another bit of information as related to 'reverse DNS' style atoms and the iTMF 
spec:
The '----' is a Atom containing:
    a) MeaningAtom  which is a FullAtom
    b) NameAtom which is a FullAtom
    c) DataAtom which is a Atom

and the code is not consistent (b) and (c). Frankly I'm just blown away by 
this; is it really possible that we are 
writing out FullAtom structure for  iTMF data atoms when they should really 
only be Atom ? Need another set 
of eyes on this to verify.

Original comment by [email protected] on 23 Dec 2008 at 4:46

[GoogleCodeExporter]

Verified. DataAtom is *not* a FullAtom. libmp4v2 has this wrong, and so does 
AtomicParseley. The only 
reason it works is because the FullAtom (a versioned atom) uses 4 bytes for 
version/flags which just so 
happens to be exactly the same size as type_indicator field for DataAtom; and a 
zero value means implicit. 
How lucky. In any case, the way we use it is wrong; and it's extremely poor 
form.

However, the problem with NameAtom is more pronounced, there is no lucky field 
overlap. The bytes used in 
NameAtom (ie: string), end up taking the place of what is supposed to be 
version/flags. For comparison 
purposes, AtomicParsley defines NameAtom as a VERSIONED_ATOM in their 
terminology, which is a FullAtom.

If I had to guess, the effect of this would be; if libmp4v2 is used to create a 
NameAtom (eg. from HB), and 
then the m4v file is inspected from QuickTime player, it might very well be 
missing the first 4 bytes 
(characters). If the value is 4 chars or less, then maybe this is when the 
issue becomes more evident.

Original comment by [email protected] on 23 Dec 2008 at 5:22

[GoogleCodeExporter]

marking as fixed; relevant changesets: r191,r194 .

Original comment by [email protected] on 10 Jan 2009 at 9:09

• Changed state: Fixed