ANSI/SCTE 67:2006 pdf download.Digital Program Insertion Cueing Message for Cable一
Interpretation for SCTE 35.
4.1 Scope
This document is an informational companion to SCTE 35 2(X$. It is not in itself a specification or a standard. The information within is intended as guideline infonnation. Where this document contradicts SCTE 35 2004. SCTE 35 2004shall take precedence.
4.2 Purpose
The purpose of this document is to aid splicing equipment designers. ad insertion equipment designers and purchasers and users of such equipment. Also expected to be interested are the networks that will originate DPI cue messages from their uplink sites and the manufacturers of the equipment to do this. This document is also expected to aid in the system integration of advertising related equipment. both at the message origination end and at the message reception end.
There may be crucial information within this document for manufacturers of equipment that pass the 1)Pl cue message as part of the MPEG stream. An example of such equipment is a rate altering re-multiplexer. which performs complex processing of the stream. When the stream is demultiplexed and processed and then re-multiplexed. it is very important to place the DPI Cue Message in the proper position relative to the video service and relative to nearby time base discontinuitics. Such equipment may also be required to alter the message before retransmission.
5 Application Guidelines
5.1 Practical Boundaries for spllce_tlme() In spllce_insert()
How far ahead of the splice must a splice_insert message be sent, relative to the picture it refers to. in order to be safely responded to by an ad insertion system?
The “arm time” denotes the time a DPI cue message must precede that actual insertion. The arm time should be in the range of 5 – 8 seconds. This is in line with the pre-roll time for analog cue- tones. The arm rime must not be so short that the avail passes by before the ad insertion system has time to respond. A minimum of 4 seconds is believed lobe required for safe operation.
More thought about the possible consequences is required if it is desirable to extend the arm time beyond the recommended eight seconds, To specify a maximum arm time therefore seems premature.
The splice_info_section itself does not have any 19’S or DTS associated with it. Therefore ii is not defined when the message should he decoded or when it should be presented. i.e. when it should take effect. By choosing the minimum required arm lime as 4 seconds, the problem of detining how this time should be measured can he avoided. Any reasonable measuring method will suffice.
5.2 Splice Time Accuracy
Although precise splice times can be specified using both the Program Splice Mode and Component Splice Mode it is not required that the server/splicer perform splices at these precise times. This is true, especially when splicing at precisely the specified time would lead to a splice of lower quality than necessary. Instead a server/splicer may usc the splice times as guidclincs.
For example. in the case of video a splicer may insert a few black frames for GOP alignment, or instead of using a H-frame as an Out Point it may choose a nearby I- or P-frame. In the case of audio the video presentation time will not in general align with the audio presentation time(s) and. therefore, corresponding audio splices will be executed at times that are “close” to the nearest video presentation time. Thus, the intelligent choice of actual splice points will he one factor that differentiates splicers.
A cue message creator may be intelligent enough to never specify the presentation time of a H- frame as an Out Point from the network feed. Then there are very few good reasons for a splicer/server to change the splice_time specified for the start of a break. Similarly. a good practice by the message creator could be to choose an I-frame as the In Point at which the network feed should resume. However, each remote site may store local MPEG2 ad files of imprecise length. structure and nature. eg.. when different encoder settings are used. Therefore a message creator cannot ensure proper alignment between a given In Point and all the individual Out Points at the remote sites without additional constraints.
