ANSI SCTE 30:2017 pdf free download – Digital Program Insertion Splicing API
Logically, a splice involves two input Channels and one output Channel. The Splicer is responsible for joining the various elementary streams (audio, video and data) together. The optimal splice point may occur at slightly different times for each elementary stream, so the Splicer should perform the splice that will supply the best quality output. Splicing may not always be performed from the Primary Channel, i.e. programming network, to the Insertion Channel, i.e. spot advertisement, and back to the Primary Channel. The Splicer may splice content that is stored solely on the server and arrives over a single input Multiplex. It is possible to use this API in a situation where a server has one Multi-Program Transport Stream (MPTS) output that contains program and interstitial material and uses the splicer to create proper splices between the content. This API supports all combinations of single and multiple Servers communicating with single and multiple Splicers. A separate API Connection is associated with each Output Channel. In some configurations, there can be either multiple Servers or multiple channels within the Insertion Multiplex connected to a Splicer. In these cases, the Splicer will have multiple API Connections associated with an Output Channel. When an [SCTE 35] Cueing Message is received in a Primary Channel, the Cue_Request message must be sent to Servers over all of the API Connections that were made for the associated Output Channel(s). It is also possible that more than one API Connection will transport a Splice_Request message for the same insertion at the same time for an Output Channel.
6.2. Arbitration Priorities
Deprecated: There are no known implementations of arbitration. Different levels of access are used to ensure that the correct Insertion Channel is utilized. There are ten different levels of access, 0 through 9, with 9 being the highest priority which may override any lower priority connection. The OverridePlaying flag in the Splice_Request message specifies whether an insertion request is honored when the Splicer is currently queuing or performing an insertion. If the flag is set to 1, then the higher priority insertion can interrupt the same or lower priority currently playing insertion. If the flag is set to 0, the Splicer will not replace the insertion currently playing, even if the new request is of a higher priority. The Splice_Request message should be sent at least three seconds before the splice time( ) in order to be valid. If the three second minimum is not met, the outcome of the Splice_Request message is not determined by this API. If multiple Servers initiate splice requests for the same time with the same priority, the Splicer will prioritize the requests on a first come-first served basis. All other requests will be denied and a collision error will be sent in the Splice_Response message (unless the OverridePlaying flag is set). For example, during the period of time immediately preceding the initiation of an insertion, the following is true: if a priority 5 Splice_Request is received for the same splice time as a priority 3 Splice_Request, a collision error is returned for the priority 3 request. If a priority 7 Splice_Request is later received for the same time, a collision error is returned for the priority 5 request and the priority 7 request is queued. If a second priority 7 request is received with the OverridePlaying flag set to 0, then the second priority 7 request would receive a collision error. However, if the OverridePlaying flag is set to 1 on the second priority 7 request, the original priority 7 request would receive a collision error and be overridden.