ImageVerifierCode 换一换
格式:PDF , 页数:44 ,大小:749.79KB ,
资源ID:1046644      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-1046644.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(SMPTE ST 2021-1-2015 Broadcast Exchange Format (BXF) - Requirements and Informative Notes.pdf)为本站会员(appealoxygen216)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

SMPTE ST 2021-1-2015 Broadcast Exchange Format (BXF) - Requirements and Informative Notes.pdf

1、 _ SMPTE ST 2021-1:2015 Revision of SMPTE ST 2021-1:2012 SMPTE STANDARD Broadcast Exchange Format (BXF) Requirements and Informative Notes _ Copyright 2015 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10607 (914) 761-1100 Approved October 9, 2015 SMPTE

2、ST 2021-1:2015 Page 2 SMPTE 2015 All rights reserved Table of Contents Foreword . 3 Intellectual Property . 3 Introduction 3 Background . 3 1 Scope . 6 2 Conformance Notation . 6 3 Document Elements . 7 4 Normative References 7 5 Definitions . 9 6 System Data Flow (Informative) . 18 7 System Securit

3、y (Informative) . 20 8 Configuration (Informative) . 20 8.1 Configuration Procedure 22 8.2 Configuration Non-schema Settings 22 9 Bibliography (Informative) 23 10 Notes (Informative) 24 10.1 Design Considerations 24 10.2 Schema . 24 10.3 Overview of Transactions 27 10.4 Message Lifecycles . 29 10.4.

4、1 BXF Request Message Lifecycle 29 10.4.2 Information Message . 31 10.4.3 Heartbeat Message . 32 10.4.4 Message Status Request 33 10.5 Message Processing . 33 10.5.1 Acknowledgement Messages . 33 10.5.2 Heartbeat Messages . 34 10.6 Primary Message Attributes 34 10.6.1 messageType Attribute . 34 10.6

5、2 status Attribute 35 10.6.3 action Attribute 36 10.6.4 error Attribute 36 10.6.5 errorDescription Attribute 37 10.7 Actions in Messages 37 10.7.1 Action Examples (Valid) . 38 10.8 Error Handling 41 10.8.1 Error Handling Responsibilities . 41 10.8.2 Error Handling Examples 41 10.9 Query Syntax 42 1

6、0.9.1 Syntax: 42 10.9.2 Symbol Definition and Semantics: 42 10.9.3 Reference Examples . 43 SMPTE ST 2021-1:2015 SMPTE 2015 All rights reserved Page 3 Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquarte

7、red 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. Participation in these Committees is open

8、 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 SMPTE ST 2021-1 was prepared by Technolog

9、y 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 Standard. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent righ

10、ts. 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 Broadcast Exchange Format (BXF) is a protocol for exchange of data among broadcast systems such as

11、Traffic, Program Management, Automation, and Content Distribution. It is intended to facilitate the movement of content and its associated metadata for better management, coordination and reporting between these broadcast systems. The BXF Protocol serves as a replacement for the many proprietary int

12、erfaces in place today between vendors in these areas. SMPTE 2021 (BXF) is broken into several parts. A brief outline of the parts can be found in SMPTE 2021-0, the Document Roadmap to this suite of documents. Background To understand the scope of BXF, a little background is helpful. The genesis of

13、BXF can be traced to the need for a consistent yet flexible means for exchanging schedule, as run, and content metadata between Traffic and Automation systems. Literally hundreds of proprietary, fixed interfaces and protocols have been created over the past 20 years or so between these two types of

14、systems. Vendors who create and develop these systems were invited to share ideas in search of a better way to facilitate the exchange of data between systems. The group quickly embraced Content Distribution and Program Management vendors as well, as they too were seeking a form of standardization a

15、nd improvement in their interfacing efforts. BXF supports the exchange of single or multiple records at one time, over a variety of transport mechanisms. While endeavoring to be a comprehensive protocol, it is acknowledged that it is possible that additional data elements, or data elements that appl

16、y to a few specific systems, may need to be exchanged. For this reason, Private Information structures have been placed at various points in the schema to allow vendors the flexibility to add data elements. SMPTE ST 2021-1:2015 Page 4 SMPTE 2015 All rights reserved It is expected that BXF could be e

17、xtended in the future, as warranted, and it has been designed with this in mind. BXF is intended to complement, not replace, the following: Advanced Authoring Format Material eXchange Format MDP Media Dispatch Protocol It is acknowledged that some may see an area of overlap in BXFs ability to reques

18、t the movement of content with other standards, such as MDP. However, MDP itself does not include support for these specific requests. Instead, BXF incorporates aspects of several pre-existing standards into its schema, such as: Programming Metadata Communication Protocol (ATSC) International Standa

19、rd Audiovisual Number (ISO) Ad-ID (AAAA/ANA) SMPTE ST 2021-1:2015 SMPTE 2015 All rights reserved Page 5 The following figure illustrates the scope of BXF within a broadcast facility. Those areas outside of the BXF box are considered outside the intended scope of the BXF protocol and this document. F

20、igure 1 Scope of BXF SMPTE ST 2021-1:2015 Page 6 SMPTE 2015 All rights reserved Broasdcast Exchange Format (BXF) 1 Scope The Broadcast eXchange Format (BXF) defines the format and content of XML Messages for the interchange of data and metadata among professional systems, as follows: 1. Broadcast sc

21、hedules, including playout and record schedules 2. As run information 3. Content metadata, such as Content ID, Title, Duration, etc. 4. Content management requests such as dub and purge requests 5. Requests for transfer of content some of which will result in the transfer of Content essence between

22、professional systems. 6. Ports as used by TCP/IP for the exchange of messages The primary systems envisioned as users of this standard are: Program Management Systems Broadcast Traffic Systems Master Control Automation Systems Content Distribution Systems This document serves as the master document

23、for the 2021 suite (thus its Part 1 designation). It includes general BXF details as well as informative notes. SMPTE OV 2021-0 provides a Roadmap for the 2021 Document Suite Unless otherwise specified the order of precedence of the types of normative information in this document shall be as follows

24、 Normative prose shall be the authoritative definition. Tables shall be next, followed by formal languages, then figures, and then any other language forms. In the event of a conflict between the schema and other information in this document, the schema is authoritative. 2 Conformance Notation Docu

25、ments consist of normative text and, optionally, informative text. Normative text is that describes elements of the design that are indispensable or contains the conformance language keywords: “shall“, “should“, or “may“. Informative text is text that is potentially helpful to the user, but not indi

26、spensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords. All text in a Standard, Recommended Practice, Amendment, Addendum, or Corrigendum, is, by default, normative, except: the Introduction, any sec

27、tion explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” Normative references are external documents referenced in normative text that are indispensable to the user. Bibliographic references are references made in informative text or are those otherwise not indispens

28、able to the user. Normative references shall conform to the types and procedures specified in the Engineering Administrative Practices. 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

29、 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 possibility or

30、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. SMPTE ST 2021-1:2015 SMPTE 2015 All rights reserved Page 7 The keyword “reserved” indicates a provision that is not defined at this time, sha

31、ll not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future. A conformant implementation according to an Engineering Document is one that includes all mandatory provisions (“shall“) an

32、d, if implemented, all recommended provisions (“should“) as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. 3 Document Elements This document is comprised of the following elements, which form an integral piece of this S

33、tandard. Additionally, the schema files may be found at http:/smpte-ra.org/schemas/2021/2015/BXF. (Accessible only by appropriately-designed software applications, for schema validation. Not intended to be human-accessible.) a) Prose document st2021-1-2015.pdf (this file) Normative b) XML schema st2

34、021-2021-1a-2015.xml Normative c) HTML schema guide st2021-1b-2015.html Informative 4 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 stan

35、dards 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. XML Schema Part 1: Structures Second Edition, W3C Recommendation 28 October 2004, http:/www.w3.org/TR/20

36、04/REC-xmlschema-1-20041028/ XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 October 2004, http:/www.w3.org/TR/2004/REC-xmlschema-2-20041028/ Extensible Markup Language (XML) 1.0 (Second Edition) W3C Recommendation, 6 October 2000, http:/www.w3.org/TR/2000/REC-xml-20001006 XML Sch

37、ema, W3C Recommendation, 2 May 2001, http:/www.w3.org/TR/2001/REC-xmlschema-0-20010502 A/76B “Programming Metadata Communication Protocol, Revision B”, Advanced Television Systems Committee, Washington, DC, January, 2008 “XML Path Language”, W3C Recommendation 16 November 1999, http:/www.w3.org/TR/1

38、999/REC-xpath-19991116 ISO 15706-2:2007, Information and Documentation International Standard Audiovisual Number (ISAN) Part 2: Version Identifier SMPTE ST 258:2004, Transfer of Edit Decision Lists, Society of Motion Picture and Television Engineers, April 21, 2004. A Universally Unique IDentifier (

39、UUID) URN Namespace P. Leach, M. Mealling, R. Salz, 2005 IETF RFC4122 http:/www.ietf.org/rfc/rfc4122.txt SMPTE ST 2021-1:2015 Page 8 SMPTE 2015 All rights reserved IETF RFC3986 - Uniform Resource Identifiers (URI): Generic Syntax T. Berners-Lee, et al. The Internet Society, 2005. http:/www.ietf.org/

40、rfc/rfc3986.txt IETF RFC3066 - Tags for the Identification of Languages, H. Alvestrand, The Internet Society, 2001 http:/www.ietf.org/rfc/rfc3066.txt MPEG-2 ISO/IEC 13818-2:2000, Information technology Generic Coding of Moving Pictures and Associated Audio Information: Video A/65C, “Program and Syst

41、em Information Protocol for Terrestrial Broadcast and Cable, Revision C, with Amendment No. 1”, Advanced Television Systems Committee, Washington, DC, 9 May 2006 CEA-708-D, Digital Television (DTV) Closed Captioning, Consumer Electronics Association SMPTE ST 2021-1:2015 SMPTE 2015 All rights reserve

42、d Page 9 5 Definitions The following definitions apply within the BXF protocol standard. Word Element/Attribute Name Definition Advertiser Name AdvertiserName Time in a broadcast schedule may be sold to a third party for the purpose of advertising products, goods, or services. These are commonly ref

43、erred to as commercials, and the third party that purchased the time for the commercial is an Advertiser. Agency Agency The entity that manages placement of commercials, and in some cases the production of commercials Alternate Audio Content AlternateAudioContent If audio that is not directly associ

44、ated with the primary video content is scheduled to run with the primary video, a separate piece of content for just this audio must be indicated. This includes audio that may be provided for the purpose of accessibility issues. As Run (Schedule) AsRun CompleteAsRun BasicAsRun A term typically apply

45、ing to broadcast playout schedules referring to the exact events that aired during a specific period of time, usually a broadcast day and also includes errors concerning scheduled content that did not air or was aired improperly. Asset Server AssetServer Asset server is a term that describes a serve

46、r where commercial and program content is stored. Authorization List AuthorizationList For cable operations a list of cable headend locations that are authorized to present specific commercial content. Avail Number AvailNumber A count of the number of format positions that are allowed to contain com

47、mercial content. Billing Reference Code BillingReferenceCode A unique reference code for each billable event that typically links back to the system that created the event, and is used in the reconciliation of the as run against the schedule. Channel Channel A definition used to describe the means b

48、y which a schedule is broadcast. SMPTE ST 2021-1:2015 Page 10 SMPTE 2015 All rights reserved Configuration Configuration There are several schema elements that are not specifically enumerated in the schema and must be configured between the two systems before the elements can be used. Constraints Constraints A set of rules that restricts the placement of commercial content on a schedule. Content Content Content may contain multiple essence types, (e.g. audio, video, etc.) Content Metadata ContentMetaData Information concerning a specific piece of content Content Play Number ContentPlayNumb

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1