search

SMPTE / st429-20

Public CD of SMPTE ST 429-20 1ED
Other
0 stars 0 forks source link

Encoding of UUID items within the LocalTagEntry Batch of the Primer Pack #1

Closed palemieux closed 2 years ago

palemieux commented 3 years ago

ST 377:2004, Table 12 implies that UUIDs are permitted in the LocalTagEntry Batch of the Primer Pack, but is ambiguous on how they are encoded.

Request clarification from 31FS

palemieux commented 3 years ago

@jpviollet The type of the UID item is defined in ST 377:2004 as UL or UUID. ST 377-1:2019 defines a AUID as a 16-byte UID that shall contain a UL or a UUID. So I think the type of the UID item is identical in both ST 377:2004 and ST 377-1:2019. Do you agree?

ST 377-1:2019

ST 377:2004

jpviollet commented 3 years ago

The fact that the type is "UUID or UL" in both standards is somehow true. The problem is the encoding/decoding of the value in case of UUID, as a ST377-1:2019 encoder would encode this UID as AUID, and as such swapping bytes in case of a UUID - this is not expected in ST377:2004, meaning that a ST377:2004 decoder would most likely get the value without knowing it has to swap top/bottom 8 bytes.

This is what we tried to solve by indicating in section 5.3: "Each UID item within the LocalTagEntry Batch of the Primer Pack should be a UL. NOTE: The encoding of UUID values as UID items is ambiguous in SMPTE ST 377:2004."

Further thinking about this, we should most likely further explain the possible issue in the NOTE by indicating specifically something like:

"NOTE: SMPTE ST 377-1:2019 requires UL or UUID values to be stored in a Property of type AUID in the LocalTagEntry Batch, which implies that a UUID is stored such that its top and bottom 8 bytes are swapped - this is not the case in SMPTE ST 377:2004, which could lead to value mis-understanding. Usage of a UL value instead of a UUID is not expected to introduce such confusion."

Does this make sense?

palemieux commented 3 years ago

@jpviollet Thanks for the reminder. You are right that ST 377:2004 does not specify that UUIDs are byte-swapped, like ST 377-1:2019 does.

In fact, it might be worse: my copy of EG 41:2004 implies that, in 2004, both byte-swapped and non-byte-swapped UUIDs were permitted -- see snapshot below. I have requested an official copy.

Maybe Bruce (@SMPTE-TC) has an opinion.

image

palemieux commented 2 years ago

Copy of (withdrawn) EG 41: https://smpte.sharepoint.com/:b:/r/sites/SCStandardsCommunity/Shared%20Documents/Reference%20Documents/Engineering%20Guidelines/eg0041-2004_withdrawn2010-private.pdf?csf=1&web=1&e=1R1RS9

@jpviollet So it does look like UUIDs may be stored in a variety of ways.

The current recommendation to encode only ULs in the Primer Pack is a good idea.

We could go further and recommend that processors assume that the 16-byte value in the Primer Pack is opaque, and not try to parse a UUID or UL out of it.

palemieux commented 2 years ago

Per 2022-02-10 meeting: the text in the following draft is sufficient:

https://smpte.sharepoint.com/:w:/s/21DC-DocumentMaintenance/Eal2gNBYVRNBjnoj0QMW2CIB8KCzUtG2OmEgkWcltezUOw?e=oYFZ01

Each UID item within the LocalTagEntry Batch of the Primer Pack should be a UL.