SMPTE ST 380M-2004 Television Material Exchange Format (MXF) - Descriptive Metadata Scheme-1 (Standard Dynamic).pdf

《SMPTE ST 380M-2004 Television Material Exchange Format (MXF) - Descriptive Metadata Scheme-1 (Standard Dynamic).pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 380M-2004 Television Material Exchange Format (MXF) - Descriptive Metadata Scheme-1 (Standard Dynamic).pdf（53页珍藏版）》请在麦多课文档分享上搜索。

1、 1 Scope This standard defines a number of descriptive metadata frameworks collectively called the MXF descriptive metadata scheme-1 (DMS-1). Each descriptive metadata (DM) framework is defined by a logical structure of metadata sets that allows them to be used as a plug-in to the header metadata of

2、 a material exchange format (MXF) file. These descriptive metadata (DM) frameworks and their associated metadata sets may be applied to any MXF operational pattern specification. Every DM framework in this DM scheme shares the same underlying data model. The standard defines each DM framework as a s

3、et structure and includes a definition for all individual metadata sets used in this scheme. All metadata sets are defined in tabular form including a reference to the SMPTE metadata dictionary for each metadata property. The document also defines how these DM frameworks relate to the audio-visual c

4、ontent of the body of an MXF file to enhance the usability of the audio-visual content of an MXF file through descriptive metadata. NOTE This standard is a dynamic document which allows new components to be added according to the procedures described in the SMPTE 359M. Specifically, new metadata DM

5、frameworks, sets and individual metadata properties may be added to this standard in future revisions as requirements emerge. In order to maintain backwards compatibility, no DM framework, metadata set or metadata property defined in this document shall be removed or otherwise changed in such future

6、 revisions. 2 Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this s

7、tandard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. SMPTE 336M-2001, Television Data Encoding Protocol using Key-Length-Value SMPTE 359M-2001, Television and Motion Pictures Dynamic Documents SMPTE 377M-2004, Television MXF File

8、 Format Specification SMPTE RP 210, Metadata Dictionary Registry of Metadata Element Descriptions 3 Glossary of acronyms, terms and data types The general glossary of acronyms, terms and data types used in the MXF specification is given in SMPTE 377M and is not repeated here. Page 1 of 53 pages SMPT

9、E 380M-2004 Copyright 2004 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100 Approved September 22, 2004 SMPTE STANDARD for Television Material Exchange Format (MXF) Descriptive Metadata Scheme-1 (Standard, Dynamic) SMPTE 380M-2004

10、 Page 2 of 53 pages 3.1 Acronyms used in this standard DM: Descriptive metadata. DMS: Descriptive metadata scheme. 3.2 Terms used in this standard Framework: A term used to describe a collection of metadata sets with a defined function. Typically one or more frameworks may be derived from a common c

11、lass model. 4 Introduction There are several parts to the MXF specification. This part defines a collection of DM frameworks known as the descriptive metadata scheme-1 (DMS-1). The MXF file format specification has a number of structural metadata packages in the header metadata that describe the ess

12、ence data and essence containers in the file body. This standard provides a number of DM frameworks that may be plugged into the structural metadata packages of the header metadata based on the mechanism defined in the MXF file format specification. These DM frameworks are a part of the header metad

13、ata and provide additional editorial value to an MXF file. Further information on using descriptive metadata in MXF is given in SMPTE EG 42. 4.1 Frameworks and context A DM framework is a grouping of related descriptive metadata properties and sets (e.g., editorial) which describe the contents of an

14、 MXF file body. The same metadata properties and sets frequently appear in different DM frameworks because they share the underlying data model of this DM scheme. The DM framework defines the context of a metadata property or set dependent upon the framework that directly, or indirectly owns it. Thi

15、s standard defines a number of DM frameworks as follows: Production framework: containing descriptive metadata sets and properties which provide identification and ownership details of the audio-visual content in the file body. In the context of MXF, production comprises metadata that applies to a c

16、omplete input or output of the MXF file as a whole and is not associated with segmentation of the timeline. Note that where an MXF file forms the input to another MXF file, this still holds true. The production framework metadata relates to the MXF file content whether it be unfinished work-in progr

17、ess, a completed episode of a program, a complete series of programs or a program item. Clip framework: containing descriptive metadata sets and properties that provide capture and creation information about the individual audio-visual clips in the file body. In the context of MXF descriptive metada

18、ta, a clip is a continuous essence element, or essence element interleave, in the essence container. This should not be confused with the SourceClip item from the MXF format specification which is a mechanism for linking portions of package sequences to each other. This essence container may compris

19、e of a number of interleaved audio, video, or data essence elements. Individual clips are the input from which the editorial experience is created. Examples include: an instance of a stereo recording of a music performance; an instance of the audio and video of an interview ( in this case the noddie

20、s and cutaways recorded at the same interview for editing into the finished piece later would be separate clips); SMPTE 380M-2004 Page 3 of 53 pages the edited interview, including noddies and cutaways, forming input to another program; an instance of a take in the movie industry but note that one c

21、lip can contain more than one take. Clips may have metadata that describes one or more shots. Note that, in the context of a clip, a shot is a description of the true nature of the audio-visual content. Scene framework: containing descriptive metadata sets and properties that describe actions and ev

22、ents within individual scenes of the audio-visual content of the file body. In the context of MXF, scene is an editorial concept and describes a continuous section of content in an MXF file. Scenes are, in general, characterized by narrative or dramatic coherence. The division of the output timeline

23、 into scenes is a matter of editorial decision and, thus, varies with the criteria applied. Scenes may overlap and they may relate to a point in time rather than having a duration. Scenes may have metadata that describes one or more shots. Note that, in the context of a scene, a shot is editorial in

24、 nature and is not necessarily related to the true nature of the audio-visual content. DM frameworks give contextual meaning to a metadata set by logically grouping metadata sets used in the same context. For example, a metadata set that describes a location can be used to describe the real location

25、 (the actual location of the camera) or the fictional location (where the scene is supposed to be set). For example, a name in the clip framework describes could be a participants real name, whereas a name in the scene framework could be that of a fictional character (e.g., Falstaff). Figure 1 illus

26、trates the structure of the DM frameworks contained in the header metadata and how it relates to the content of the MXF file body. Descriptions of the use of DM segments and DM SourceClips are given in the MXF descriptive metadata engineering guideline (SMPTE EG 42). This guideline also describes th

27、e use of static, event and timeline track kinds. Figure 1 Descriptive metadata frameworks and their relationship to the content of an MXF file body DM Track 2, Segments 1, 2 they may define instants in time, they may overlap and they may leave gaps. 5.3.1 Abstract superclasses and the DM scheme data

28、 model For consistency with object orientated design, there are implied abstract superclasses in DMS-1. This concept is shown in the class diagram in annex C. Annex C also implies a common data model to be shared by all DM frameworks in this DM scheme. 5.3.2 DM framework data models Models of the DM

29、 frameworks (figure 2a, figure 2b, and figure 2c) define the production, clip and scene frameworks as a grouping of logically connected sets where each set has one or more properties. Each set is defined by a set name (outlined in a bold-lined box) with a set number (as defined in annex A) and inclu

30、des the set properties immediately below the set name. For clarity, the key, length, instance UID, and generation UID values of each set are not shown in figure 2a, figure 2b, and figure 2c. The full definition of each different descriptive metadata set and its properties, together with the set key

31、and length fields are to be found in annex A. Many of the descriptive metadata sets are common to more than one DM framework. Metadata properties in annex A are described in abbreviated form. Every set has a column for the UL of the SMPTE metadata dictionary entry, and it is the dictionary that prov

32、ides the full normative definition of each property. This column shows only the last 8 field entries of the UL in common with the SMPTE metadata dictionary definitions. NOTES 1 Any new set or individual metadata property may be added to figure 2a, figure 2b, and figure 2c in accordance with the type

33、 1 procedures defined in SMPTE 359M. Such new additions shall retain backwards compatibility with any earlier versions of this document. 2 Figure 2a, figure 2b, and figure 2c are originated in an Excel spreadsheet for ease of development. These figures are thus limited by the constraints imposed by

34、the Excel capabilities, although the tool itself has been found to be very useful for the development and maintenance of the DM frameworks. SMPTE 380M-2004 Page 7 of 53 pages Figure 2a Model of the production framework, sets and properties 11 1. Production Framework 0n Metadata Server Locator NOTES:

35、Framework Extended Text Language Code See Locators in MXF Format 1. Numbers to the left of eaFramework Thesaurus Name name indicate the set numberFramework Title 0n 8. Event 0n 9. Publication 2. For clarity, Instance UIDPrimary Extended Spoken Language Code Extended Text Language Code Publication Or

36、ganisation Name Generation UID properties arSecondary Extended Spoken Language Code Thesaurus Name Publication Service Name not shown in this diagram.Original Extended Spoken Language Code Event Indication Publication MediumIntegration Indication Event Start Date and Time Publication RegionEvent End

37、 Date and Time0n 12. Annotation0n 4. Titles 0n 11. Captions Description (See Annotation below)Extended Text Language Code Extended Text Language Code Note that this includes allMain Title Thesaurus Name sets that are referenced by Secondary Title Extended Captions Language Code Annotation, both dire

38、ctly andWorking Title Caption Kind indirectlyOriginal TitleVersion Title 0n 12. Annotation 0n 15. Classification 0n 28. Name-ValueExtended Text Language Code Extended Text Language Code Item Name0n 5. Identification Thesaurus Name Thesaurus Name Item ValueExtended Text Language Code Annotation Kind

39、Content Classification SMPTE Universal Label LocatoThesaurus Name Annotation SynopsisIdentifier Kind Annotation Description 01 32. Cue WordsIdentifier Value Related Material Description Extended Text Language CodeIdentification Locator In-cue WordsIdentification Issuing Authority 0n 13. Setting Peri

40、od Out-cue WordsExtended Text Language Code0n 6. Group Relationship Thesaurus Name 0n Related Material LocatorExtended Text Language Code Setting Date e.g., a particular cataloguing, indexing or thesaurus system 02.02.03.01.00.00.00.00 Programming Group Kind UTF-16 char string Variable Opt The kind

41、of program group of which the program forms a part; e.g., Anthology, Serial, Series, Themed Cluster, Repeating Series etc. 02.02.06.01.00.00.00.00 Progamming Group Title UTF-16 char string Variable Opt The title of a programming group 03.02.01.06.08.01.00.00 Group Synopsis UTF-16 char string Variabl

42、e Opt Synopsis of the group, series, serial etc. 06.10.01.00.00.00.00.00 Numerical Position in Sequence Uint32 4 bytes Opt Position of the group, item, series; etc as a number in a sequence; e.g. 1, 2, 3, etc. 06.10.04.00.00.00.00.00 Total Number in Sequence Uint32 4 bytes Opt Total number of group,

43、 items, series; etc in a sequence 02.02.04.00.00.00.00.00 Episodic Start Number Uint16 2 bytes Opt The episodic number at the start of a series 02.02.05.00.00.00.00.00 Episodic End Number Uint16 2 bytes Opt The episodic number at the end of a series 7. Branding UL Designator Name Type Length Req Def

44、inition Defined in Table 2 Branding Set Set UL 16 Req Defines the Branding set Length BER Length var Req See SMPTE 377M 01.01.15.02.00.00.00.00 Instance UID UUID 16 bytes Req Unique ID of the instance of this set 05.20.07.01.08.00.00.00 Generation UID UUID 16 bytes Opt Identifier that references the

45、 Identification set for the modification 03.01.01.02.02.11.00.00 Extended Text Language Code ISO 7-bit char string 12 chars max Opt The long code that represents the language and optional country variant used for text 01.05.0D.01.00.00.00.00 Brand Main Title UTF-16 char string Variable Opt Main Bran

46、d title (e.g. Horizon) 01.05.0E.01.00.00.00.00 Brand Original Title UTF-16 char string Variable Opt Any original Brand title SMPTE 380M-2004 Page 20 of 53 pages 8. Event UL Designator Name Type Length Req Definition Defined in Table 2 Event Set Set UL 16 Req Defines the Event set Length BER Length v

47、ar Req See SMPTE 377M 01.01.15.02.00.00.00.00 Instance UID UUID 16 bytes Req Unique ID of the instance of this set 05.20.07.01.08.00.00.00 Generation UID UUID 16 bytes Opt Identifier that references the Identification set for the modification 03.01.01.02.02.11.00.00 Extended Text Language Code ISO 7

48、-bit char string 12 chars max Opt The long code that represents the language and optional country variant used for text 03.02.01.02.02.01.00.00 Thesaurus Name UTF-16 char string Variable Opt The name of a specialized vocabulary of selected words or concepts for a particular field; e.g., a particular

49、 cataloguing, indexing or thesaurus system 05.01.01.02.01.00.00.00 Event Indication UTF-16 char string Variable Opt A term that describes what the Event is as a part of the Process. Terms must be consistent with industry or organizational practices to be useful. Includes project, mission, scene, in-points, trigger points, license, option, publication, cataloguing, etc. 07.02.01.02.07.02.00.00 Event Start Date and Time ISO 7-bit char string 32 chars max Opt The absolute start local date and time of the project, mission, scene,