An AAF source clip contains a data definition, a length and a source reference. The source reference leads typically to another mob. The source ref comprises 3 parts, namely; a SourceID (being the ID of the referenced mob), a SourceMobSlotID (for the referenced mob) and a StartTime (being an offset into the relevant slot).
Until today I always assumed that the StartTime must be a positive offset into the referenced slot. However, today I've been sent an AAF file which seems to have a negative offset into the referenced mob slot. To be specific, it has an offset of 0xffffff9c into a slot whose length is only 0x145 units.
Is this legal or should I flag it up to the originator?
I have a bit more information about the problem, this morning.
Since I first posted, I've found 3 more sourcelips (in the same AAF file) that are all showing a negative offset into the source mob slot that they reference. I asked my customer to import that AAF file into another Avid of the same type that it was exported from. The session imports correctly with no problems at the positions where I expected to see problems.
I know for certain that negative slot positions are illegal in OMFI-2 so I next asked my customer to export the same session (from the originating Avid) in OMFI-2 format. As expected, this one doesn't exhibit any negative offsets and my software will import the session correctly. So at the moment, I can't tell my customer whether:-
a) Negative slot positions are legal for AAF but I just didn't realise it, or;
b) They aren't legal but Avid has found a way to implement them (that its own s/ware can understand), or;
c) There's a problem with the Avid code that exported the session (given that it seems to export different timing information depending on the exported format), or;
d) There's a problem in my version of InfoDumper.
My customer would prefer to export in AAF format but they can't do this if the exported sessions will only import on some systems but not on others. The session format is native AAF (not XML) and I'm not sure whether XML format (even if it's available) would be any better.
I'm inclined to tell my customer to stick with OMF since that seems to be stable - but I'd prefer to have a more positive answer.
According the the AAF Object Spec, StartTime is of type PositionType which is an Int64 (as opposed to a UInt64), so legally you can have a negative value here. The spec defines it as an "offset from the origin of the referenced Mob MobSlot", but doesn't describe what a negative offset means in this context.
That said, I don't think your file has a negative StartTime. You quoted a value of 0xffffff9c, but being of type Int64 this number is a large position number (4294967196). Furthermore, I crafted a structured storage AAF file with a negative StartTime of -100 and when I InfoDumped the file, InfoDumper displayed "StartTime: -100". BTW, where did you see "0xffffff9c" - InfoDumper dumps StartTime as decimal not hex numbers (at least in the last couple of SDK releases).
Thanks for looking into this Stuart. Regardless of the output from InfoDumper I think that the intended offset is -100 because (at least that way) a sensible positive offset can be arrived at (eventually) by accumulation of it and any subsequent offsets into the media. If the intended offset was 4294976196 that would make the situation much worse because there's nowhere near enough media to accommodate such an offset.
Currently, my customer is trying to clarify the situation with Avid, whose Adrenaline product originated the AAF file. However, if the AAF Object Spec doesn't define what a negative offset is supposed to mean, maybe it needs to be defined (with some urgency, since at least one company already uses it). I was informed yesterday that a second file (from the same product) also seems to have a negative (or unrealistically large) start time offset.
FYI an aafLength_t is also of Int64 type, suggesting that a negative object length is also legal. I don't have a copy of the AAF Object Spec, so it might be worth your while to check whether a 'length' property is already described as being positive only.
It does seem more plausible that the SourceClip is pointing to a MobSlot 100 edit units before it starts. It would be nice to know how the application arrived at this reference though.
The AAF Oject Spec (and Edit Protocol) are part of the SDK. You can view them here: http://aaf.cvs.sourceforge.net/aaf/AAF/doc/
The LengthType type is an Int64 so can be negative.
My understanding of all of this is as follows:
- (StartTime (in the referencing SourceClip) + Origin (of the referenced TimelineMobSlot)) shall be >= 0
- Length shall be >= 0 (even though it's a signed int)
The Origin property on a TimelineMobSlot is there to accommodate adding or removing material from the front end of the referenced slot, changed after it is first created. It tells you the offset into the track of the point corresponding to "StartTime=0". If you redigitise an asset and bring in earlier material than you did first time round, then you should end up with an Origin > 0. SourceClips that reference the new material at the front of the redigitised asset will have StartTime < 0. The key thing is that StartTime + Origin >= 0 (otherwise a reference is made before the material begins).
Given this, do you believe the files you have are OK?
Because this all happened so close to Christmas I thought it best to leave things until after the break. However, according to your description, the mob offsets in these cases are incorrectly formed. The start times (from the referencing mobs) are negative but the origin (within the referenced mob) is zero. It has to be said that after accumulation (i.e. taking into account other mobs further down the chain) the offset eventually sorts itself out and becomes positive - but taking your description literally, the offsets are mal-formed.
The main problem this causes is when using the AAF->OMF conversion utility. Negative offsets are illegal for OMF, even if the cumulative offset is eventually non-negative.
What seems to have happened is that an audio clip was digitized having 19 seconds duration. From that, a smaller subclip was created having 13 seconds duration and starting 6 seconds into the original clip. From that (smaller) subclip a larger subclip was then created having 17 seconds duration (but ending at the same time as the small subclip). Because it was 4 seconds longer, it therefore needed to start 4 seconds earlier than the subclip from which it was created - hence the negative start time. One wonders what might happen if the 13 second subclip got consolidated and the original (19 second) clip got deleted. This would presumably lead to a situation where the offset was still negative, even after accumulation.
My client has passed this back to Avid to see if they can find out how a large subclip could have been created from a smaller one, so hopefully some more light will be shed on this during the next week or so.
In any case, I've now been sent another AAF file in which 2 mobs appear to have the same ID..!! I'll post some data about that, once I've been able to dig into it a bit further.
I think it needs to be said though that my customers (who are many) are becoming ever more difficult to convince about the merits of moving to AAF. To those on the outside, it seems to be a rather clique-y format that is constantly in flux and somewhat without direction. First, the structured storage format changed, then there was a push to merge with MXF, now I hear that the metadata will be changed to XML format and even the name has changed!!
One could be forgiven for thinking that the primary aim of AAF developers is to keep themselves in work - rather than to deliver a solid, stable interchange format upon which users can rely.
I'm sorry if that sounds harsh but I can promise you that it is the perception of a large number of media professionals and needs to be addressed. Sorry for going off-topic - but these niggly issues over negative offsets and duplicate mob ID's and undocumented properties and lots of other things are damaging the market's confidence in AAF and are not helpful in encouraging its uptake.
Log in to post a comment.