[RichardRudek]

I'm having trouble reconciling what I'm reading about UUID and UL's in 5.5.8 of the SMPTE eg41-2004 MXF Engineering Guide and what has been implemented in MXFLib (types.h), with what I'm seeing in an MXF file that was produced by an FS100 DTE.

A specific example being their ProductID. Here's a snippet of MFXDump run against a file:

Quote:

Dump an MXF file using MXFLib
- using dictionary "T:\MXF data for Richard\dict.xml"

Partition at 0x00000000 is for BodySID 0x0000
0x00000000 : ClosedCompleteHeader(PartitionMetadata)
0x00000014 : MajorVersion(UInt16) = 1
0x00000016 : MinorVersion(UInt16) = 2
0x00000018 : KAGSize(UInt32) = 1
0x0000001c : ThisPartition(UInt64) = 0
0x00000024 : PreviousPartition(UInt64) = 0
0x0000002c : FooterPartition(UInt64) = 1575968768
0x00000034 : HeaderByteCount(UInt64) = 4656
0x0000003c : IndexByteCount(UInt64) = 27840
0x00000044 : IndexSID(UInt32) = 1
0x00000048 : BodyOffset(UInt64) = 0
0x00000050 : BodySID(UInt32) = 0
0x00000054 : OperationalPattern(Label) = [060e2b34.0401.0102.0d010201.10020000]
0x00000064 : EssenceContainers(EssenceContainers)
0x0000006c : EssenceContainer(Label) = [060e2b34.0401.0101.0d010301.02026102]

Header Metadata:
0x00000584 : Preface(InterchangeObject)
0x00000598 : InstanceUID(UUID) = {570a7c14-d8ca-4af8-91db-c03cd5c660b8}
0x000005ac : LastModifiedDate(Timestamp) = 2006-10-24 9:28:11.000
0x000005b8 : Version(VersionType) = 258
0x000005be : Identifications(Identifications)
0x000005ca : Identification(UUID) = {cce2ed58-9001-05a4-93fe-9d7ede3afb35}
0x000005ca : Identification(UUID) -> Strong Reference to Identification
0x0000062a : Identification(InterchangeObject)
0x0000063e : InstanceUID(UUID) = {cce2ed58-9001-05a4-93fe-9d7ede3afb35}
0x00000652 : ThisGenerationUID(UUID) = {51e9bfe1-eac4-867e-c323-fca15df7d6a1}
0x00000666 : CompanyName(UTF16String) = Focus Enhancements, Inc.
0x0000069a : ProductName(UTF16String) = FireStore
0x000006b0 : VersionString(UTF16String) = v1.4
0x000006bc : ProductUID(UUID) = [65000000.0000.0000.46697265.53746f72]
0x000006d0 : ModificationDate(Timestamp) = 2006-10-24 9:28:11.000

From the square brackets and the fact that the element has a type of UUID, this should be a UL. Right ?

If so, then if I'm reading 5.5.8 right, the UL shown above is illegal, right ? - not documented in SMPTE spreadsheets.

Quote:

5.5.8 Storing ULs and UUIDs in the same property
Some data fields, such as the UID property of the LocalTagEntry batch in the primer, can contain
either a UL or a UUID. In this case there is an advantage to using a particular byte order for the
UUIDs. All UUIDs have a 1 in the most significant bit of the “clk_seq_hi_res” word (byte 9),
whereas all ULs have a 0 in the most significant bit of the first byte. If UUIDs are stored with a
byte order that places the “clk_seq_hi_res” word first, then it is always possible to tell if the value
is a UL or a UUID by examining the MSB of the first byte. This byte order also prevents the
remote possibility of a UUID being stored that matches a registered UL. For these reasons, it is
recommended that when any UUID is published for inclusion in a data field that can also
contain ULs, the byte order specified for that UUID be the same as the ISO/IEC 11578 default
order, but with the upper and lower eight bytes swapped.

The section above gives rise to the following guidelines:
• A UUID may be stored in a data field of type UL by swapping the top and bottom 8 bytes of the
UUID (the most significant bit of the first byte of such a swapped UUID is always 1);
• MXF decoders should accept a swapped UUID in a place where a UL is expected.
NOTE – AAF uses a compatible byte-swap method for storing ULs and UUIDs in the same
properties, which it defines as AUIDs.

[Matt Beard]

Quote:

If so, then if I'm reading 5.5.8 right, the UL shown above is illegal, right ? - not documented in SMPTE spreadsheets.

Right.

For some reason there is a common misconception that you can put whatever you want in a UUID field. This is not true - the format is defined by RFC 4122.

MXF (and for that matter AAF) use a trick to allow UUIDs and ULs to be used interchangeably; all valid UUIDs have the MSB of the 9th byte set and all ULs start with 0x06. This means that if "end-swap" a UL (you re-order a UL so that the first eight bytes are stored last and the last eight first) you can store it in a UUID field and distinguish it from a genuine UUID. This process is described in EG41 section 5.5.8.

So, we have the situation that MXF UUID fields can either store a UUID as defined by RFC 4122 (9th byte has its MSB set) or an end-swapped UL (9th byte is 0x06).

What I frequently find is someone has simply put ASCII text in the field instead, such as "MyFirstDevice". This is not a UUID, nor is it an end-swapped UL.

If you look at the bytes that are stored in the ProductUID given you will see that they are actually "FireStore".

When MXFLib displays a UUID it checks the MSB of the 9th byte; if it is set it displays it as a UUID (with curly brackets), otherwise it end-swaps it and displays it as a UL (with square brackets). If the data is neither a UUID or a UL you will just get garbage!

Note: These mixed UUID/ULs are generally called AUIDs. If you do the same trick in reverse (store an end-swapped UUID in a UL field) it seems to be increasingly common to call that an IDAU (you see what they have done? They have end-swapped AUID)