Understanding UMID And KLV

They may sound like Houston's summer weather and a Dutch airline, but UMID and KLV are really key elements in the effort to expedite the management and interchange of program material. When the Pro-MPEG Forum and the Advanced Authoring Format Association (AAF) jointly demonstrated the MXF and GFX file exchange formats at NAB, UMID and KLV were among the many building blocks that enabled that open source breakthrough. As time goes on, you'll see UMID and KLV mentioned more and more often.
Author:
Publish date:

They may sound like Houston's summer weather and a Dutch airline, but UMID and KLV are really key elements in the effort to expedite the management and interchange of program material. When the Pro-MPEG Forum and the Advanced Authoring Format Association (AAF) jointly demonstrated the MXF and GFX file exchange formats at NAB, UMID and KLV were among the many building blocks that enabled that open source breakthrough. As time goes on, you'll see UMID and KLV mentioned more and more often.

If we're going to get maximum benefit from all the digital content we're creating, we need effective, universal ways to locate and manage programs and the various bits and pieces that go into making them.

The Society Of Motion Picture And Television Engineers (SMPTE) has been working with users, manufacturers, and industry groups such as the Pro-MPEG Forum and AAF to provide some universal solutions. Most of this work is based on the SMPTE Data Model that grew out of SMPTE's seminal 1998 cooperation with the European Broadcasting Union (EBU) on digital program interchange.

The model defines "content" as a combination of "essence" and "metadata." The essence is the meat and potatoes—video, audio, graphics, etc. It's the bits intended for the consumer. Metadata is all the other important stuff that the consumer never sees—time code, encoding parameters, shooting data, EDLs, and rights documentation. While it begins with video and audio, the SMPTE model can be extended to virtually any type of media.

Metadata has been called "the bits about the bits." As the concept has evolved over time, some have suggested that it's really the megabits about the bits. KLV and UMIDs are two of the new tools standardized by SMPTE to help corral and manage all those elements that go into a program or piece of "content."

KLV is a data encoding protocol (SMPTE 336M). It stands for the Key, Length, and Value that make up items of data. The "key" is a unique, registered sequence of bits that tells you what's coming (video, audio, EDL, UMID, whatever). It follows International Standards Organization (ISO) rules for an "Object Identifier," in this case a SMPTE Universal Label (SMPTE 298M). Since it is registered in an internationally standardized form, any system receiving the key can trace its meaning to the appropriate registry and determine what to do with the data, even if it had no prior knowledge of what to expect. "Length," the next element in the KLV protocol, simply indicates how long the payload will be, and the remainder of the item is the "value," or payload.

KLV's success relies on its registries. They facilitate interchange by providing a common repository for definitions (data types, signal formats, effect names, plug-in types, content identifiers, etc.). With standardized definitions, vendors can extend systems and add features in a compatible fashion. The registries may be public and global (such as the SMPTE Universal Label registry and the SMPTE Metadata Dictionary), or they may be private for such things as contract provisions and billing data. To avoid having to query a global registry for every action, local registries provide temporary storage of the most frequently used identifiers for a particular application.

UMIDs are SMPTE Unique Material Identifiers (SMPTE 330M / RP205). Where other unique program identifiers such as the International Standard Book Number (ISBN) and International Standard Audiovisual Number (ISAN) are simple labels that identify only completed works, UMIDs can uniquely identify every component of a program and provide linkage between the various pieces of essence and their associated metadata.

They are the link that ties ownership, rights, edit decisions, pan and scan vectors, virtually anything of importance, to its associated essence regardless of where or how it's stored. Even analog programming can carry UMIDs in watermarks or vertical blanking.

The concepts of a "content unit" and a "clip" are essential to understanding the UMID. A "content unit" is dependent on the type of content. For digital audio, it could be the length of one audio frame, perhaps 4 ms. For video, it might be 1/60 of a second for an NTSC field or as much as half a second if the video was encoded as a long MPEG-2 group of pictures. In any event, it's the smallest practical unit that you could work with under a given set of circumstances. A "clip" is a sequence of one or more of these content units. The 32-byte basic UMID provides a globally unique identification for a "clip." The first 12 bytes are the key identifying it as a UMID. They're followed by one byte to indicate length and 19 bytes of value. The first three value bytes are an "instance number," the remaining 16 are the "material number."

The instance number provides a means of tracking copies of an original. An original high definition clip, its clones and standard definition, postage stamp or other copies would all have the same material number, but each would have a different instance. The instance number could come from a pseudo random generator or be assigned by a local registry. The material number gets it's global uniqueness from a combination of time, date, a random number, and a registered code for the machine that created it.

If you need more detailed information you can use an "extended" UMID which can uniquely identify each and every content unit in a clip. It adds another 32 bytes of "signature metadata" to the basic UMID. You don't have to use all of them, but the signature metadata has slots for time and date of creation, longitude, latitude, and altitude as well as country, organization, and user codes.

While this may seem like information overkill, most of this stuff can be created automatically. When you consider that the UMID provides the core linkage that can identify essence regardless of its current location, ownership or status, you can see that these are bits well spent.

In doing all this work, SMPTE and its collaborators have been careful not to reinvent the wheel. There has been a concerted attempt to build on already proven computer and Internet standards. KLV coding conforms to ISO standards. The UMID takes into account numbering schemes previously standardized by the Institute Of Electrical And Electronics Engineers and the Internet Engineering Task Force.

In addition to their role in universal file exchange, UMIDs and KLV coding will also be key enablers for new asset management systems and other digital integration initiatives. Like all voluntary standards, their ultimate success will depend on how manufacturers and users implement them.