1、 SMPTE ST 2071-1:2016 Copyright 2016 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved May 19, 2016 Table of Contents Page Foreword . 3 Intellectual Property 3 Introduction 3 1 Scope . 5 2 Conformance Notation . 5 3 Normative Re
2、ferences . 6 4 Identity 6 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) 11 4.6 Namespace Names 12 5 Directories 13 5.1 Registries . 13 5.2 Load Balancing and Fault Toleran
3、ce . 13 6 Signals 14 6.1 Polling. 14 6.2 Asynchronous Callback 14 7 Capability-Based Programming . 14 7.1 Capability Interfaces . 15 8 Services . 16 8.1 Service Factory 16 8.2 Service Directory 16 8.3 Service Registry . 16 8.4 Service Templates . 16 9 Devices 17 9.1 Device Directory . 17 9.2 Device
4、Registry 17 9.3 Device Hierarchy 17 10 Modes. 18 Page 1 of 87 pages SMPTE ST 2071-1:2016 Revision of SMPTE ST 2071-1:2014 SMPTE STANDARD Media Device Control Framework (MDCF) SMPTE ST 2071-1:2016 Page 2 of 87 pages 11 Media . 18 11.1 Media Assets 18 11.2 Material Assets . 18 11.3 Media Files . 18 11
5、.4 Media Instances . 19 11.5 Media Containers . 19 11.6 Media Bundles 19 11.7 Media Pointers and Segments . 19 11.8 Media Directory 19 12 Query Expressions and Query Syntax 20 12.1 Attribute Designation . 21 13 Delegation of Control . 22 13.1 Acquiring a Session . 22 13.2 Exclusive Locking 22 13.3 R
6、equesting a Session 23 13.4 Requesting an Exclusive Lock 23 13.5 Administration of Sessions and Locks . 24 14 Authentication / Authorization 24 14.1 Authentication 25 14.2 Authentication Sequence. 25 14.3 Security Layer 26 14.4 Authentication Servers 26 14.5 Permissions . 26 15 Data and Operation Mo
7、del 27 15.1 Identity . 27 15.2 Status and Events . 30 15.3 The Service Framework 34 15.4 The Device Framework . 38 15.5 Session and Lock Management (Delegation of Control) 42 15.6 Modes Framework . 47 15.7 The Media Framework . 49 15.8 Data Types 54 15.9 Querying Expression Syntax Object Notation .
8、58 15.10 Security Framework . 62 Annex A Glossary . 67 Annex B Complete MDCF UML . 70 Annex C MDCF Core IDL (Informative) . 71 Annex D Bibliography (Informative) . 87 SMPTE ST 2071-1:2016 Page 3 of 87 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally
9、-recognized standards 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 Techno
10、logy Committees. Participation 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 Standards Opera
11、tion Manual. SMPTE ST 2071-1:2016 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
12、some of the elements 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 medi
13、a devices there has been 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. But, unfortunately as technologies advanced and media devic
14、es became attached 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 ext
15、ensibility and adaptability. 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 c
16、ontains the specification 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
17、 additional device 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
18、client that has implicit knowledge about a device and accesses the device directly, without the use of the directories. SMPTE ST 2071-1:2016 Page 4 of 87 pages Figure 1 - Using MDC Directories to Play Media Figure 2 - Directly Connecting to the Play Device SMPTE ST 2071-1:2016 Page 5 of 87 pages 1 S
19、cope This document is 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 mac
20、hine level control of 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
21、the Internet Protocol, 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
22、be inherently supported, 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:
23、 “shall“, “should“, 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 de
24、fault, normative, except: 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
25、. The keywords, “should“ 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 possibilit
26、y or course of action 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
27、keyword “forbidden” 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 desc
28、ribed. A conformant 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 defin
29、ition; Tables shall be next; followed by formal languages; then figures; and then any other language forms. SMPTE ST 2071-1:2016 Page 6 of 87 pages 3 Normative References The following standards contain provisions that, through reference in this text, constitute provisions of this standard. At the t
30、ime of publication, 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 1737, Functional Requirements fo
31、r Uniform Resource Names IETF RFC 1738, Uniform Resource Locator (URL) IETF RFC 2141, Uniform Resource Name (URN): URN Syntax IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types IETF RFC 3986, Uniform Resource Identifiers (URI): Generic Syntax IETF RFC 5234, Augmented B
32、NF for Syntax Specifications: ABNF ISO/IEC 8601:2004, Date Elements and Interchange Formats Information Interchange Representation of Dates and Times ISO/IEC 19505-1:2012, Object Management Group Unified Modeling Language (UML), Infrastructure ISO/IEC 19505-2:2012, Object Management Group Unified Mo
33、deling Language (UML), Superstructure 4 Identity The unique identification of resources is a cornerstone to any network based device or media control system. Each resource within the system shall be addressed with a persistent identifier and those identifiers shall provide enough information so that
34、 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 Internet Engineering Task Forces RFC 1737 and RFC 2141. 4.1 Media Device Control Resource Name Media Device Control Resource N
35、ames 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 Device Control Resource Names shall share the same format and may be used to wrap existing identity schemes or to create new on
36、es. 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, access, and control the identified resources. SMPTE ST 2071-1:2016 Page 7 of 87 pages The following ABNF grammar defines the Med
37、ia 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_TYPE = 1*(DIGIT / ALPHA) SCOPE = NAME *(“.” NAME) IDENTITY_ATTRIBUTES = ATTRIBUTE *(“,
38、” / “;”) 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 ;end ABNF notation 4.1.1 Namespace Media Device Control Resource Names shall be assigne
39、d 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 (“:”). Namespaces are used to help depict the scope, functional arrangement and relationship of resources within the MDCF an
40、d 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 hierarchy of namespaces. The namespace hierarchy is separate from but related to the physical arrangement of the system, reflecting
41、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 the MDCF. 1. Namespaces are assigned to sub-systems, with each sub-system having its own namespace. 2. Namespaces are assig
42、ned 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 can interact and connect directly with one another. Given the previous assumptions, the following rules apply. 1. If the purp
43、ose 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. 3. Changes to the namespace assignment of a resource shall change the identity of that resource within the MDCF, even if t
44、he 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, workflow and/or purpose of the resources and may contain the location information, if the distances between the resources are la
45、rge 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 “.” delimited list of name parts defined in a manner that is meaningful to both humans and the MDCF. The period delimitation was
46、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.vendor company.east.ingest.vendor.1 SMPTE ST 2071-1:2016 Page 8 of 87 pages 4.1.2 Identity Attributes The MDCF identity sc
47、heme 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-colon (“;”) delimited list of name/value pairs, with the name of the identity attrib
48、ute 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 are no restrictions to the contents of an identity attribute, provided those contents
49、 can be represented as a string of characters. 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=value urn:smpte:udn:company.ingest.1: urn:smpte:udn:company.ingest.1:id=12345 urn:smpte:udn:company.i
