12.07.2015 Views

ENGINEERING COMMITTEE Digital Video Subcommittee SCTE 118 ...

ENGINEERING COMMITTEE Digital Video Subcommittee SCTE 118 ...

ENGINEERING COMMITTEE Digital Video Subcommittee SCTE 118 ...

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>ENGINEERING</strong> <strong>COMMITTEE</strong><strong>Digital</strong> <strong>Video</strong> <strong>Subcommittee</strong><strong>SCTE</strong> <strong>118</strong>-2 2012Program-Specific Ad Insertion -Content Provider to Traffic Communication ApplicationsData Model


NOTICEThe Society of Cable Telecommunications Engineers (<strong>SCTE</strong>) Standards are intended to serve thepublic interest by providing specifications, test methods and procedures that promote uniformityof product, interchangeability and ultimately the long term reliability of broadbandcommunications facilities. These documents shall not in any way preclude any member or nonmemberof <strong>SCTE</strong> from manufacturing or selling products not conforming to such documents, norshall the existence of such standards preclude their voluntary use by those other than <strong>SCTE</strong>members, whether used domestically or internationally.<strong>SCTE</strong> assumes no obligations or liability whatsoever to any party who may adopt the Standards.Such adopting party assumes all risks associated with adoption of these Standards, and acceptsfull responsibility for any damage and/or claims arising from the adoption of such Standards.Attention is called to the possibility that implementation of this standard may require the use ofsubject matter covered by patent rights. By publication of this standard, no position is taken withrespect to the existence or validity of any patent rights in connection therewith. <strong>SCTE</strong> shall notbe responsible for identifying patents for which a license may be required or for conductinginquiries into the legal validity or scope of those patents that are brought to its attention.Patent holders who believe that they hold patents which are essential to the implementation ofthis standard have been requested to provide information about those patents and any relatedlicensing terms and conditions. Any such declarations made before or after publication of thisdocument are available on the <strong>SCTE</strong> web site at http://www.scte.org.All Rights Reserved© Society of Cable Telecommunications Engineers, Inc. 2007140 Philips RoadExton, PA 19341i


TABLE OF CONTENTS1.0 SCOPE ..................................................................................................................12.0 NORMATIVE REFERENCES ............................................................................13.0 INFORMATIVE REFERENCES .........................................................................24.0 COMPLIANCE NOTATION ...............................................................................35.0 DEFINITIONS AND ACRONYMS ....................................................................36.0 DATA MODEL OF CONTENT PROVIDER TO THE AFFILIATE TRAFFICSYSTEM COMMUNICATIONS .........................................................................57.0 CONDITIONAL AVAIL METHODS .................................................................78.0 ADOPTION OF SMPTE 2021 .............................................................................99.0 APPENDIX A – SAMPLE BXF XML ENCODING OF PROGRAMSCHEDULES (INFORMATIVE) ......................................................................13ii


1.0 SCOPEThis document describes the information that is required to communicate the program andavail structure from a Network to an Affiliate’s <strong>SCTE</strong> 35[1] compliant Traffic System.Additionally, this document describes the information required to comply with the Tier 0,Tier 1 and Tier 2 Program-Specific Ad Insertion models as defined by <strong>SCTE</strong> <strong>118</strong>-1[2].This document does not specify the source of the data that is required by the Traffic system.This data may be provided by the Content Provider (Network) or by a 3rd party (such as anetwork schedule aggregator, etc.). The data may be provided in its entirety, or a subset ofthe data may be provided and then manually supplemented.2.0 NORMATIVE REFERENCESThe following documents contain provisions, which, through reference in this text,constitute provisions of this standard. At the time of subcommittee approval, the editionsindicated were valid. All standards are subject to revision, and parties to agreement basedon this standard are encouraged to investigate the possibility of applying the most recenteditions of the documents listed below.[1] <strong>SCTE</strong> 35 2012– <strong>Digital</strong> Program Insertion Cueing Message for Cable[2] <strong>SCTE</strong> <strong>118</strong>-1 2012 – Program-Specific Ad Insertion - Data Field Definitions,Functional Overview and Application Guidelines.[3] SMPTE 2021-2-2009 – Broadcast Exchange Format (BXF)[4] A/65: “Program and System Information Protocol for Terrestrial Broadcast andCable (PSIP)”, Advanced Television Systems Committee, Washington, DC, 14April 2009[5] A/76B: “Programming Metadata Communication Protocol Standard, Revision B”,Advanced Television Systems Committee, Washington, DC, 14 January 2008[6] ISO 15706-2:2007 – Information and Documentation - International StandardAudiovisual Number (ISAN) – Part 2: Version Identifier[7] ISO 8601 2004 - Data elements and interchange formats -- Information interchange-- Representation of dates and times Move to 2.2 or change to non-segmented – getupdated template[8] W3C Recommendation, “Extensible Markup Language (XML) 1.0 (FourthEdition)”, Tim Bray, et al, 16 August 2006[9] W3C Recommendation, “Namespaces In XML (Second Edition)”, Tim Bray, et al,16 August 20061


[10] W3C Recommendation, “XML Schema Part 1: Structures (Second Edition)”, H.Thompson, et al, 28 October 2004[11] W3C Recommendation, “XML Schema Part 2: Datatypes (Second Edition)”, P.Biron, et al, 28 October 20043.0 INFORMATIVE REFERENCESThe following documents may provide valuable information to the reader but are notrequired when complying with this standard.[12] <strong>SCTE</strong> <strong>118</strong>-3 2012 – Program-Specific Ad Insertion – Traffic System to AdInsertion System File Format Specification.[13] <strong>SCTE</strong> 67 2010 – Recommended Practice for <strong>SCTE</strong> 35 <strong>Digital</strong> Program InsertionCueing Message for Cable[14] SMPTE ST 2021-0:2009 – Broadcast Exchange Format — Roadmap for the 2021Document Suite[15] SMPTE ST 2021-1:2009 – Broadcast Exchange Format (BXF) — GeneralInformation and Informative Notes2


4.0 COMPLIANCE NOTATION“SHALL” This word or the adjective “REQUIRED” means that the item is anabsolute requirement of this specification.“SHALL NOT” This phrase means that the item is an absolute prohibition of thisspecification.“SHOULD” This word or the adjective “RECOMMENDED” means that there mayexist valid reasons in particular circumstances to ignore this item, butthe full implications should be understood and the case carefullyweighted before choosing a different course.“SHOULD NOT” This phrase means that there may exist valid reasons in particularcircumstances when the listed behavior is acceptable or even useful,but the full implications should be understood and the case carefullyweighed before implementing any behavior described with this label.“MAY” This word or the adjective “OPTIONAL” means that this item is trulyoptional. One vendor may choose to include the item because aparticular marketplace requires it or because it enhances the product,for example; another vendor may omit the same item.5.0 DEFINITIONS AND ACRONYMSThe following terms and acronyms are used in this document:Ad Insertion A complete hardware and software solution that interprets theSystemschedule file, streams content when triggered based on theschedule file, logs insertion results, and returns a verification fileto the Traffic & Billing system.AvailAn avail is an opportunity provided by the network to a localaffiliate to insert a commercial event into a program. The start ofan avail is indicated as a splice event in the programming stream.The duration of the avail may vary from a few seconds to severalminutes. (<strong>SCTE</strong> 67[13])BreakA break is an opportunity for local insertion to occur within abroadcast program. In a sales context, a break is divided intosellable units of time (avails). In an insertion context, a break isdivisible into individual insertion events (slots).Broadcast Day The 24-hour period which is logically thought of as a day for abroadcaster or affiliate. When it does not align with a calendarday, it will typically begin in the early morning and span acrossmidnight.Business Day For the affiliate’s traffic and billing system, this is the calendardate that contains the start of the Broadcast Day.BXFBroadcast Exchange Format standard as defined in SMPTE2021[3]Calendar Day The actual, Gregorian calendar day on which an event takes place.A broadcaster or affiliate may define their broadcast day asrepresenting events that span 2 separate calendar days.3


Cue MessageEnhanced FileEvent-BasedFormatNetworkSchedule FileService Level<strong>SCTE</strong>Simple FileSlotSMPTESpotTierTime Based FormatTraffic SystemTraffic & Billing(T&B) SystemUniqueUnique ProgramIdentifierISANA <strong>SCTE</strong> 35 [1]splice_info_section identifying an opportunity toleave or return to the network program stream.A <strong>SCTE</strong> <strong>118</strong>-2 XML file provided by the content provider(Network) which communicates programming and availinformation containing metadata in the optional “SL” fieldassociated with the avail detailing which Service Level(s) itbelongs to. Service level variations are expressed in the XMLschema as AuthorizedNames and AuthorizationLists.Defined by setting up a window time and assigning avails thatfloat within that window.A cable, satellite, or digital terrestrial content delivery networksuch as CNN, ESPN, etc. It can also include an MSO’s locallyoriginated programming.An XML file that lists all the spots and times that the spots are toplay for a particular network and zone.An agreement between the content provider (Network) and a MSOthat outlines the number of avails to be provided and expected. Anetwork can have different arrangements with different MSOs.Society of Cable Telecommunications EngineersA <strong>SCTE</strong> <strong>118</strong>-2 XML file provided by the content provider(Network) that communicates programming and avail informationthat contains no metadata in the optional “SL” field associatedwith the avail.A slot is a segment of time within a break into which a spot can bescheduled.Society of Motion Picture and Television EngineersA single, schedulable and verifiable, piece of video and audiocontent within a break.A measure of system and data support with regards to Program-Specific Ad Insertion, as defined by <strong>SCTE</strong> <strong>118</strong>-1[2].A time-based format assigns each break an exact time that a cuemessage is to be expected and then allows for a buffer around it.Shorthand for Traffic & Billing System.A system that processes client orders, creates schedule files,processes verification files, and produces invoices.Within the scope of this document, the definition of ‘unique’follows <strong>SCTE</strong> 67[13], section 5.8’s definition of unique and itsusage.A bitfield in this file format specification that is equivalent to theunique_program_id field in <strong>SCTE</strong> 35[1].ISAN is an acronym for International Standard Audio/VisualNumber [6]. This is a globally-unique identifier used forreferencing a specific version of a completed audio/visual work aswell as its finished components.4


Verification FileWindowWindow-BasedZoneXMLAn XML file generated by the Ad Insertion System that lists all ofthe spots that successfully played and failed to play, for aparticular network and zone.A time range, defined by the schedule file, when a cue message isexpected.A type of avail. Insertion will be triggered by a cue receivedwithin a specified time range and not by a Program ID. Window-Based avails can be scheduled as time or event based format.A geographic sales region.Extensible Markup Language6.0 DATA MODEL OF CONTENT PROVIDER TO THE AFFILIATE TRAFFICSYSTEM COMMUNICATIONS6.1 Tier 0 RequirementsTier 0 insertion is non-Program-Specific Ad Insertion using <strong>SCTE</strong> 35 Cue Messages.To support Tier 0 insertion, the following data elements shall be provided in theschedule data.Required DataNotes / ExamplesScheduled Program Date & Calendar Date and Time on which the programTimebegins.Scheduled Program Duration Expected duration in hours, minutes andseconds.Program NameLarry King Live, ESPN Sports Center, etc.Table 6-1 – Tier 0 Required Data Elements6.2 Tier 1 RequirementsTier 1 insertion is Program-Specific Ad Insertion using <strong>SCTE</strong> 35[1] Cue Messages,but does not require matching the avail_num or avails_expected fields of <strong>SCTE</strong>35[1]. To support Tier 1 insertion, in addition to the Tier 0 fields above, the followingadditional data element shall be provided in the schedule data.Required DataUnique Program Identifier(<strong>SCTE</strong> 35[1] unique_program_idfield)6.3 Tier 2 RequirementsNotesThe Unique Program Identifier of the programthat is scheduled to air.Table 6-2 – Tier 1 Required Data ElementsTier 2 insertion is Program-Specific Ad Insertion using <strong>SCTE</strong> 35[1] Cue Messagesrequiring matching the avail_num and avails_expected fields in <strong>SCTE</strong> 35[1]messages. To support Tier 2 insertion, in addition to the Tier 0 & Tier 1 fields above,the following data elements shall be provided in the schedule data.5


Required DataNotesAvail NumberThe current avail opportunity to which the cue(<strong>SCTE</strong> 35[1] avail_num field) message refers for a given unique_program_id.Avails ExpectedTogether with the Avail Number, this announces(<strong>SCTE</strong> 35[1] avails_expected the anticipated avails for a particular program.field)Table 6-3 – Tier 2 Required Data ElementsA Network shall communicate all data elements required for Tier 2 support in the CueMessages that will exist in the data stream for the Program. Due to the TieredInsertion behavior logic (see <strong>SCTE</strong> <strong>118</strong>-1[2], section 6.3), if an Ad Insertion systemrecognizes a cue message containing Tier 1 or Tier 2 data elements, it will attempt toinsert any open window, non-Program-Specific ad content. A Network may preventinsertions associated with Cue Messages not intended for a particular Affiliatethrough the use of the AuthorizedName (see Section 6.4). If a Network is using Tier1 behavior, there is no way to prevent or direct an Affiliate to ignore a particular CueMessage.6.4 Optional Data ItemsThe following are additional items that may appear for each program. Optional itemsmay be used in implementations of any tier.Optional DataAuthorizedNameAuthorizationListAvail Date & TimeAvail Time TolerancesAvail DurationProgram TypeProgram DescriptionEpisode InformationISAN IdentifierNotesA unique identifier for a Service Levelcovering one or more Cable Operators that allshare the same contractual agreement forauthorized avails.A list of AuthorizedName(s)Anticipated Time (within the Program) for theavail.Specifies potential variation of the anticipatedavail time in minutes minus and minutes plus.Expected Avail duration.Live, Scheduled, Repeat, etc.Textual information describing the programTextual description or programmer definednumbering scheme to differentiate amongepisodes of a program series.ISAN is an acronym for International StandardAudio/Visual Number. This is a uniqueidentifier of the content as defined by ISO15706-2:20076


Program GenreParental RatingTextual description of the type ofprogramming: i.e. Movie/Comedy, TalkShow/Political, etc.Standard rating as defined by A/65, Section6.9.3, Content Advisory Descriptor. See alsoA/76B, Programming MetadataCommunication Protocol, for a method ofcarrying the descriptor in an XML form.Table 6-4 – Optional Data Elements7.0 CONDITIONAL AVAIL METHODSContent Providers (Networks) frequently establish varying agreements with cableMSOs with respect to the number of local avails into which the MSO may insertadvertising. Based on these varying agreements, certain MSOs may be offered moreor less avails than others and/or the duration of specified avails may differ amongMSOs. This section describes methods for defining these conditional avails withvarying degrees of privacy among the participating parties.The following refers to the four Approaches illustrated in the seven / five availexample in <strong>SCTE</strong> 67 [13], Section 5.9.6, Table 5-1 and assumes a full <strong>SCTE</strong> <strong>118</strong>-1[2]Tier 2 implementation. The table is reprinted here as a service to the reader.Table 5-1 from <strong>SCTE</strong> 67 [13] – 5.9.6AVAIL Approach 1 Approach 2 Approach 3 Approach 41 1 of 7 1 of 5 1 of 7 1 of 72 2 of 7 2 of 5 2 of 7 2 of 73 3 of 7 ---- ---- (3 of 7) rcvd but not scheduled4 4 of 7 3 of 5 4 of 7 4 of 75 5 of 7 ---- ---- (5 of 7) rcvd but not scheduled6 6 of 7 4 of 5 6 of 7 6 of 77 7 of 7 5 of 5 7 of 7 7 of 7Programmers may execute the above approaches using several different methods. Themethod selected by the content provider will be based on the followingconsiderations:1. the number of “service level” agreements it has with MSOs if different“service levels” are provided,2. its desire to maintain privacy of their different deals with each MSO.3. its ability / desire to generate a single or separate <strong>118</strong>-2 schedule file for each“service level”7


4. its ability / desire to generate a separate or encrypted <strong>SCTE</strong>-35 messagestream for each provided “service level”Service Level MethodsMethod 1 Method 2 Method 3 Method 4<strong>118</strong>-2 1 Simple n Simple 1 Enhanced 1 Enhanced<strong>SCTE</strong> 35 Streams 1 n n 1Avail Privacy N/A Yes No NoTable 7-1 – Communication Method MatrixMethod 1A programmer choosing to offer only one Service Level would deliver the same availinformation via a single Simple File for distribution to all MSOs (timing of delivery /pickup of these files needs to be determined). Correspondingly, only one stream of<strong>SCTE</strong> 35 cue messages would be needed to support the single Service Level acrossthe marketplace. This is illustrated by Approach 1 in <strong>SCTE</strong> 67[13] Table 5-1 includedabove for reference.Method 2A programmer offering more than one Service Level and having the capacity togenerate unique Simple Files and unique <strong>SCTE</strong> 35[1] cue messages per service levelcould utilize Method 1 for each service level variant, i.e. produce a separate SimpleFile and a corresponding <strong>SCTE</strong> 35[1] cue message stream for each variant.To implement this method a programmer would generate <strong>SCTE</strong> <strong>118</strong>-2 files and <strong>SCTE</strong>35[1] cue messages illustrated by Approach 1 for the MSOs with the seven availService Level and <strong>SCTE</strong> <strong>118</strong>-2 files and <strong>SCTE</strong> 35[1] cue messages illustrated byApproach 2 for the MSOs with the five avail Service Level.This is perhaps the cleanest method when multiple service level contracts are offeredbecause the communication of avails is handled separately from end to end andallows for avail privacy if desired.Method 3A programmer offering more than one type of service agreement may instead opt todistribute a single version of the <strong>SCTE</strong> <strong>118</strong>-2 schedule file enhanced with availallocation metadata to all MSOs. With this method, all seven avails would be listed inthe Enhanced File and each avail would contain an AuthorizationList identifying theeligible service levels of that avail.Separate or encrypted <strong>SCTE</strong> 35[1] cue message streams would then need to begenerated for each type of Service Level, exposing only the avails appropriate for the8


targeted MSO, much like Approach 3. Because all avails are revealed in the singleEnhanced File, avail privacy is forfeited with this method. However, it does spareprogrammers the burden of producing multiple Simple Files.Method 4Programmers that may not have the means or desire to generate separate or encrypted<strong>SCTE</strong> 35[1] cue message streams but wish to support multiple MSO Service Levelscould produce a single version of the Enhanced File coupled with a single <strong>SCTE</strong>35[1] cue message stream. As all the cue messages are visible, MSOs would betrusted to schedule only the avails identified by the AuthorizationList correspondingwith their service level agreements.With this method, there is full avail disclosure via the Enhanced File and the honorsystem is in effect for avail usage by the MSO. However, there is no need for multipleor encrypted <strong>SCTE</strong> 35[1] cue message streams.8.0 ADOPTION OF SMPTE 20218.1 ObjectivesAll required and optional data elements of this standard are accommodated within theSMPTE 2021[3] BXF protocol and its associated XML schema for encoding ofContent Provider to Affiliate Traffic System program schedules. Since the BXFprotocol covers extensive data beyond the scope of this standard, this standard shallbe based on a mapping of required and optional data defined in section 6.0 above toBXF XML data elements as defined in section 8.2 below.8.2 Mapping of Data ElementsThe following table defines the mapping of data elements, required for each tier ofthis standard, to the BXF protocol as defined in SMPTE 2021[3]. Appendix Aprovides examples of <strong>SCTE</strong> <strong>118</strong>-2 program schedules encoded using BXF XML.<strong>SCTE</strong> <strong>118</strong>-2 DataElementTiers SMPTE 2021 Data Element (Root)BxfMessage/BxfData/Schedule/ScheduledEvent/…Scheduled ProgramDate & Time0,1,2 EventData/StartDateTime with @eventTypeset to “Primary-ProgramHeader”Scheduled ProgramDuration0,1,2 LengthOption/Duration with @eventType setto “Primary-ProgramHeader”Program Name 0,1,2 EventData/PrimaryEvent/ProgramEvent/ProgramName where @eventType = “Primary-ProgramHeader”Unique ProgramIdentifier1,2 Content/ContentId/AlternateId, with @IdTypeset to “Unique Program Identifier”9


<strong>SCTE</strong> <strong>118</strong>-2 DataElementTiers SMPTE 2021 Data Element (Root)BxfMessage/BxfData/Schedule/ScheduledEvent/…Avail Number 2 Format/Formats/FormatStructure/FormatElements/AvailNumberAvails Expected 2 Format/Formats/FormatStructure/FormatElements/TotalAvailsAuthorizationList &AuthorizedName2 Format/Formats/FormatStructure/FormatElements/AuthorizationListFormat/Formats/FormatStructure/FormatElements/AuthorizedNameAvail Date & Time 0,1,2 EventData/StartDateTime with @eventTypeAvail Time Tolerances 0,1,2set to “Primary-BreakHeader”Format/Formats/FormatStructure/FormatElements/PrimaryOffset with @minusWindow and@plusWindow – note these are not definedattributes in the schema, but are allowed usingthe “any” attribute.Program Type Optional ContentTypeProgram Description Optional Content/DescriptionContent/NameEpisode Information Optional Series/SeriesNameSeries/EpisodeNameSeries/EpisodeCodeISAN Identifier Optional Content/ContentId/IsanProgram Genre Optional Content/GenreTV Rating Optional ParentalRating/Rating with @region set to 1(US)Table 8-1 – Mapping of Data Elements to SMPTE 20218.3 Common Schedule Examples (INFORMATIVE)This section describes four typical examples of schedule constructs addressed by thisstandard. In all cases these exchanges are from a program originator or designatedproxy directed to a cable MSO’s traffic system. An outline of the BXF XML mappingfor each example is included with the BXF XML elements in bold and briefexplanations of the elements employed. In all cases these data are contained withinthe element of BXF XML and each program isdefined within a element and its subordinate elements.A detailed BXF XML encoding sample addressing the salient aspects of thesescenarios is also included in Appendix A – Sample BXF XML Encoding of ProgramSchedules.8.3.1 Fixed Duration Program with Two Breaks10


In practice, the majority of program content is defined as a fixed durationprogram with a predefined number of breaks that are also of fixed duration.Such a program would be defined within a element asfollows:1. An element defining the , a and for the program.2. A element defining the program by ,, , and 3. A element giving the identifier of the format, defining the duration of the format and listing two records under the each with an identifier, and a type set to“Break” and with the first record the set to 1 and set to 2 and the second record with set to 2 and set to 2.8.3.2 Live Program with Four Fixed and Two Potential Extra BreaksLive programs frequently vary from the originally scheduled duration as in thecase of overtime play in a live sporting event. In this scenario it is useful todefine “extra” breaks that may be offered if the event goes over time. Such aprogram would be defined within a element as follows:1. An element defining the , a and for the program.2. A element defining the program by ,, , and 3. A element giving the identifier of the format,defining the duration of the format and declaring four TotalAvails inthe same manner as the first example under the.4. A element containing exactly six5. Four of type Break defining the details of eachfixed break by offset time within the format and duration.6. Two of type Break defining the details of eachextra break by anticipated offset time within the format and duration.In this case the offset times will be greater than the scheduled programduration and the avail numbers will exceed the avails expected.11


8.3.3 Conditional Number of Avails by Service LevelWhen multiple service level agreements are to be encoded within a single BXFXML schedule (see Section 7.0 – Method 3) the elementis employed. This element will be included for each break where the carriage isrestricted to MSOs by service level. Each service level is identified by a that directly corresponds to the contract specifying thecarriage details. The presence of an indicates that thebreak is conditional and only available to MSOs with matching. For example, consider a program with two breaks wherethe second break is conditional as follows:1. An element defining the , a and for the program.2. A element defining the program by ,, , and 3. A element giving the identifier of the format,defining the duration of the format and declaring two TotalAvails.4. A element containing exactly two5. A of type Break defining the details of the firstbreak by offset time within the format and duration. This break iscarried by all MSOs and, therefore, contains no .6. A of type Break defining the details of thesecond break by offset time within the format and duration. This breakis carried conditionally and, therefore, contains an with one or more elementscorresponding to the service level contract(s) providing those breaks.8.3.4 Conditional Duration of Avails by Service LevelIn some cases the variation among service levels may result in the same numberof breaks but differing durations. The also covers thisscenario as in the following example where the second of two breaks may belonger for some service level(s):1. An element defining the , a and for the program.2. A element defining the program by ,, , and 12


3. A element giving the identifier of the format, defining theduration of the format and declaring two TotalAvails.4. A element containing exactly three5. A of type Break defining the details of the firstbreak by offset time within the format and duration. This break is thesame duration for all MSOs and, therefore, contains no.6. A of type Break defining the details of thesecond break by offset time within the format and duration. This breakduration varies and, therefore, contains an withone or more elements corresponding to theservice level contract(s) for the specified duration.7. A of type Break defining the alternative detailsof the second break by offset time within the format and alternativeduration. This break duration varies and, therefore, contains an with one or more elementscorresponding to the service level contract(s) for the specified alternateduration.9.0 APPENDIX A – SAMPLE BXF XML ENCODING OF PROGRAM SCHEDULES(INFORMATIVE)The following example defines the live sporting event and fixed duration talk show asdescribed and illustrated in Section 8.3. Note that this is a fragment of a BXF XML fileand includes only the required header data and those elements relevant to <strong>SCTE</strong> <strong>118</strong>-2 todefine two programs and their avails. This sample is provided as an informative referenceonly. In the event of any conflict between this sample and the standard as defined inSMPTE 2021[3], the requirements of SMPTE 2021[3] are definitive.ESPN East Feedchannel desc13


urn:uuid:3A725992-7656-456e-94F6-6090DE940E0A1NBA Basketball17:00:00:0002:30:00:00FixedDuration07224NBA BasketballSport/NBA BasketballLA Lakers vs Detroit Pistonsurn:uuid:3A725992-7656-456e-94F6-6090DE940E0B02:30:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E0CBreak1700:15:00:0000:01:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E0DBreak2700:45:00:0000:01:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E0EBreak37Service Level Agreement ID-1Service Level Agreement ID-701:00:00:0000:01:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E0FBreak414


701:15:00:0000:01:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E10Break57Service Level Agreement ID-1Service Level Agreement ID-701:45:00:0000:01:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E11Break6702:00:00:0000:01:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E11Break7702:15:00:0000:01:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E12Break87Service Level Agreement ID-1Service Level Agreement ID-702:45:00:0000:01:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E12Break9703:15:00:0000:01:00:0015


urn:uuid:3A725992-7656-456e-94F6-6090DE940E11Sports Center19:30:00:0002:30:00:00FixedDuration07226Sports CenterTalk/SportBasketball wrap-upurn:uuid:3A725992-7656-456e-94F6-6090DE940E1401:00:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E15Break1200:25:00:0000:01:00:00urn:uuid:3A725992-7656-456e-94F6-6090DE940E16Break2200:55:00:0000:01:00:0016

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!