SMPTE EG 2032-4-2007 Media Dispatch Protocol (MDP) Engineering Guideline (Informative)《媒体调度协议(MDP) 工程指南(资料性)》.pdf

《SMPTE EG 2032-4-2007 Media Dispatch Protocol (MDP) Engineering Guideline (Informative)《媒体调度协议(MDP) 工程指南(资料性)》.pdf》由会员分享，可在线阅读，更多相关《SMPTE EG 2032-4-2007 Media Dispatch Protocol (MDP) Engineering Guideline (Informative)《媒体调度协议(MDP) 工程指南(资料性)》.pdf（35页珍藏版）》请在麦多课文档分享上搜索。

1、 Copyright 2007 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100 Approved December 14, 2007 Table of Contents Page Foreword . 4 Introduction . 4 1 Scope 5 2 MDP Document Structure . 5 3 What Problem Does MDP Address?. 6 4 How Does

2、 MDP Relate to? . 7 4.1 Applications 7 4.2 Transfer Protocols 7 4.3 File Formats . 7 4.4 Security Technologies 7 4.5 Metadata 8 4.6 Web Services. 8 4.7 Middleware. 8 4.8 Proprietary Delivery Solutions 8 4.9 BXF 8 4.10 TV-Anytime, ADI, SIP/SDP, etc. 8 5 How Does MDP Work . 9 5.1 Organizations and Age

3、nts 9 5.2 Projects 10 5.3 Transaction 10 5.4 Initiator Target Agents 10 5.5 Push-Mode, Pull-Mode and Use Cases. 10 5.6 The Manifest Document (Part One). 11 5.7 Messages and Endpoints. 12 5.8 Data Structures 13 5.9 The Manifest Document (Part Two). 13 5.9.1 manifest elements. . 14 Page 1 of 35 pages

4、EG 2032-4-2007SMPTE ENGINEERING GUIDELINE Media Dispatch Protocol (MDP) Engineering Guideline (Informative)EG 2032-4-2007 Page 2 of 35 pages 5.9.2 transferoption elements14 5.9.3 file elements. 15 5.9.4 transferewith elements and status properties. .15 5.9.5 details, updated and comment properties.

5、16 5.10 Transfers, Controllers, Senders and Receivers 16 5.11 The Capabilities Document .17 6 What Happens During a Typical Delivery?18 6.1 Before Initation. .18 6.2 Initiation. 18 6.3 Negotiation.19 6.4 Start of Transfer.19 6.5 During Transfer20 6.5.1 Status check. .20 6.5.2 Pause and resume. .20 6

6、.5.3 Checking received files22 6.6 Completion22 7 What Happens When Things Go Wrong? .22 7.1 General22 7.2 Error Responses and reason Properties. 23 7.3 Stalled and Failed Transfers and updated Properties.23 7.4 Problems that MDP Cannot Express.24 8 How Will MDP Be Kept Both Interoperable and Future

7、-Proof?.24 8.1 Additional Profiles24 8.2 Additional Mappings. .25 8.3 Transfer Protocols. 25 8.4 Capabilities Document.26 9 Can MDP Carry Metadata? .26 10 What Must Be Implemented and What is Optional?27 11 How Can Transfers Be Scheduled and Prioritized?27 12 How Can Agents Discover Each Other? .28

8、13 How Can Good Transfer Performance Be Obtained?.28 14 How Can Deliveries Be Secured .28 14.1 General28 14.2 Authentication29 14.3 Integrity Check.29 14.4 Manifest Document Properties 29 15 Can Parts of Files Be Transferred?.29 16 How Can MDP Work through a Firewall or NAT? .30 17 How Can MDP Be Us

9、ed within a Department or Facility 31 EG 2032-4-2007 Page 3 of 35 pages 18 Can MDP Be Used for Streamed or Live Content? 31 19 Can MDP Be Used for Delivery to Multiple Recipients. 31 Annex A Requirement for Post-Production File Transfer 32 A.1 General. 32 A.2 Target Use Cases. 32 A.3 Simplicity. 32

10、A.4 Packaging. 33 A.5 Content . 33 A.6 Transfer 33 A.7 Security. 33 A.8 Performance and Reliability 34 A.9 Control and Monitoring . 34 A.10 Standards 34 Annex B Glossary . 35 EG 2032-4-2007 Page 4 of 35 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an international

11、ly-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 Techn

12、ology 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 Part XIII of i

13、ts Administrative Practices. SMPTE Engineering Guideline EG 2032-4 was prepared by Technology Committee S22 on Committee on Television Systems Technology. Introduction The Media Dispatch Protocol (MDP) is a means of orchestrating the delivery of media files over IP networks. It defines a standard me

14、chanism for implementations to initiate a delivery, to negotiate the details of the delivery, to provide information about the progress of the delivery, and to provide a confirmation of the outcome of the delivery. It is important to note that MDP is not a transfer protocol. Instead it allows organi

15、zations to transfer files at agreed times, using agreed transfer protocols, and using an agreed set of secure technologies (where appropriate). Furthermore, MDP is not overly prescriptive in regards to which protocols or technologies shall be used; rather it provides a framework which allows organiz

16、ations to choose those that best suit their own needs. This document is the MDP Engineering Guideline. It provides an introduction to the protocol, explains what problem it is intended to solve, and outlines how it works. It also provides information what is contained in the normative MDP specificat

17、ion documents. EG 2032-4-2007 Page 5 of 35 pages 1 Scope This Engineering Guideline gives an introduction to the Media Dispatch Protocol (MDP) for the orchestration of the delivery of media files over IP networks. It describes the purpose of the protocol, and presents an outline of the technology in

18、volved, including an overview of the messages and data structures of the protocol, and how the protocol can be extended to meet future scenarios. The Guideline provides advice on how the protocol can be used in practice, and what should be implemented. It also outlines how common transfer protocols

19、and security mechanisms might be used in conjunction with MDP. 2 MDP Document Structure The MDP specification is split into a number of separate parts (see Figure 1) in order to create a document structure that allows new applications to be covered in the future. These parts are: Part 1 (Normative),

20、 the MDP protocol specification (SMPTE 2032-1). Part 2 (Normative), the MDP mapping specifications (e.g. SMPTE 2032-2 is the MDP/XML/HTTP mapping). Part 3 (Normative), the MDP profile specifications (e.g. SMPTE 2032-3 is the MDP Basic Target Pull profile). Part 4 (Informative), the MDP Engineering G

21、uideline (this document). Figure 1 MDP document suite When implementing MDP, you should ensure that you have the latest version of all of these documents. The individual mapping and profile specifications will be independently updated. Part 1 Protocol Specification (Normative) Part 2.x Mapping Speci

22、fication (Normative) Part 3.x Profile Specification (Normative) Part 4 Engineering Guideline (Informative) Administrative register of transfer protocols XML Schema At smpte-ra.org EG 2032-4-2007 Page 6 of 35 pages This document is the MDP Engineering Guideline (Part 4). It provides an introduction a

23、nd description. This document should be read first because it introduces many of the concepts and explains what problem MDP is intended to solve. It is presented as a set of questions (or an extended FAQ). Concepts are introduced gradually, and, where necessary, more detail is added later. This make

24、s the document easier to read, but less good as a reference, so you are encouraged to make full use of the table of contents. Annex B of this document lists the defined terms in the specification. The MDP protocol specification (Part 1) is at the core of the MDP standard. It defines the syntax and s

25、emantics of the messages and data structures used within the protocol. The MDP mapping specifications (Part 2) define how the messages and data structures of Part 1 are represented on the network. At present there is only one defined mapping (MDP/XML/HTTP); however, as new user and technical require

26、ments are identified, additional mappings will be produced. Each mapping specification will have its own document. The MDP profile specifications (Part 3) define subsets of the messages and data structures of Part 1, and place constraints on the use of these subsets. The purpose of this is to make i

27、t easier to achieve interoperability between implementations. At present there is only one defined profile (Basic Target Pull); however, as new user and technical requirements are identified, additional profiles will be produced. Each profile specification will have its own document. The specificati

28、on also normatively references an “Administrative Register” document on the SMPTE Registration Authority website. This contains a list of transfer protocols that have defined names with MDP (for instance “HTTP”). This will be updated as required to incorporate new protocols without the need to issue

29、 a new version of a specification document. The MDP document suite makes reference to several non-SMPTE standards. Unlike many SMPTE specifications, the majority of these are from the Internet and Web community. Many are “Request For Comment” documents (RFCs) from the Internet Engineering Task Force

30、 (IETF)”, or from the World Wide Web Consortium (W3C). A Bibliography for the document suite appears in the protocol specification. To improve the clarity in all parts of the MDP document suite, text in this typeface is used to indicate the names or values of messages and data structures used in the

31、 protocol. 3 What Problem Does MDP Address? The use of data files to represent audio and video content has revolutionized the television industry. For example, almost all editing occurs using non-linear systems, and most playout occurs from disk-based servers. However, at the time of writing (early

32、2007) transfer of content as files has so far largely been confined to scenarios where the content formats and transfer protocols can be carefully controlled. In particular, delivery between different organizations, or different departments of the same organization, still often occurs through the us

33、e of physical media such as videotapes, or via SDI and video lines. As the cost of metropolitan- and wide-area connectivity falls, we can expect the demand to increase for file-based media delivery over IP-based networks. Examples include delivery of content between production facilities and broadca

34、sters, and provision of agency news feeds. The success of such an approach depends on the availability of fit-for-purpose network interconnectivity, but it also depends on the systems at either end understanding one another. While the simple transfer of a file is a trivial problem (FTP is available

35、on almost every platform), this only provides part of what is required. To avoid the need for manual intervention during every delivery, we need a mechanism to automatically initiate, supervise and audit the transfers. In addition because there are so many different transfer protocols in existence,

36、and so many ways of configuring a transfer, the systems need to agree just what is going to happen. There are on the market various proprietary file delivery solutions that solve these problems. However, differing systems do not interoperate, which in practice means that an organization wishing to e

37、xchange EG 2032-4-2007 Page 7 of 35 pages content with multiple partners needs to deploy multiple systems. In many cases this would be unacceptable, and a standardized approach is needed. MDP provides part of such a standardized approach. In particular it provides a mechanism to allow organizations

38、to agree on the details of a delivery (what files are to be sent, when transfer will occur, what transfer protocol will be used), to manage its lifecycle, and to exchange information about its progress. MDP was initially developed by a working group of the Professional MPEG Forum that investigated r

39、equirements and technologies for the exchange of large media files over IP networks. File delivery within the post-production community was seen as an important use case, and Annex A provides a summary of the relevant requirements identified by the group in this area. MDP was therefore initially dev

40、eloped to be suitable for file transfer within the post-production community. However, it contains no features that tie it to such applications, and is suitable for use in other scenarios, for instance delivery of finished programs to playout centers. In fact, MDP is not specific to media files and

41、could be used in any scenario requiring the transfer or large files between organizations. 4 How Does MDP Relate to? As MDP is in some ways an “invisible technology” it is helpful to clarify how it relates to other technologies. 4.1 Applications A production or other media organization typically cre

42、ates, manages and processes files using a selection of applications such as non-linear editing systems, media asset management systems and transcoding engines. Sometimes these applications will need to exchange these files with applications belonging to other organizations. Because there are a wide

43、range of possible mechanisms for performing these exchanges, it makes sense if these are not implemented in the applications themselves, and instead the tasks are delegated to specialized software agents. Then, as new transfer protocols, or other technologies, are adopted, it is not necessary to cha

44、nge the code within the applications themselves. As discussed in section 5, MDP provides a standard way for such agents to communicate. 4.2 Transfer Protocols MDP is not a transfer protocol. Instead it carries information about what transfer protocol might be, or is being used. To ensure interoperab

45、ility the standard requires all implementations to support HTTP and HTTPS, but allows the use of other protocols. Although MDP was developed for deliveries over metropolitan- and wide-area networks, it can also be used with protocols more suitable for local-area networks, for example copying of file

46、s from a shared network file system such as NFS. 4.3 File Formats Although MDP provides a logical grouping of files that are involved in the same delivery, it is not a file wrapper or container format like MXF (SMPTE 377M). It is expected that delivery of MXF files will be an important use of MDP, b

47、ut the protocol makes no assumptions or requirements of the type of files transferred (they do not even have to be related to audio or video). 4.4 Security Technologies Often it will be necessary to deliver files over public networks such as the Internet. MDP does not in itself ensure that deliverie

48、s are secured, but allows security technologies such as TLS (Transport Layer Security) to EG 2032-4-2007 Page 8 of 35 pages be used, and enables implementations to exchange information about what security measures are supported before starting the transfers. 4.5 Metadata MDP is not a metadata protoc

49、ol, and it has no defined relationship with any metadata standard or recommended practice (e.g. SMPTE RP 210). MDP can be used to transfer files containing metadata, e.g. within an MXF file or in a separate XML file. The standard forbids the carriage of “dark metadata” within the protocol; this is discussed further in section 9. 4.6 Web Services “Web service” simply means any software system that supports interoperable machine-to-machine interaction over a network. Therefore MDP implementatio