1、 Copyright 2014 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved May 13, 2014 Table of Contents Page Foreword . 3 Intellectual Property 3 Introduction 3 1 Scope 5 2 Conformance Notation 5 3 Normative References 6 4 Identity . 6
2、 4.1 Media Device Control Resource Name . 6 4.2 Uniform Device Name (UDN) 8 4.3 Uniform Service Name (USN) . 8 4.4 Uniform Media Name (UMN) 9 4.5 Uniform Capability Name (UCN) . 10 4.6 Namespace Names . 11 5 Directories . 12 5.1 Registries 12 5.2 Load Balancing and Fault Tolerance 12 6 Signals. 13 6
3、.1 Polling 13 6.2 Asynchronous Callback. 13 7 Capability-Based Programming 13 7.1 Capability Interfaces 14 8 Services 15 8.1 Service Factory . 15 8.2 Service Directory . 15 8.3 Service Registry 15 8.4 Service Templates 15 9 Devices 16 9.1 Device Directory 16 9.2 Device Registry . 16 9.3 Device Hiera
4、rchy . 16 10 Modes 17 Page 1 of 85 pages SMPTE ST 2071-1:2014 Revision of SMPTE ST 2071-1:2012 SMPTE STANDARD Media Device Control Framework (MDCF) SMPTE ST 2071-1:2014 Page 2 of 85 pages 11 Media 17 11.1 Media Assets . 17 11.2 Material Assets 17 11.3 Media Files 18 11.4 Media Instances 18 11.5 Medi
5、a Containers . 18 11.6 Media Bundles 18 11.7 Media Pointers and Segments . 18 11.8 Media Directory 18 12 Query Expressions and Query Syntax . 19 12.1 Attribute Designation 20 13 Delegation of Control 21 13.1 Acquiring a Session 21 13.2 Exclusive Locking . 21 13.3 Requesting a Session . 22 13.4 Reque
6、sting an Exclusive Lock . 22 13.5 Administration of Sessions and Locks 23 14 Authentication / Authorization . 24 14.1 Authentication . 24 14.2 Authentication Sequence 24 14.3 Security Layer . 25 14.4 Authentication Servers . 25 14.5 Permissions 25 15 Data and Operation Model . 26 15.1 Identity . 26
7、15.2 Status and Events . 29 15.3 Service Framework 33 15.4 Device Framework . 37 15.5 Session and Lock Management (Delegation of Control) . 41 15.6 Modes Framework . 46 15.7 Media Framework 48 15.8 Data Types 53 15.9 Querying Expression Syntax Object Notation . 57 15.10 Security Framework . 61 Annex
8、 A Bibliography (Informative) 66 Annex B Glossary (Normative) . 67 Annex C Complete MDCF UML (Normative) . 69 Annex D MDCF IDL (Informative) . 70 SMPTE ST 2071-1:2014 Page 3 of 85 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards
9、 developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTEs Technology Committees. Part
10、icipation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual. SMP
11、TE ST 2071-1 was prepared by Technology Committee 34CS. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements
12、of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. Introduction This section is entirely informative and does not form an integral part of this Engineering Document. Since the inception of media devices there has b
13、een a continual need for a standardized means of controlling them. This need led to the initial creation of protocols such as de-facto, manufacturer based, serial RS-422 control on a 9-pin “D” connector, and later VDCP. However, unfortunately as technologies advanced and media devices became attache
14、d to Internet Protocol networks, these methods were replaced with proprietary solutions. This Media Device Control suite of standards is intended to address this issue and deliver the same level of interoperability as its predecessors, using Internet Protocol, with provisions for extensibility and a
15、daptability. Both device and media control standardization are included in this document. This suite of standards presents media in a fashion similar to that of a POSIX file system, allowing media to be searched and manipulated without regard to its physical location. This document contains the spec
16、ification of the core Media Device Control Framework (MDCF) and is Part 1 of a series of documents that define the complete Media Device Control over IP specification. All subsequent documents describe applications of or extensions to this framework, such as the wire protocols and/or additional devi
17、ce interfaces. The diagrams below depict how a client interacts with the MDC system to play media. Figure 1 Using MDC Directories to Play Media illustrates the flow a client would follow to search for devices and media, while Figure 2 Directly Connecting to the Play device depicts a client that has
18、implicit knowledge about a device and accesses the device directly, without the use of the directories. SMPTE ST 2071-1:2014 Page 4 of 85 pages Figure 1 Using MDC Directories to Play Media Figure 2 Directly Connecting to the Play Device SMPTE ST 2071-1:2014 Page 5 of 85 pages 1 Scope This document i
19、s Part 1 of a series of documents that specify the concepts, data structures and operations required to control modern media devices. This document presents a platform agnostic model that can in turn be adapted to any protocol, platform and/or architecture, for the purpose of machine level control o
20、f media devices on Internet Protocol networks. Further documents in this series will supply protocol and platform specific adaptations of this model. The Media Device Control (MDC) suite of standards addresses the low level, atomic operations needed to control media devices over the Internet Protoco
21、l, in a deterministic, low-latency manner. MDC is designed to bridge the gap between workflow level interfaces and the physical hardware and is intended for use on private networks, with sufficient bandwidth and bounded latency. While the control of devices over the Internet may be inherently suppor
22、ted, it is not recommended for low-latency applications, due to the unpredictable nature of public, general-purpose, networks. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: “shall“, “should“,
23、or “may“. Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords. All text in this document is, by default, normative, ex
24、cept: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” The keywords “shall“ and “shall not“ indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted. The keywords, “sho
25、uld“ and “should not“ indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of actio
26、n is deprecated but not prohibited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document. The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden”
27、indicates “reserved” and in addition indicates that the provision will never be defined in the future. A conformant implementation according to this document is one that includes all mandatory provisions (“shall“) and, if implemented, all recommended provisions (“should“) as described. A conformant
28、implementation need not implement optional provisions (“may“) and need not implement them as described. Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall
29、be next; followed by formal languages; then figures; and then any other language forms. SMPTE ST 2071-1:2014 Page 6 of 85 pages 3 Normative References The following standards contain provisions that, through reference in this text, constitute provisions of this standard. At the time of publication,
30、the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. IETF RFC 3986, Uniform Resource Identifiers (URI): Generic Sy
31、ntax IETF RFC 2141, Uniform Resource Name (URN): URN Syntax IETF RFC 1737, Functional Requirements for Uniform Resource Names IETF RFC 1738, Uniform Resource Locator (URL) IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types IETF RFC 5234, Augmented BNF for Syntax Specif
32、ications: ABNF ISO/IEC 19505-1,Object Management Group Unified Modeling Language (UML), Infrastructure ISO/IEC 19505-2,Object Management Group Unified Modeling Language (UML), Superstructure ISO/IEC 8601:2004, Date Elements and Interchange Formats Information Interchange Representation of Dates and
33、Times SMPTE ST 330:2011, Unique Material Identifier (UMID) SMPTE RP 205:2009, Application of Unique Material Identifiers in Production and Broadcast Environments 4 Identity The unique identification of resources is a cornerstone to any network based device or media control system. Each resource with
34、in the system shall be addressed with a persistent identifier and those identifiers shall provide enough information so that each resource is uniquely identified. The Media Device Control (MDC) Framework defines an identity scheme that is based on the Uniform Resource Name (URN) as defined by the In
35、ternet Engineering Task Forces RFC 1737 and RFC 2141. 4.1 Media Device Control Resource Name Media Device Control Resource Names are Uniform Resource Names (URNs) defined by the MDCF to persistently and portably identify specific system resources, such as devices, namespaces and media. All Media Dev
36、ice Control Resource Names shall share the same format and may be used to wrap existing identity schemes or to create new ones. Media Device Control Resource Names shall not imply the availability of the identified resource, but shall be used in conjunction with directories to identify, locate, acce
37、ss, and control the identified resources. The following ABNF grammar defines the Media Device Control Resource Name syntax. Please refer to RFC 5234 for the definition of the ABNF language. ;start ABNF notation NAMESPACE “:” NAME_TYPE “:” SCOPE “:” IDENTITY_ATTRIBUTES NAMESPACE = “urn:smpte” NAME_TY
38、PE = 1*(DIGIT / ALPHA) SCOPE = NAME *(“.” NAME) IDENTITY_ATTRIBUTES = ATTRIBUTE *(“,” / “;”) ATTRIBUTE) ATTRIBUTE = NAME “=” VALUE NAME = 1*(DIGIT / ALPHA / “+” / “-“ / “_” / SP) VALUE = DQUOTE 1*(SP / “!” / %23-%2B / %2D-%3A / “” / %3E-%7E / ESCAPE_SEQUENCE) DQUOTE ESCAPE_SEQUENCE = “%” 2HEXDIG ;en
39、d ABNF notation SMPTE ST 2071-1:2014 Page 7 of 85 pages 4.1.1 Namespace Media Device Control Resource Names shall be assigned to and arranged by namespace. The namespace shall be the text of the Media Device Control Resource Name following the URN scheme (“urn:”), up to and including the last colon
40、(“:”). Namespaces are used to help depict the scope, functional arrangement and relationship of resources within the MDCF and group resources by system, sub-system and/or purpose. Each namespace shall have a parent namespace and may have zero or more child namespaces, forming a genealogy or hierarch
41、y of namespaces. The namespace hierarchy is separate from but related to the physical arrangement of the system, reflecting the functional arrangement of the system resources and their ability to interact. Some fundamental assumptions are made regarding the assignment and management of namespaces in
42、 the MDCF. 1. Namespaces are assigned to sub-systems, with each sub-system having its own namespace. 2. Namespaces are assigned by workflow, purpose and/or usage. 3. Resources in the same namespace share the same purpose and work together to fulfill that purpose. 4. Resources in the same namespace c
43、an interact and connect directly with one another. Given the previous assumptions, the following rules apply. 1. If the purpose or workflow of a resource changes, the namespace of that resource shall change. 2. If a resource is moved to another sub-system, the namespace of that resource shall change
44、. 3. Changes to the namespace assignment of a resource shall change the identity of that resource within the MDCF, even if the vendor specific identity of that resource remains the same. 4.1.1.1 Scope A Scope shall be a collection of resources, arranged in a logical fashion based on the vendor, work
45、flow and/or purpose of the resources and may contain the location information, if the distances between the resources is large enough to impact the latency or deterministic nature of the network communications. Each Media Device Control Resource Name shall contain a Scope depicted by a period “.” de
46、limited list of name parts defined in a manner that is meaningful to both humans and the MDCF. The period delimitation was chosen to simplify the parsing of the Scope by differentiating it from the rest of the URN namespace. Example Scopes company company.east company.east.ingest company.east.ingest
47、.vendor company.east.ingest.vendor.1 4.1.2 Identity Attributes The MDCF identity scheme shall provide a space for vendor specific information, known as identity attributes. The identity attributes shall be appended to the namespace of the Media Device Control Resource Name as a comma (“,”) or semi-c
48、olon (“;”) delimited list of name/value pairs, with the name of the identity attribute and the value being separated by an equals (“=”) sign. The identity attributes allow Media Device Control Resource Names to wrap existing identity schemes without the need for external mapping mechanisms. There ar
49、e no restrictions to the contents of an identity attribute, provided those contents can be represented as a string of characters. SMPTE ST 2071-1:2014 Page 8 of 85 pages 4.2 Uniform Device Name (UDN) The Uniform Device Name (UDN) shall be a Media Device Control Resource Name of type “udn”, with “udn” being a new sub-namespace of the SMPTE URN namespace (“urn:smpte”) that uniquely identifies devices within the MDCF. Example UDNs urn:smpte:udn:Subsystem.Name:attribute1=value;attribute2
