This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/main/jmc-storage/docs/SCTE/ANSI SCTE 035 Digital Program Insertion Cueing Message for Cable (2007)[2].pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- ENGINEERING COMMITTEE Digital Video Subcommittee AMERICAN NATIONAL STANDARD ANSI/SCTE 35 2007 Digital Program Insertion Cueing Message for Cable NOTICE The Society of Cable Telecommunications Engineers (SCTE) Standards are intended to serve the public interest by providing specifications, test methods and procedures that promote uniformity of product, interchangeability and ultimately the long term reliability of broadband communications facilities. These documents shall not in any way preclude any member or non-member of SCTE from manufacturing or selling products not conforming to such documents, nor shall the existence of such standards preclude their voluntary use by those other than SCTE members, whether used domestically or internationally. SCTE 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 accepts full 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 of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. SCTE shall not be responsible for identifying patents for which a license may be required or for conducting inquiries 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 of this standard have been requested to provide information about those patents and any related licensing terms and conditions. Any such declarations made before or after publication of this document are available on the SCTE web site at http://www.scte.org. All Rights Reserved © Society of Cable Telecommunications Engineers, Inc. 2007 140 Philips Road Exton, PA 19341 1 Contents 1  Scope ................................................................................................................................................... 5  2  References .......................................................................................................................................... 5  2.1  Normative references ................................................................................................................ 5  2.2  Informative References ............................................................................................................ 6  3  Definition of terms ............................................................................................................................. 6  4  Abbreviations ...................................................................................................................................... 9  5  Introduction...................................................................................................................................... 10  5.1  Splice points (Informative) ..................................................................................................... 10  5.2  Program Splice Points (Informative) .................................................................................... 10  5.3  Splice events (Informative)..................................................................................................... 11  5.4  Content Storage Considerations (Informative) ................................................................... 11  5.5  PID selection ............................................................................................................................ 12  5.5.1 PID Selection (Normative) ...................................................................................................... 12  5.5.2 PID Selection (Informative) ..................................................................................................... 12  5.6  Message flow (Informative) .................................................................................................... 13  6  PMT Descriptors .............................................................................................................................. 13  6.1  Registration Descriptor .......................................................................................................... 13  6.1.1 Semantic definition of fields in Registration Descriptor ......................................................... 14  6.2  Cue Identifier Descriptor ....................................................................................................... 14  6.2.1 Semantic definition of fields in Cue Identifier Descriptor....................................................... 15  6.2.2 Description of cue_stream_type usage .................................................................................... 15  6.3  Stream Identifier Descriptor .................................................................................................. 16  6.3.1 Semantic definition of fields in Stream Identifier Descriptor .................................................. 16  7  Splice Information Table ................................................................................................................. 16  7.1  Overview .................................................................................................................................. 16  7.1.1 Time Base Discontinuities ....................................................................................................... 18  7.2  Splice Info Section ................................................................................................................... 18  7.2.1 Semantic definition of fields in splice_info_section() ............................................................. 19  7.3  Splice Commands .................................................................................................................... 21  7.3.1 splice_null() ............................................................................................................................. 21  7.3.2 splice_schedule()...................................................................................................................... 21  7.3.3 splice_insert() ........................................................................................................................... 23  7.3.4 time_signal() ............................................................................................................................ 25  2 7.3.5 bandwidth_reservation() .......................................................................................................... 26  7.3.6 private_command() .................................................................................................................. 26  7.4  Time .......................................................................................................................................... 27  7.4.1 splice_time() ............................................................................................................................ 27  7.4.2 break_duration() ....................................................................................................................... 27  7.5  Constraints............................................................................................................................... 28  7.5.1 Constraints on splice_info_section()........................................................................................ 28  7.5.2 Constraints on the interpretation of time ................................................................................. 29  8  Splice Descriptors............................................................................................................................. 31  8.1  Overview .................................................................................................................................. 31  8.2  Splice Descriptor ..................................................................................................................... 31  8.2.1 Semantic definition of fields in splice_descriptor() ................................................................. 32  8.3  Specific Splice Descriptors ..................................................................................................... 32  8.3.1 avail_descriptor() ..................................................................................................................... 32  8.3.2 DTMF_descriptor() .................................................................................................................. 33  8.3.3 segmentation_descriptor()........................................................................................................ 34  9  Encryption ........................................................................................................................................ 40  9.1  Overview .................................................................................................................................. 40  9.2  Fixed Key Encryption ............................................................................................................. 40  9.3  Encryption Algorithms ........................................................................................................... 40  9.3.1 DES – ECB mode .................................................................................................................... 41  9.3.2 DES – CBC mode .................................................................................................................... 41  9.3.3 Triple DES EDE3 – ECB mode ............................................................................................... 41  9.3.4 User Private Algorithms .......................................................................................................... 41  3 List Of Tables Table 6-1. registration_descriptor() ......................................................................................................... 14 Table 6-2. cue_identifier_descriptor() ..................................................................................................... 14 Table 6-3. cue_stream_type Values ......................................................................................................... 15 Table 6-4. stream_identifier_descriptor() ................................................................................................ 16 Table 7-1. splice_info_section() .............................................................................................................. 18 Table 7-2. splice_command_type Values ................................................................................................ 20 Table 7-3. splice_null() ............................................................................................................................ 21 Table 7-4. splice_schedule() .................................................................................................................... 22 Table 7-5. splice_insert() ......................................................................................................................... 24 Table 7-6. time_signal() ........................................................................................................................... 26 Table 7-7. bandwidth_reservation() ......................................................................................................... 26 Table 7-8. private_command()................................................................................................................. 26 Table 7-9. splice_time() ........................................................................................................................... 27 Table 7-10. break_duration() ................................................................................................................... 28 Table 8-1. Splice Descriptor Tags ........................................................................................................... 31 Table 8-2. splice_descriptor() .................................................................................................................. 31 Table 8-3. avail_descriptor() .................................................................................................................... 32 Table 8-4. DTMF_descriptor() ................................................................................................................ 33 Table 8-5. segmentation_descriptor() ...................................................................................................... 34 Table 8-6. segmentation_upid_type ......................................................................................................... 36 Table 8-7. segmentation_type_id ............................................................................................................. 37 Table 9-1. Encryption Algorithm............................................................................................................. 41 4 Digital Program Insertion Cueing Message for Cable 1 Scope This standard supports the splicing of MPEG-2 streams for the purpose of Digital Program Insertion, which includes advertisement insertion and insertion of other content types. An in-stream messaging mechanism is defined to signal splicing and insertion opportunities and it is not intended to ensure seamless splicing. As such, this recommendation does not specify the splicing method used or constraints applied to the streams being spliced, nor does it address constraints placed on splicing devices. This standard also supports accurate signaling of events in the stream. A fully compliant MPEG-2 transport stream (either Multi Program Transport Stream or Single Program Transport Stream) is assumed. No further constraints beyond the inclusion of the defined cueing messages are placed upon the stream. This standard specifies a technique for carrying notification of upcoming Splice Points and other timing information in the transport stream. A splice information table is defined for notifying downstream devices of splice events, such as a network break or return from a network break. The splice information table, which pertains to a given program, is carried in one or more PID(s) referred to by that program’s Program Map Table (PMT). In this way, splice event notification can pass through most transport stream remultiplexers without need for special processing. 2 References 2.1 Normative references The following standards contain provisions that, through reference in this text, constitute provisions of this standard. At the time 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. ISO 15706:2002 – Information and Documentation - International Standard Audiovisual Number (ISAN) ISO 15706-2:200x (In Process) – Information and Documentation - International Standard Audiovisual Number (V-ISAN) ITU-T Recommendation H.222.0 / ISO/IEC 13818-1 (2000), Information Technology ---- Generic Coding of Moving Pictures and Associated Audio Information: Systems MD-SP-ADI2.0-AS-I03-070105 – Metadata Specifications - ADI 2.0 Specification Asset Structure 5 SMPTE 330M-2004 – SMPTE Standard for Television - Unique Material Identifier FIPS PUB 46-3, 1999 October 25, Data Encryption Standard FIPS PUB 81, 1980 December 2, DES Modes of Operation 2.2 Informative References Advertising Digital Identification, LLC - http://www.ad-id.org/ ISAN (International Standard Audiovisual Number) website – http://www.isan.org ITU-T Recommendation H.262 / ISO/IEC 13818-2 (2000), Information Technology ---- Generic Coding of Moving Pictures and Associated Audio Information: video ISO/IEC 13818–4: 2004 – Information Technology – Generic coding of moving pictures and associated audio information – Part 4: Conformance testing SCTE 30 2006 – Digital Program Insertion Splicing API SCTE 67 2006 – Digital Program Insertion Cueing Message for Cable – Interpretation for SCTE 35 SCTE 118-2 2006 – Program-Specific Ad Insertion – Content Provider to Traffic Communication Applications Data Model SMPTE Registration Authority, LLC – http://www.smpte-ra.org/ SMPTE 312M – 2001 - SMPTE STANDARD for Television - Splice Points for MPEG-2 Transport Streams 3 Definition of terms Throughout this standard the terms below have specific meanings. Because some of the terms that are defined in ISO/IEC 13818 have very specific technical meanings, the reader is referred to the original source for their definition. For terms defined by this standard, brief definitions are given below. Access Unit: A coded representation of a presentation unit (see ITU-T H.262 / ISO/IEC 13818-1 2.1.1). Advertisement (also called “ad”): an inducement to buy or patronize. As used in the cable industry, usually with a duration under 2 minutes (sometimes called “short-form” content). Analog Cue Tone: in an analog system, a signal that is usually either a sequence of DTMF tones or a contact closure that denotes to ad insertion equipment that an advertisement avail is about to begin or end. Avail: time space provided to cable operators by cable programming services during a program for use by the CATV operator; the time is usually sold to local advertisers or used for channel self promotion. 6 Break: avail or an actual insertion in progress. Chapter: a short section of a longer program, usually situated to permit a viewer to easily locate a scene or section of the program. Component Splice Mode: a mode of the cueing message whereby the program_splice_flag is set to ‘0’ and indicates that each PID/component that is intended to be spliced will be listed separately by the syntax that follows. Components not listed in the message are not to be spliced. Content: Generic term for television material, either advertisements or programs. Cueing Message: see message. Event: a splice event or a viewing event. In Point: a point in the stream, suitable for entry, that lies on an elementary presentation unit boundary. An In Point is actually between two presentation units rather than being a presentation unit itself. In Stream Device: A device that receives the transport stream directly and is able to derive timing information directly from the transport stream. Message: in the context of this document a message is the contents of any splice_info_section. Multi Program Transport Stream: A transport stream with multiple programs. Out of Stream Device: A device that receives the cue message from an in stream device over a separate connection from the transport stream. An out of stream device does not receive or pass the transport stream directly. Out Point: a point in the stream, suitable for exit, that lies on an elementary presentation unit boundary. An Out Point is actually between two presentation units rather than being a presentation unit itself. payload_unit_start_indicator: a bit in the transport packet header that signals, among other things, that a section begins in the payload that follows (see ITU-T H.222.0 / ISO/IEC 13818-1). PID: Packet identifier; a unique 13-bit value used to identify the type of data stored in the packet payload (see ITU-T H.222.0 / ISO/IEC 13818-1). PID stream: All the packets with the same PID within a transport stream. pointer_field: the first byte of a transport packet payload, required when a section begins in that packet (see ITU-T H.222.0 / ISO/IEC 13818-1). Presentation Time: the time that a presentation unit is presented in the system target decoder (see ITU-T H.222.0 / ISO/IEC 13818-1). 7 Presentation Unit: A decoded Audio Access Unit or a decoded picture (see ITU-T H.262 / ISO/IEC 13818-1 2.1.40). Program: A collection of video, audio, and data PID streams that share a common program number within an MPTS (see ITU-T H.222.0 / ISO/IEC 13818-1). As used in the context of the segmentation descriptor, a performance or informative presentation broadcast on television, typically with a duration over 5 minutes (sometimes called “long-form” content). Program In Point: a group of PID stream In Points that correspond in presentation time. Program Out Point: a group of PID stream Out Points that correspond in presentation time. Program Splice Mode: a mode of the cueing message whereby the program_splice_flag is set to ‘1’ and indicates that the message refers to a Program Splice Point and that all PIDs/components of the program are to be spliced. Program Splice Point: a Program In Point or a Program Out Point. Receiving Device: A device that receives or interprets sections conforming to this standard. Examples of these devices include splicers, ad servers, segmenters and satellite receivers. Registration Descriptor: carried in the PMT of a program to indicate that, when signaling splice events, splice_info_sections shall be carried in a PID stream within this program. The presence of the Registration Descriptor signifies a program’s compliance with this standard. reserved: The term “reserved”, when used in the clauses defining the coded bit stream, indicates that the value may be used in the future for extensions to the standard. Unless otherwise specified, all reserved bits shall be set to ‘1’ and this field shall be ignored by receiving equipment. Segment: either a Program, a Chapter, a Provider Advertisement, a Distributor Advertisement, or an Unscheduled Event as listed in Table 8-7, segmentation_type_id. Single Program Transport Stream: A transport stream containing a single MPEG program. Splice Event: an opportunity to splice one or more PID streams. Splice Immediate Mode: a mode of the cueing message whereby the splicing device shall choose the nearest opportunity in the stream, relative to the splice_info_table, to splice. When not in this mode, the message gives a “pts_time” that, when modified by pts_adjustment, gives a presentation time for the intended splicing moment. Splice Point: a point in a PID stream that is either an Out Point or an In Point. Viewing Event: a television program or a span of compressed material within a service; as opposed to a splice event, which is a point in time. 8 4 Abbreviations This document uses the following abbreviations: ADI: Asset Distribution Interface Ad-ID: Advertisement Identifier ATSC: Advanced Television Systems Committee. bslbf: Bit string, left bit first, where left is the order in which bit strings are written. DVB: Digital Video Broadcast FIPS: Federal Information Processing Standard ISAN: International Standard Audiovisual Number (see ISO 15706) ISCI: Industry Standard Commercial Identifier MPTS: a Multi Program Transport Stream. PMT: Program Map Table (see ITU-T H.222.0 / ISO/IEC 13818-1). PTS: Presentation Time Stamp (see ITU-T H.222.0 / ISO/IEC 13818-1). rpchof: Remainder polynomial coefficients, highest order first. SPTS: a Single Program Transport Stream. STC: System Time Clock TI: Turner Identifier TID: Tribune Identifier uimsbf: Unsigned integer, most significant bit first. UMID: Unique Material Identifier V-ISAN: Version-ISAN (core ISAN number plus a version number) (see ISO 15706-2) 9 5 Introduction 5.1 Splice points (Informative) To enable the splicing of compressed bit streams, this standard defines Splice Points. Splice Points in an MPEG-2 transport stream provide opportunities to switch elementary streams from one source to another. They indicate a place to switch or a place in the bit stream where a switch can be made. Splicing at such splice points may or may not result in good visual and audio quality. That is determined by the performance of the splicing device. Transport streams are created by multiplexing PID streams. In this standard, two types of Splice Points for PID streams are defined: Out Points and In Points. In Points are places in the bit streams where it is acceptable to enter, from a splicing standpoint. Out Points are places where it is acceptable to exit the bit stream. The grouping of In Points of individual PID streams into Program In Points in order to enable the switching of entire programs (video with audio) is defined. Program Out Points for exiting a program are also defined. Out Points and In Points are imaginary points in the bit stream located between two elementary stream presentation units. Out Points and In Points are not necessarily transport packet aligned and are not necessarily PES packet aligned. An Out Point and an In Point may be co-located; that is, a single presentation unit boundary may serve as both a safe place to leave a bit stream and a safe place to enter it. The output of a simple switching operation will contain access unit data from one stream up until its Out Point followed by data from another stream starting with the first access unit following an In Point. More complex splicing operations may exist whereby data prior to an Out Point or data after an In Point are modified by a splicing device. Splicing devices may also insert data between one stream’s Out Point and the other stream’s In Point. The behavior of splicing devices will not be specified or constrained in any way by this standard. 5.2 Program Splice Points (Informative) Program In Points and Program Out Points are sets of PID stream In Points or Out Points that correspond in presentation time. Although Splice Points in a Program Splice Point correspond in presentation time, they do not usually appear near each other in the transport stream. Because compressed video takes much longer to decode than audio, the audio Splice Points may lag the video Splice Points by as much as hundreds of milliseconds and by an amount that can vary during a program. This standard defines two ways of signaling which splice points within a program are to be spliced. A program_splice_flag, when true, denotes that the Program Splice Mode is active and that all PIDs of a program may be spliced (the splice information table PID is an exception; splicing or passage of these messages is beyond the scope of this standard). A program_splice_flag, when false, indicates that the Component Splice Mode is active and that the message will specify unambiguously which PIDs are to 10 be spliced and may give a unique splice time for each. This is required to direct the splicing device to splice or not to splice various unspecified data types as well as video and audio. While this standard allows for a unique splice time to be given for each component of a program, it is expected that most Component Splice Mode messages will utilize one splice time (a default splice time) for all components as described in section 7. The facility for optionally specifying a separate splice time for each component is intended to be used when one or more components differ significantly in their start or stop time relative to other components within the same message. An example would be a downloaded applet that must arrive at a set-top box several seconds prior to an advertisement. 5.3 Splice events (Informative) This standard provides a method for in-band signaling of splice events using splice commands to downstream splicing equipment. Signaling a splice event identifies which Splice Point within a stream to use for a splice. A splicing device may choose to act or not act upon a signaled event (a signaled event should be interpreted as an opportunity to splice; not a command). A splice information table carries the notice of splice event opportunities. Each signaled splice event is analogous to an analog cue tone. The splice information table incorporates the functionality of cue tones and extends it to enable the scheduling of splice events in advance. This standard establishes that the splice information table is carried on a per-program basis in one or more PID stream(s) with a designated stream_type. The program’s splice information PID(s) are designated in the program’s program map table (PMT). In this way, the splice information table is switched with the program as it goes through remultiplexing operations. A common stream_type identifies all PID streams that carry splice information tables. Remultiplexers or splicers may use this stream_type field to drop splice information prior to sending the transport stream to the end-user device. The cue injection equipment may send messages at intervals that do not indicate a splice point to be used as heartbeat messages which help insure the proper operation of the system. This could be performed by periodically issuing splice_null() messages or by sending encrypted splice_insert messages generated with a key that is not distributed. Since cues are currently sent twice per hour on a typical network, an average interval of 5 minutes would be a reasonable interval. If a message was not received in a 10 minute interval, a receiving device could alarm an operator to a possible system malfunction (such behavior would be implementer dependent). 5.4 Content Storage Considerations (Informative) The requirements for identifier uniqueness are written expecting the content to be playing in real time. If the content is stored, then the playback of the content does not place requirements upon the playback equipment to alter any of these identifiers (such as splice_event_id or segmentation_event_id). Downstream equipment parsing the identifiers should keep this in mind and, if applicable, rely upon other confirming information before reacting adversely to a seeming violation of the identifier uniqueness requirements of this standard. This standard provides optional tools to assist with segmenting content into shorter sections which may be either chapters or advertisements. See Section 8.3.3. 11 5.5 PID selection 5.5.1 PID Selection (Normative) Splice Information can be carried in multiple PIDs. The maximum number of PIDs that can carry splice information shall not exceed 8. These PIDs can be either in the clear (where the transport scrambling_control bits are set to '00') or scrambled by a CA system. Each cue message PID may include the cue_identifier_descriptor defined in section 6.2 to describe the splice commands included in the PID. When multiple PIDs are used to carry splice information, the first cue message PID in the Program Map Table shall only contain the splice command types 0x00 (splice_null), 0x04 (splice_schedule) and 0x05 (splice_insert). In addition, the splice_event_id shall be unique in all splice information PIDs within the program. 5.5.2 PID Selection (Informative) While the use of multiple cue message PIDs is an allowed practice, it should be noted that not all equipment may respond in the same manner to a stream that contains multiple cue message PIDs. Some equipment may limit the number of PIDs that the equipment can pass or receive. If a system utilizes multiple PIDs through various devices with the intention of reaching the set-top, it is suggested that thorough end-end testing be performed. In many systems, the delivery of PIDs that carry splice information beyond the ad insertion equipment in the head-end is not desired. In these systems, the splicing or multiplexing device will drop any or all of these messages (PIDs) so they will not be delivered to the set-top. In other systems it may selectively pass certain PIDs to the set top to enable set-top functionality. A third possibility is that the splicing or multiplexing device will aggregate the multiple PIDs that carry splice information into a single PID to handle downstream, set-top, issues with multiple PIDs. The action of ignoring or passing the message is recommended to be a user provisioned item, with a suitable default behavior chosen by the implementer. The default operation if a splicing or multiplexing device receives a PID based on this specification with the scrambling bits set in the header should be to drop that PID and not pass it through to the output. This ideally should be a user provisioned operation, as in some instances this PID may be descrambled by a downstream device. The delivery of messages outside of the receive location to the customer may be based on business agreements. An example would be that one programmer wants the cue messages passed to set-tops to enable a targeted advertising method while a different programmer insists that the messages be dropped to insure that a commercial killer may not utilize the messages. When multiple splicing PIDs are identified in the PMT, the splicing device should process all of these PIDs. If the cue_identifier_descriptor is utilized, the splicing or multiplexing device may use that information to be more selective of the PIDs on which it will act. Some possible reasons for utilizing multiple PIDs for this message include selective delivery of cue messages for different tiers of advertising or for separating cue messages from segmentation messages. While one possible method of handling these issues is to use the encryption methods built in to this 12 standard, many delivery mechanisms can support conditional delivery by PID in a secure fashion. The delivery equipment (Satellite transmitter/receiver, remultiplexer) may PID filter the stream to only allow one or a small number of the PIDs to be passed in-stream. This method may be used to create multiple programs in the feed based on entitlement. The decision to use one or more PIDs will be based on the security required and the CA hardware available on the system. 5.6 Message flow (Informative) The messages described in this document can originate from multiple sources. They are designed to be sent in-stream to downstream devices. The downstream devices may act on the messages or send them to a device that is not in-stream to act upon them. An example would be a splicer communicating via SCTE 30 protocol to an ad server. The in-stream devices could pass the messages to the next device in the transmission chain, or they could, optionally, drop the messages. Implementers are urged to make these decisions user provisioned, rather than arbitrarily hard-coded. Any device that restamps pcr/pts/dts and that passes these cue messages to a downstream device should modify the pts_time field or the pts_adjustment field in the message in all PIDs conforming to this standard. Modifying the pts_adjustment field is preferred because the restamping device will not have to be knowledgeable of the pts_time field that may occur in multiple commands (and possibly in future commands). The bandwidth_reservation() message is intended as a message used on a closed path from a satellite origination system (encoder) to a receiver. It is also intended that this message will be dropped (replaced by a NULL packet) by the receiver, but this is not required. Should this message reach an in- stream device (e.g. a splicer) the message should not be forwarded to an out-of-stream device (e.g. Ad Server) and can either be ignored or passed by an in-stream device. The action of ignoring or passing the message is recommended to be a user provisioned item, with a suitable default behavior chosen by the implementer. 6 PMT Descriptors 6.1 Registration Descriptor The registration descriptor (ITU-T H.222.0 / ISO/IEC 13818-1, table 2-46 -- Registration Descriptor, clause 2.6.8) is defined to identify unambiguously the programs that comply with this standard. The registration descriptor shall be carried in the program_info loop of the PMT for each program that complies with this standard. It must reside in all PMTs of all complying programs within a multiplex. The presence of the registration descriptor also indicates that, when signaling splice events, splice_info_sections shall be carried in one or more PID stream(s) within this program. Presence of this registration descriptor in the PMT signals the following: 1. The program elements do not include the splice information table defined by SMPTE 312M. 13 2. The only descriptors that can be present in the ES_descriptor_loop of the PMT for the PID(s) that carry the splice_information_table are those that are defined in this specification or user private descriptors. Note that this descriptor applies to the indicated program and not to the entire multiplex. The content of the registration descriptor is specified in Table 6-1 and below: Table 6-1. registration_descriptor() Syntax Bits Mnemonic registration_descriptor() { descriptor_tag 8 uimsbf descriptor_length 8 uimsbf SCTE_splice_format_identifier 32 uimsbf } 6.1.1 Semantic definition of fields in Registration Descriptor descriptor_tag – The descriptor_tag is an 8-bit field that identifies each descriptor. For registration purposes, this field shall be set to 0x05. descriptor_length – The descriptor_length is an 8-bit field specifying the number of bytes of the descriptor immediately following descriptor_length field. For this registration descriptor, descriptor_length shall be set to 0x04. SCTE_splice_format_identifier – SCTE has assigned a value of 0x43554549 (ASCII “CUEI”) to this 4-byte field to identify the program (within a multiplex) in which it is carried as complying with this standard. 6.2 Cue Identifier Descriptor The cue_identifier_descriptor may be used in the PMT to label PIDs that carry splice commands so that they can be differentiated as to the type or level of splice commands they carry. The cue_identifier_descriptor, when present, shall be located in the elementary descriptor loop. If the cue_identifier_descriptor is not utilized, the stream may carry any valid command in this specification. Table 6-2. cue_identifier_descriptor() Syntax Bits Mnemonic cue_identifier_descriptor() { descriptor_tag 8 uimsbf descriptor_length 8 uimsbf cue_stream_type 8 uimsbf } 14 6.2.1 Semantic definition of fields in Cue Identifier Descriptor descriptor_tag - The descriptor_tag is an 8-bit field that identifies each descriptor. For cue_identifier_descriptor, this field shall be set to 0x8A. descriptor_length - The descriptor_length in an 8-bit field specifying the number of bytes of the descriptor immediately following descriptor_length field. For this descriptor, descriptor_length shall be set to 0x01. cue_stream_type - This 8-bit field is defined in the following table. Table 6-3. cue_stream_type Values cue_stream_type PID usage 0x00 splice_insert, splice_null, splice_schedule 0x01 All Commands 0x02 Segmentation 0x03 Tiered Splicing 0x04 Tiered Segmentation 0x05-0x7f Reserved 0x80 - 0xff User Defined 6.2.2 Description of cue_stream_type usage 0x00 – splice_insert, splice_null, splice_schedule – Only these cue messages are allowed in this PID stream. There shall be a maximum of one PID identified with this cue_stream_type. If this PID exists, it shall be the first stream complying with this standard in the PMT elementary stream loop. 0x01 – All Commands – Default if this descriptor is not present. All messages can be used in this PID. 0x02 – Segmentation – This PID carries the time_signal command and the segmentation descriptor. It may also carry all other commands if needed for the application, but the primary purpose is to transmit content segmentation information. 0x03 – Tiered Splicing – Tiered Splicing refers to an insertion system where the operator provides different inserted program possibilities in a given avail for different customers. The physical and logical implementation may be done in several different manners, some of them outside the scope of this standard. 0x04 – Tiered Segmentation – Tiered Segmentation refers to a system where the operator provides different program segmentation possibilities for different customers. The physical and logical implementation may be done in several different manners, some of them outside the scope of this standard. 0x05-0x7F – Reserved for future extensions to this standard. 0x80-0xFF – User defined range. 15 6.3 Stream Identifier Descriptor The stream identifier descriptor may be used in the PMT to label component streams of a service so that they can be differentiated. The stream identifier descriptor shall be located in the elementary descriptor loop following the relevant ES_info_length field. The stream identifier descriptor shall be used if either the program_splice_flag or the program_segmentation_flag is zero. If stream identifier descriptors are used, a stream identifier descriptor shall be present in each occurrence of the elementary stream loop within the PMT and shall have a unique component tag within the given program. Table 6-4. stream_identifier_descriptor() Syntax Bits Mnemonic stream_identifier_descriptor() { descriptor_tag 8 uimsbf descriptor_length 8 uimsbf component_tag 8 uimsbf } 6.3.1 Semantic definition of fields in Stream Identifier Descriptor descriptor_tag - The descriptor_tag is an 8-bit field that identifies each descriptor. For stream_identifier_descriptor, this field shall be set to 0x52. descriptor_length - The descriptor_length in an 8-bit field specifying the number of bytes of the descriptor immediately following descriptor_length field. For this descriptor, descriptor_length shall be set to 0x01. component_tag - This 8-bit field identifies the component stream for associating it with a description given in a component descriptor. Within a program map section each stream identifier descriptor shall have a different value for this field. 7 Splice Information Table 7.1 Overview The splice information table provides command and control information to the splicer. It notifies the splicer of splice events in advance of those events. It is designed to accommodate ad insertion in network feeds. In this environment, examples of splice events would include 1) a splice out of a network feed into an ad, or 2) the splice out of an ad to return to the network feed. The splice information table may be sent multiple times and splice events may be cancelled. Syntax for a splice_info_section is defined to convey the splice information table. The splice_info_section is carried on one or more PID stream(s) with the PID(s) declared in that program’s PMT. A splice event indicates the opportunity to splice one or more elementary streams within a program. Each splice event is uniquely identified with a splice_event_id. Splice events may be communicated in 16 three ways: they may be scheduled ahead of time, a preroll warning may be given, or a command may be given to execute the splice event at specified Splice Points. These three types of messages are sent via the splice_info_section. The splice_command_type field specifies the message being sent. Depending on the value of this field, different constraints apply to the remaining syntax. The following command types are specified: splice_null(), splice_schedule(), splice_insert(), time_signal() and bandwidth_reservation(). If the Receiving Device does not support a command it can ignore the entire splice_info_section. The splice_null() command is provided for extensibility. It can be used as a means of providing a heartbeat message to downstream splicing equipment. The splice_schedule() command is a command that allows a schedule of splice events to be conveyed in advance. The splice_insert() command shall be sent at least once before each splice point. Packets containing the entirety of the splice_info_table shall always precede the packet that contains the related splice point (i.e., the first packet that contains the first byte of an access unit whose presentation time most closely matches the signaled time in the splice_info_section). In order to give advance warning of the impending splice (a pre-roll function), the splice_insert() command could be sent multiple times before the splice point. For example, the splice_insert() command could be sent at 8, 5, 4 and 2 seconds prior to the packet containing the related splice point. In order to meet other splicing deadlines in the system, any message received with less then 4 seconds of advance notice may not create the desired result. The splice_insert() message shall be sent at least once a minimum of 4 seconds in advance of the desired splice time for a network Out Point condition. It is recommended that, if a return-to-network (an In Point) message is sent, the same minimum 4 second pre-roll be provided. The splice_insert() command provides for an optional break_duration() structure to identify the length of the commercial break. It is recommended that splice_insert() messages with the out_of_network_indicator set to 1 (a network Out Point) include a break_duration() structure to provide the splicer with an indication of when the network In Point will occur. The break_duration() structure provides for an optional auto_return flag that, when set to 1, indicates that the splicer is to return to the network at the end of the break (defined as Auto Return Mode, refer to Section 7.5.2.2). It is recommended that this Auto Return Mode be used to support dynamic avail durations. The time_signal() command is provided for extensibility while preserving the precise timing allowed in the splice_insert() command. This is to allow for new features not directly related to splicing utilizing the timing capabilities of this specification while causing minimal impact to the splicing devices that conform to this specification. This allows the device that will be inserting the time into the cue message to have a defined location. The bandwidth_reservation() command is provided to allow command insertion devices to utilize a consistent amount of transport stream bandwidth. Descriptors may be used in this command, but they can not be expected to be processed and sent downstream to provide signaling information. 17 There are two methods for changing the parameters of a command once it has been issued. One method is to cancel the issued command by sending a splice_info_section with the splice_event_cancel_indicator set and then to send a new splice_info_section with the correct/new parameters. The other method is to simply send a subsequent message with the new data (without canceling the old message via a cue message that has the splice_event_cancel_indicator bit set). 7.1.1 Time Base Discontinuities In the case where a system time base discontinuity is present, packets containing a splice_insert() or time_signal() command with time expressed in the new time base shall not arrive prior to the occurrence of the time base discontinuity. Packets containing a splice_insert() or time_signal() command with time expressed in the previous time base shall not arrive after the occurrence of the time base discontinuity. See ISO/IEC 13818–4: 2004 – Information Technology – Generic coding of moving pictures and associated audio information – Part 4: Conformance testing. The complete syntax is presented below, followed by definition of terms, followed by constraints. 7.2 Splice Info Section The splice_info_section shall be carried in transport packets whereby only one section or partial section may be in any transport packet. Splice_info_sections must always start at the beginning of a transport packet payload. When a section begins in a transport packet, the pointer_field must be present and equal to 0x00 and the payload_unit_start_indicator bit must be equal to one (per the requirements of section syntax usage per ITU-T H.222.0 / ISO/IEC 13818-1). Table 7-1. splice_info_section() Syntax Bits Mnemonic Encrypted splice_info_section() { table_id 8 uimsbf section_syntax_indicator 1 bslbf private_indicator 1 bslbf reserved 2 bslbf section_length 12 uimsbf protocol_version 8 uimsbf encrypted_packet 1 bslbf encryption_algorithm 6 uimsbf pts_adjustment 33 uimsbf cw_index 8 uimsbf reserved 12 bslbf splice_command_length 12 uimsbf splice_command_type 8 uimsbf E if(splice_command_type == 0x00) splice_null() E if(splice_command_type == 0x04) splice_schedule() E if(splice_command_type == 0x05) splice_insert() E if(splice_command_type == 0x06) 18 time_signal() E if(splice_command_type == 0x07) bandwidth_reservation() E if(splice_command_type == 0xff) private_command() E descriptor_loop_length 16 uimsbf E for(i=0; i:/ as specified in Section 5.2 of MD-SP-ADI2.0-AS-I03-070105, represented as 7-bit ASCII characters (values ranging from 0x20 (space) to 0x7E (tilde)). The variable “element” shall take only the values “PREVIEW”, “MPEG2HD”, “MPEG2SD”, and “OTHER”. segmentation_upid_length - Length in bytes of segmentation_upid() as indicated by Table 8-6. segmentation_upid() - Length and identification from Table 8-6. This structure’s contents and length are determined by the segmentation_upid_type and segmentation_upid_length fields. An example would be a type of 0x06 for V-ISAN and a length of 12 bytes. This field would then contain the V- ISAN identifier for the content to which this descriptor refers. segmentation_type_id - The 8 bit value shall contain one of the values in Table 8-7 to designate type of segmentation. All unused values are reserved. When the segmentation_type_id is 0x01 (Content Identification), the value of segmentation_upid_type shall be non-zero. 36 Table 8-7. segmentation_type_id Segmentation Message Segmentation_type_id segment_num segments_expected Not Indicated 0x00 0 0 Content Identification 0x01 0 0 Program Start 0x10 1 1 Program End 0x11 1 1 Program Early Termination 0x12 1 1 Program Breakaway 0x13 1 1 Program Resumption 0x14 1 1 Program Runover Planned 0x15 1 1 Program Runover Unplanned 0x16 1 1 Chapter Start 0x20 Non-zero Non-zero Chapter End 0x21 Non-zero Non-zero Provider Advertisement Start 0x30 0 or Non-zero 0 or Non-zero Provider Advertisement End 0x31 0 or Non-zero 0 or Non-zero Distributor Advertisement Start 0x32 0 or Non-zero 0 or Non-zero Distributor Advertisement End 0x33 0 or Non-zero 0 or Non-zero Unscheduled_event_start 0x40 0 0 Unscheduled_event_end 0x41 0 0 segment_num - This field provides identification for a specific chapter or advertisement within a segmentation_upid(). This value, when utilized, is expected to reset to one for the first chapter in a new viewing event. This field is expected to increment for each new segment (such as a chapter). The value of this field shall be as indicated in Table 8-7. segments_expected - This field provides a count of the expected number of individual segments (such as chapters) within the current segmentation event. The value of this field shall be as indicated in Table 8-7. 8.3.3.2 Segmenting Content - Additional semantics One use of this descriptor is to signal content Segments. Segments are expected to have a logical hierarchy consisting of programs (highest level), chapters, and advertisements (refer to Table 8-7, above). Provider and distributor advertisements share the lowest logical level and should not overlap. For the purposes of defining the semantics stated in this document section, the following definition applies: Segment - Shall be either a Program, a Chapter, a Provider Advertisement, a Distributor Advertisement, or an Unscheduled Event as listed in Table 8-7, segmentation_type_id. Occurrences of the segmentation_descriptor() that support Segments typically occur in pairs. The valid pairings are: - Program start/end – Program end can be overridden by Program Early Termination - Program breakaway/resumption 37 - Chapter start/end - Provider advertisement start/end - Distributor advertisement start/end - Unscheduled_event_start/end The following segmentation_types (from Table 8-8) also support Segments but are not paired: - Program Runover Planned - Program Runover Unplanned The following segmentation_types (from Table 8-8) are outside of the scope of this document section. They are not considered to support Segments (Segmenting Content): - Not Indicated - Content Identification Descriptors should normally be paired, once for a given Segment start and then for Segment end. Each Segment end usage may be followed by another Segment start of the same logical level Segment. Refer to Section 8.3.3.3 (Programs) and Section 8.3.3.4 (Chapters) for additional semantics. When a Segment’s duration is provided, and that duration expires without a Segment end being signaled, then the value of segmentation_event_id may be reused if appropriate. Such inferred Segment end cases are not to be encouraged and should not be used. In order to associate different types of segmentation constructs (such as associating Program level constructs with Chapter level constructs) the same segmentation_upid() may be used in the associated constructs. This however is not required. The semantics of the fields within the segmentation_descriptor() for segmenting content are as follows: segmentation_event_id - When a Segment start is signaled, the segmentation_event_id value becomes active. While active this value shall not be used to identify other segmentation events. When a Segment end is signaled, the segmentation_event_id value shall match the segment start segmentation_event_id value and this value then becomes inactive and hence able to be used again for a new segmentation_descriptor() occurrence including non-Segment usage such as Content Identification. program_segmentation_flag - Shall be set to ‘1’. segmentation_duration_flag - If set to ‘1’, a valid segmentation_duration shall be included in the descriptor. If segmentation_type_id is set to 0x10 (Program Start) then this flag may be set to ‘0’. segment_num - Shall be set to non-zero values for Chapters ranging from one to the value of segments_expected. For Program segments, this value shall be set to one. This field may be optionally utilized for Advertisements in the same manner as Chapters. segments_expected Shall be set to a non-zero value, providing the number of Chapters (and optionally Advertisements) in the program. For Program segments, this value shall be set to one. 38 8.3.3.3 Programs - Additional semantics When signaled, a Program shall begin with a segmentation_descriptor() containing a segmentation_type_id value of 0x10 (Program Start). The Program shall utilize a single and unique value for segmentation_event_id in all descriptors that pertain to this Program. The usage of a segmentation_upid( ) is optional but, if used, its value must be uniquely assigned to this Program and not shared by Programs that are embedded within this Program. A Program shall end with a segmentation_descriptor() containing a segmentation_type_id value of 0x11 (Program End) or 0x12 (Program Early Termination). The following segmentation messages shall only occur between the Program Start and Program end (Program End or Program Early Termination): Program Beakaway (segmentation_type_id value of 0x13); Program Resumption (segmentation_type_id value of 0x14); Program Runover Planned (segmentation_type_id value of 0x15); or Program Runover Unplanned (segmentation_type_id value of 0x16). A Program Resumption may only follow a Program Breakaway. A program may be ended while in a Program Breakaway state. Following a Program Beakaway, another Program Start to Program End sequence may occur, with new values of segmentation_event_id and segmentation_upid( ). An entire embedded Program or Segments of an embedded Program shall be situated only between a Program Breakaway and a Program Resumption. Multiple instances of embedded Programs may occur. Note: Program Runover messages are asynchronous notifications and may occur at any time between the start and end of the program including within another embedded active program. If provided the segmentation_duration is considered from the splice_time() of the time_signal command, if time is present, or from the time the message is received. The duration clock continues to increment during Program Breakaways. Segmentation_duration can be extended using a Runover Planned or Runover Unplanned message. The value supplied in the new message is an update to the overall duration of the program and represents the elapsed time from the effective moment of the new message to the end of the segment. It is not an addition of elapsed time. If segmentation_duration is specified, when the duration is exceeded the program shall be considered terminated. If at Program start a duration is not provided, a duration may be provided at a later time using a Program Runover Planned or Program Runover Unplanned message. If a duration is in effect, either set at Program start or later introduced, segmentation_duration may be set to zero by sending a Program Runover Planned or Program Runover Unplanned message with segmentation_duration_flag set to ‘0’. A Content Identification (value of segmentation_type_id 0x01) message with a value of segmentation_upid( ) matching the currently active Program may be sent on a periodic basis to make an implementation more robust. If sent it shall match the values of segmentation_event_id and segmentation_upid( ) used in the Program related messages. This does not restrict Content Identification messages being sent that do not match the segmentation_event_id and segmentation_upid( ) used in the Program related messages. 39 8.3.3.4 Chapters - Additional semantics A chapter Segment shall be introduced by a Chapter Start and ended by a Chapter End. For Chapter End, the value of segmentation_event_id shall match the value of segmentation_event_id for Chapter Start. If present, the segmentation_upid() shall be the same in both occurrences of a segmentation_descriptor() pair. Chapter Segments may be associated with Program segments using the same segmentation_upid() on both Chapter and Program messages. Chapters may overlap. Chapters may be numbered using segment_num. Segments_expected shall indicate the expected number of chapters. Use of non-zero values for segmentation_duration on Chapter Start is optional. 9 Encryption 9.1 Overview The splice_info_section supports the encryption of a portion of the section in order that one may prevent access to an avail to all except those receivers that are authorized for that avail. This chapter of the document describes the various encryption algorithms that may be used. The encryption of the section is optional, as is the implementation of encryption by either the creator of the message, or any receive devices. The use of encryption is deemed optional to allow a manufacturer to ship “in-the-clear” systems without worrying about the export of encryption technology. If encryption is included in the system, any receive device shall implement all of the algorithms listed in this document, which allows the creator of a splice info table to use any of the algorithms in a transmission. The use of private encryption technology is optional, and out of the scope of this document. 9.2 Fixed Key Encryption The encryption used with this document assumes a fixed key is to be used. The same key is provided to both the transmitter and the receiver. The method of delivering the key to all parties is unspecified. This document allows for up to 256 different keys to be available for decryption. The cw_index field is used to determine which key should be used when decrypting a section. The length of the fixed key is dependent on the type of algorithm being used. It is assumed that fixed key delivered to all parties will be the correct length for the algorithm that is intended to be used. 9.3 Encryption Algorithms The encryption_algorithm field of the splice_info_section is a six-bit value, which may contain one of the values shown in Table 9-1. All Data Encryption Standard variants use a 64-bit key (actually 56 bits plus a checksum) to encrypt or decrypt a block of 8 bytes. In the case of triple DES, there will need to be 3 64-bit keys, one for each of the three passes of the DES algorithm. The “standard” triple DES actually uses two keys, where the first and third keys are identical. See FIPS PUB 46-3 and FIPS PUB 81. 40 Table 9-1. Encryption Algorithm Value Encryption Algorithm 0 No encryption 1 DES – ECB mode 2 DES – CBC mode 3 Triple DES EDE3 – ECB mode 4-31 Reserved 32-63 User private 9.3.1 DES – ECB mode This algorithm uses the “Data Encryption Standard”, (see FIPS PUB 81), in the electronic codebook mode. In order to use this type of encryption, the encrypted data must contain a multiple of 8 bytes of data, from splice_command_type through to E_CRC_32 fields. The alignment_stuffing loop may be used to pad any extra bytes that may be required. 9.3.2 DES – CBC mode This algorithm uses the “Data Encryption Standard”, (see FIPS PUB 81) in the cipher block chaining mode. The basic algorithm is identical to DES ECB. Each 64-bit plaintext block is bitwise exclusive- ORed with the previous ciphertext block before being encrypted with the DES key. The first block is exclusive-ORed with an initial vector. For the purposes of this document, the initial vector shall have a fixed value of zero. In order to use this type of encryption, the encrypted data must contain a multiple of 8 bytes of data, from splice_command_type through to E_CRC_32 fields. The alignment_stuffing loop may be used to pad any extra bytes that may be required. 9.3.3 Triple DES EDE3 – ECB mode This algorithm uses three 64-bit keys, each key being used on one pass of the DES-ECB algorithm. See FIPS PUB 46-3. Every block of data at the transmit device is first encrypted with the first key, decrypted with the second key, and finally encrypted with the third key. Every block at the receive site is first decrypted with the third key, encrypted with the second key, and finally decrypted with the first key. In order to use this type of encryption, the encrypted data must contain a multiple of 8 bytes of data, from splice_command_type through to E_CRC_32 fields. The alignment_stuffing loop may be used to pad any extra bytes that may be required. 9.3.4 User Private Algorithms This document allows for the use of private encryption algorithms. It is not specified how the transmit and receive devices agree on the algorithm to use for any user private code. It is also not specified as to how coordination of private values for the encryption_algorithm field should be registered or administered. 41