28
Technical Review | January-March 2013
Because the UMID by itself does not tell where to access the desired AV material, the application needs to resolve the UMID; i.e., to dynamically associate the UMID with its corresponding URL. In this example, when the application distributes a query such as “Do you have an AV material with this UMID value?”, the Ingest server replies “Yes I have!” and provides the URL of the requested AV material, which can then be used by the application to access the material.
While this scenario demonstrates the principle of material search and access, it may be generalized by dividing a media production system into two layers: the Application layer for various applications including workflow management, and the Media layer for media devices such as material servers and media processors.
In the upper Application layer, light weight data such as workflow information and/or material metadata, typically represented in XML (eXtensible Markup Language), need to be handled in a flexible way, while the heavy weight media data, need to be intensively processed in the lower Media layer. Then, it is the UMID and its connection via the URL which loosely couples those two layers, resulting in much higher flexibility for the media device reinforcement and/or replacement in the system compared with the conventional way using static URLs. Note that this is consequently the best fit to a SOA (Service Oriented Architecture) based media production system such as the FIMS (Framework for Interoperable Media Service).
To realize this scenario, however, a set of UMID application rules need to be established. First, it is obvious that each material server, even when supplied from a different vendor, needs to appropriately respond with the URL for a given UMID to an external application based on a defined UMID resolution protocol. Furthermore, in order for the UMID to be used as a common material identifier in the industry, it must be always valid.
But, what is a valid UMID? The UMID Application Principles are introduced to answer the question, i.e., they are the most fundamental rules that every product must strictly follow in order to maintain the valid UMID. While the detailed principle statements are still under study, the following statements are possible candidates:
Principle 1: UMID Integrity Different AV material shall always be identified by different UMID value,
Principle 2: UMID Identification The UMID identifies the Essence representation at its playout.
The Principle 1 should be obvious, i.e., different AV materials must not share the same UMID value. The Principle 2 might be controversial, but it is crucial to provide a clear boundary between identical and different AV materials. According to the proposed Principle 2, two AV materials may be said identical (and thus share the same UMID) when their A/V essence is identical at their playout and any differences occur only in their descriptive metadata such as a title or description.
Note that because the UMID Application Principles should be defined by common industry rules, they will be specified
as normative part of the relevant industry standards. But because such principles are usually too abstract to be implemented into products as they state, a concept called UMID Managed Domain is introduced as an embodiment of the UMID Application Principles.
The UMID Managed Domain is defined as a logical space composed of appropriately managed AV materials via their valid UMIDs. This is implemented by introducing a material manager that manages the AV materials with their UMIDs and corresponding URLs in the Domain. To maintain the UMIDs validity, the material manager plays a crucial role in any AV material manipulation in the Domain.
For example, when AV material having its own UMID in some non-standard location is imported into the Domain, the material manager should replace its original UMID with a newly created value. This is because there is no guarantee that the original UMID is globally unique. When the material manager creates a new UMID according to the standard (SMPTE ST 330), the global uniqueness of the UMID is always guaranteed.
Another example is given for AV material modification. When an AV material containing its UMID in it is duplicated and a part of the Essence in one of the AV materials is modified by overwriting, the material manager also needs to replace its contained UMID with a newly created value in order to avoid those two AV materials of different Essence sharing the same UMID.
It should be mentioned that the material manager is also responsible for an appropriate maintenance of the UMID and its corresponding URL for each AV material, because it is in the position to know both of them. As a result, it is the material manager that must take the active role in the aforementioned UMID resolution protocol.
An interesting property of the UMID Managed Domain is that if an AV material having its own UMID is imported from another UMID Managed Domain, the material manager does not have to replace the original UMID because its global uniqueness is already guaranteed. Consequently, identical AV materials can co-exist in the source and the destination UMID Managed Domains. Effectively those two Domains are merged to form a single UMID Managed Domain.
This property of the UMID Managed Domain can be extended also in a system level, i.e., if all products participating in a media production system are correctly supporting the UMID Managed Domain, the Domains may be merged to cover an entire system, resulting in the UMID based media production system (Figure 3). Note that, in this system, the UMID is used as a common material identifier over the system even when multiple MAM (Media Asset Management) products from different vendors are involved. It should be also noted that the same protocol as used between the application and a material server in Figure 2 can be also used among products in Figure 3.
Furthermore, because of the global uniqueness of the UMID, the above scenario may be further extended in a global sense. According to the UMID Application Principle 2, two
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48