Hello,
The field PhysicalTrackNumber of media files created by AMT3 is invalid on sourceMob with essences and is absent on masterMob. Our software uses this properties to manage mapping, do you think you can do something about it ?
sample dump:
Object of Class: SourceMob
MobID: { {0x6,0xa,0x2b,0x34,0x1,0x1,0x1, ... 0xa6 } } }
Slots: Strong Object Reference Array [1] of MobSlot
kAAFTypeID_MobSlotStrongReferenceVector [0]: Object of Class: TimelineMobSlot
SlotID: 1
Segment:
Object of Class: Sequence
DataDefinition: Picture
PhysicalTrackNumber: 352388609

Sincerely,

Jean

Aurélien,

ST377 states that PTNs are defined by the Essence Container specification. For mapping into the MXF Generic Container, ST0379-2 defines the PTN for the file source mob as UInt32 comprising four bytes that shall have the same values as bytes 13-16 of the KLV key of the corresponding System Element. AMT3 follows this rule so this is 100% intentional. Please refer to section 9.3 of ST0379 for details.  

You are right, PTN are not invalid on sourceMob with essence according to ST-379. My last message was wrong and incompleted. I would like to specify the problem.

The PTN is used differently on sourceMob with essence from others types of mob. I understand this propertie depends on the media type on sourceMob with essence data. On physical sourceMob linked to tape or import file, the propertie specifies the stream index of the source. And finally on the masterMob it tells the target stream index.

You can read at 4.4 of "AAF Object Specification v1.1", AAFlib documentation :
In a CompositionMob or MasterMob, PhysicalTrackNumber is the output channel number that the MobSlot should be routed to when played.

The undefined PTN of the masterMob mobSlot forces to determine the stream index using the slot order. Anyway we are doing like that, if it is ok there is nothing to modify on your side and on ours.

Many thanks.

Jean Pagliani