SCTE-104 List of available Multiple Operation Message and XML

Multiple Operation Message

Therefore, the main XML parameters will be the same when sending any command:

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
                <opID>258</opID>
                    <data>
                    </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• protocol_version – An 8-bit unsigned integer field whose function is to allow, in the future, this message type to carry parameters that may be structured differently than those defined in the current protocol. It shall be zero (0x00). Non-zero values of protocol_version may be used by a future version of this standard to indicate structurally different messages.
• AS_index uniquely identifies the source of the message (since it is possible to have several automation systems active at once). The number ranges from 0 to 255 and shall be zero if this index is not required.
  This variable takes the value returned by the “AS_index” field of the config_response message (See
  Section 10.2.3). A redundant AS shall be assigned one single value of AS_index which applies to both primary and backup. Either the primary or the backup is active at a given time, but not both. An Injector Instance shall be connected to only one AS at a given time. If non-zero, AS_index shall be unique within a single DCS.
• message_number – An integer value that is used to identify an individual message. The message_number variable must be unique for the life of a message. When multiple copies of the same message are sent, they can be identified because they have the same message_number. This means that for messages that are to be processed in the future, the message_number may not be reused until themessage has been processed. If not in current use, the message_number may freely vary over the range of 0 to 255.
  In a uni-directional system, the message number can be assumed to be available for reuse after the associated processing timestamp() time has passed.
• DPI_PID_index specifies the index to the DPI PID which will carry the resulting splice_info_sections. The number ranges from 0 to 65535. DPI_PID_index shall be zero if not required by the system architecture.
• SCTE35_protocol_version – This 8-bit unsigned integer field indicates the version of SCTE 35 protocol that the section which results from this message conforms to. Its function is to allow, in the future, this section type to carry parameters that may be structured differently than those defined in the current protocol. At present, the only valid value is zero (0x00). Non-zero values of SCTE35_protocol_version may be used by a future version of this standard to indicate structurally different sections.
• opID – An integer value that indicates what request is being sent.

 

inject_section_data_request()

This is a Normal usage request. When this request is processed, the image will be copied into the command structure of the associated splice_info_section being created. Some Supplemental requests, such as an insert descriptor request or encrypted_DPI request may be used with this request.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>256</opID>
            <data>
                <inject_section_data_request>
                    <SCTE35_command_length>5</SCTE35_command_length>
                    <SCTE35_protocol_version>0</SCTE35_protocol_version>
                    <SCTE35_command_type>1</SCTE35_command_type>
                    <SCTE35_command_contents>2A31323323</SCTE35_command_contents>
                </inject_section_data_request>
            </data>
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• SCTE35_command_length – This field encodes the number of bytes in the SCTE35_command_contents() structure.
• SCTE35_protocol_version – When the splice_info_section() is created, the protocol version field in the Splice Info Section will be filled in with this value. This could allow a compatible method of delivering commands defined in future revisions of using older versions of this protocol.
• SCTE35_command_type – This field will fill in the value of the splice_command_type field in the splice_info_section() being created.
• SCTE35_command_contents() – This is a complete binary image of the splice_info_section() being created, following the splice_command_type field up to, but not including, the descriptor_loop_length field.

splice_request_data()

This Normal request is the usual carrier of splicing requests. It may be further elaborated upon by various Supplemental type requests which may follow it within the data() structure of a multiple_operation_message.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>257</opID>
            <data>
                <splice_request_data>
                    <splice_insert_type>1</splice_insert_type>
                    <splice_event_id>214</splice_event_id>
                    <unique_program_id>135</unique_program_id>
                    <pre_roll_time>0</pre_roll_time>
                    <break_duration>0</break_duration>
                    <avail_num>0</avail_num>
                    <avails_expected>0</avails_expected>
                    <auto_return_flag>1</auto_return_flag>
                </splice_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• splice_insert_type – An 8-bit unsigned integer defining the type of insertion operation desired. These will result in the generation of one or more splice_info() sections with a splice_command_type field value of splice_insert with other inferred field values also being set within the resulting splice_info() section. The other inferred field values are noted with the discussion of each assigned value.

This API		Resulting SCTE 35 splice_insert() structure
splice_insert_type	Value	splice_event_ cancel_indicator	out_of_network_ indicator	duration_flag	splice_immediate_flag	auto_return_flag
reserved	0	n/a	n/a	n/a	n/a	n/a
spliceStart_normal	1	0	1	0 or 1	0	0 or 1
spliceStart_immediate	2	0	1	0 or 1	1	0 or 1
spliceEnd_normal	3	0	0	0	0	n/a (0)
spliceEnd_immediate	4	0	0	0	1	n/a (0)
splice_cancel	5	1	n/a (0)	0	n/a (0)	n/a (0)

• • spliceStart_normal section(s) occur at least once before a splice point. This interval should match the requirements of and serve to set up the actual insertion. It is recommended that if sufficient pre-roll time is given by the AS, the Injector send several succeeding splice_info_section() sections in response to a single splice_request message with a spliceStart_normal splice_insert_type value.
  • spliceStart_immediate sections may come once at the splice point’s exact location. The Injector shall set the splice_immediate_flag to 1 and the out_of_network_indicator to 1 in the resulting splice_info_section() section. Usage of “immediate mode” signaling is not recommended by and may result in inaccurate splices.
  • spliceEnd_normal sections come to terminate a splice done without a duration specified. They may also be sent to ensure a splice has terminated on schedule. The Injector sets the out_of_network_indicator to 0. If they are to terminate a spliceStart_normal with no duration specified, they should be sent prior to the minimum interval before the return point and carry a value for pre_roll_time, especially if terminating a long form insertion.
  • spliceEnd_immediate sections come to terminate a current splice before the splice point, or a splice in process earlier than expected. The Injector sets the out_of_network_indicator to 0 and the splice_immediate_flag to 1. The value of pre_roll_time is ignored.
  • splice_cancel sections come to cancel a recently sent spliceStart_normal section. The AS must supply the correct value of splice_event_id for the section to be cancelled. The Injector shall set the splice_event_cancel_indicator to 1.
• splice_event_id –  Splicers use the splice_event_id to determine when multiple messages refer to the same event (insertion opportunity). AS implementers should be aware of the splice_event_id uniqueness discussion. The Injector retains this value until the time indicated by the timestamp() is reached. 
• unique_program_id – Once set by the AS, the value of the field is relied upon for operations as defined by the syntax.
• pre_roll_time – An 16-bit field giving the time to the insertion point in milliseconds. This field is ignored for splice_insert_type values other than spliceStart_normal and spliceEnd_normal. If zero (and Component Mode is not in use) the Injector should set the splice_immediate_flag to 1 in the resulting splice_info_section.
• break_duration – A 16-bit field giving the duration of the insertion in tenths of seconds. If zero the Injector will not set a duration. This field is ignored for splice_insert_type values other than spliceStart_normal and spliceStart_immediate.
• avail_num – An 8-bit field giving an identification for a specific avail within the current unique_program_id. It may be zero to indicate its non-usage.
• avails_expected – An 8-bit field giving a count of the expected number of individual avails within the current viewing event. If zero, it indicates that avail_num has no meaning.
• auto_return_flag – If this field is non-zero and a non-zero value of break_duration is present, then the auto_return field in the resulting section will be set to one. This field is ignored for splice_insert_type values other than spliceStart_normal and spliceStart_immediate.

splice_null_request_data()

This is a Normal usage request. When this request is processed, an splice_null() splice_info_section will be generated and transmitted at the time indicated by the timestamp field. This request will normally be accompanied by one or more insert_descriptor requests.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>258</opID>
            <data>
                <splice_null_request_data></splice_null_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

start_schedule_download_request_data()

The standard allows for a schedule of avail times to be broadcast. This request readies the Injector to accept one or more schedule_definition_data() requests prior to transmission. Since a schedule can potentially have a large amount of data, provision has been made to download the data in smaller pieces.

The start schedule download message permits generation of a avail_descriptor. It is a Normal type message. The Injector must allocate sufficient memory to permit the accumulation of the maximum amount of section data specified by. A splice_request is not required in conjunction with splice_schedule.

If the schedule request is intended to be encrypted before being sent, then the Encrypted_DPI_data() structure must be included in the same multiple_operation_message data() structure as this start_schedule_download_data() structure. In this case ONLY, it must be placed in the data() structure before the start_schedule_download_data() structure is placed in the data() structure. By setting up the encryption before downloading the data, any intermediate sections that might be created can also be encrypted.

The splice_info_section() structure only allows one descriptor loop for an entire schedule splice_info_section. Therefore, any Supplemental requests that generate descriptors must be attached to the Start Schedule Request. These descriptors will then be inserted in all splice_info_section generated as a result of the schedule download.

If num_provider_avails is zero, then the provider avail id field is not being used and the value should be ignored and no avail_descriptor will be created.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>259</opID>
            <data>
                <start_schedule_download_request_data>
                    <num_provider_avails>0</num_provider_avails>
                </start_schedule_download_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

If num_provider_avails is non-zero, then the provider avail id field(s) must contain valid data.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>259</opID>
            <data>
                <start_schedule_download_request_data>
                    <num_provider_avails>2</num_provider_avails>
                    <provider_avail_id>116</provider_avail_id>
                    <provider_avail_id>268</provider_avail_id>
                </start_schedule_download_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• provider_avail_id – This is an optional 32-bit number which will be inserted into the splice_info_section() avail_descriptor.

time_signal_request_data()

This is a Normal request which will be generated and transmitted at the time indicated by the timestamp() field of the multiple_operation_message() structure. This request will normally be accompanied by one or more insert_descriptor requests.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>260</opID>
            <data>
                <time_signal_request_data>
                    <pre-roll_time>200</pre-roll_time>
                </time_signal_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• pre-roll_time – The splice splice_info_section may be sent by the automation system well in advance of when it is required. In order to support repeated sending of the same splice_info_section and to support multiple sections being outstanding simultaneously, this request supports the preloading of its parameters.
  The timestamp() indicates the time to process the splice_info_section. The pre-roll field indicates the amount of time, in milliseconds, after being processed that the action will occur. For the time_signal_request() this is the pre-roll for the associated descriptors. If this request arrives after the indicated time, the splice_info_section is sent as soon as possible.
  The timestamp field can indicate immediate processing (and therefore uses relative timing) or Deferred processing (which uses exact timing). In all cases, the signaling point is calculated relative to the time the Request is processed. The pre-roll field determines the exact delay period for the splice point relative to the Request being processed.
  If this Request is processed immediately on arrival, then the physical insertion of the time signal request is as soon as it is received. In the case of an exact timestamp using a UTC, VITC1 or GPI triggering2, the Request is processed at the indicated time.
  In the case when a component mode request is used to modify this basic request, the overall pre-roll time is not used. That is, this field is only used when the DPI splice_info_section produced is for a program mode splice. For component mode splicing, each component will have its own time stamp.

transmit_schedule_request_data()

This is a Normal usage request. When this request is processed, any schedule data saved in local memory is packetized and transmitted at the time indicated.

A downloaded schedule is not remembered after it has been transmitted, and the Injector may immediately free-up allocated local memory. The automation device is responsible for retransmitting upto-date schedule information when required.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>261</opID>
            <data>
                <transmit_schedule_request_data>
                    <cancel>1</cancel>
                </transmit_schedule_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• cancel – This flag is used to cancel any downloaded data and abort the transmission of the schedule in progress. A value of zero is normal, and indicates that the downloaded data can be transmitted at the time that the timestamp indicates. Any non-zero value indicates that the download should be cancelled.
  If this request is cancelled before being processed, then the entire schedule downloaded is also discarded. The effect is the same as if this request was sent with the cancel bit set.

component_mode_DPI_request_data()

The component mode DPI request is used for applications that wish to splice into some of the elementary streams of a program, and not others. This is an advanced method of DPI control that requires detailed knowledge of the structure of the program elements that exists in the same program as this DPI splice_info_section.

It is a Supplemental type request and must follow the splice_request_data() for which it applies within the data() structure of the multiple_operation_message. The presence of this request changes fundamental syntactic elements in the resulting splice_info_section() as the request will force component mode rather than program mode operation in the splicer.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>262</opID>
            <data>
                <component_mode_DPI_request_data>
                    <component_tag>0</component_tag>
                    <component_preroll>100</component_preroll>
                    <component_tag>1</component_tag>
                    <component_preroll>200</component_preroll>
                </component_mode_DPI_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• component_tag – This field contains the associated component tag for one of the elementary streams to be spliced. The loop provides a complete list of spliced elementary streams and the time at which the splice should occur.
• component_preroll – The overall request timestamp provides the exact time to process the message. In component mode, each component (i.e. Elementary stream PID) has a unique time at which its splice is to occur. The actual timestamp can be calculated by adding the pre-roll time to the timestamp() reference point.
  When operating in component mode splicing, the value of pre_roll_time given in the corresponding
  splice_request message is not used. This field is expressed in milliseconds.

encrypted_DPI_request_data()

The encrypted DPI message is used for applications that wish to use the built in security capabilities of under the direction of the Automation System. This message is sent in the clear, and the resulting section will be encrypted by the Injector before being formatted and placed in the output multiplex.

The actual control words to use by the Injector must have been previously provisioned by the PAMS or by the AS (via the update_ControlWord request) for the particular control word index, or the resulting splice_info_section() will not be placed in the outgoing TS, the data() discarded, and an error code returned by the Injector. In a uni-directional communication system, the error return path shall be notification of the PAMS operator.

This is a Supplemental usage request and must follow the associated splice_request_data() in the data() structure of the multiple_operation_message() for which it applies. If component_mode_DPI_data() structures are also present in the multiple_operation_message data() structure, then the encrypted_DPI_data() follows the final occurrence of component_mode_DPI_data().

When this request is present, the encrypted_packet bit shall be set in the resulting splice_info_section().

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>263</opID>
            <data>
                <encrypted_DPI_request_data>
                    <encryption_algorithm>2</encryption_algorithm>
                    <CW_index>0</CW_index>
                </encrypted_DPI_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• encryption_algorithm – This field carries the value of the 6-bit field.
• CW_index – An 8 bit unsigned integer which conveys which Control Word (key) is to be used to
  encrypt and decrypt the message.

insert_descriptor_request_data()

This is a Supplemental usage request. When this request is processed, the descriptor image will be copied into the descriptor loop of the associated splice_info_section being created. One of the Normal requests must exist earlier in the same data() buffer and these descriptors will be added to any section generated by that Normal request.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>264</opID>
            <data>
                <insert_descriptor_request_data>
                    <descriptor_count>5</descriptor_count>
                    <descriptor_image>2A31323323</descriptor_image>
                </insert_descriptor_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• descriptor_count – This field encodes the number of descriptors following.
• descriptor_image – This field carries a complete image of a standard descriptor, which follows MPEG-2 rules and has its length as the second byte of the descriptor. This request is used to inject proprietary, or future standard descriptors into a request without need for specific knowledge of the contents of the descriptor to be injected. For standard descriptors, the recommended method is to update this protocol to include a request for the new descriptor.

insert_DTMF_descriptor_request_data()

This is a Supplemental usage request. This request creates an image of the DTMF descriptor. One specific note about this descriptor. The pre-roll field found in this descriptor is intended to be the same value as that used for the associated splice_request. The DTMF descriptor allows for tenths of a second resolution, and the splice_request allows millisecond resolution. One should ensure that both requests use the same pre-roll value to provide a consistent program insertion on both analog and digital systems.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>265</opID>
            <data>
                <insert_DTMF_descriptor_request_data>
                    <pre-roll>0</pre-roll>
                    <dtmf_length>5</dtmf_length>
                    <DTMF_char>*</DTMF_char>
                    <DTMF_char>1</DTMF_char>
                    <DTMF_char>2</DTMF_char>
                    <DTMF_char>3</DTMF_char>
                    <DTMF_char>#</DTMF_char>
                </insert_DTMF_descriptor_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• pre-roll – The pre-roll time encodes the number of tenths of seconds before the splice_point signaled in the resulting section that a DTMF tone sequence should finish being emitted. To allow for processing time, the pre-roll signaled in the SCTE 35 message should be greater than this value.
• dtmf_length – This indicates the length of the following loop in bytes.
• DTMF_char – This field carries one character of a DTMF sequence to be output by an IRD. This field should contain one of the ASCII characters ‘0’ through ‘9’, ‘*’, ‘#’, and ‘A’ through ‘D’.

insert_avail_descriptor_request_data()

This is a Supplemental usage request. When this request is processed, an avail_descriptor() shall be added to the descriptor loop of the associated splice_info_section being created. The Normal request to which it applies must exist earlier in the same data() buffer.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>266</opID>
            <data>
                <insert_avail_descriptor_request_data>
                    <num_provider_avails>3</num_provider_avails>
                    <provider_avail_id>16</provider_avail_id>
                    <provider_avail_id>39</provider_avail_id>
                    <provider_avail_id>48</provider_avail_id>
                </insert_avail_descriptor_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• num_provider_avails – If this field is zero, then the provider_avail_id field is not being used and the
  value shall be ignored. If this field is non-zero, then the num_provider_avails field is the repetition count for the provider_avail_id field. Also, the Injector must include an avail_descriptor()in the DPI splice_info_section created.
  provider_avail_id – This is an optional 32-bit field which may be inserted into the resulting splice_info_section. If the value of num_provider_avails is zero, this field shall be ignored and no avail_descriptor() shall be created.

insert_segmentation_descriptor_request_data()

This is a Supplemental usage request, and creates a Segmentation descriptor. The program_segmentation_flag shall be set to one in the resulting splice_info_section(). If the user needs to support component mode segmentation, then an insert_descriptor request should be used to directly format this descriptor.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>267</opID>
            <data>
                <insert_segmentation_descriptor_request_data>
                    <segmentation_event_id>138</segmentation_event_id>
                    <segmentation_event_cancel_indicator>0</segmentation_event_cancel_indicator>
                    <duration>0</duration>
                    <segmentation_upid_type>0</segmentation_upid_type>
                    <segmentation_upid_length>0</segmentation_upid_length>
                    <segmentation_upid>0</segmentation_upid>
                    <segmentation_type_id>0</segmentation_type_id>
                    <segment_num>0</segment_num>
                    <segments_expected>0</segments_expected>
                    <duration_extension_frames>0</duration_extension_frames>
                    <delivery_not_restricted_flag>0</delivery_not_restricted_flag>
                    <web_delivery_allowed_flag>0</web_delivery_allowed_flag>
                    <no_regional_blackout_flag>0</no_regional_blackout_flag>
                    <archive_allowed_flag>0</archive_allowed_flag>
                    <device_restrictions>0</device_restrictions>
                    <insert_sub_segment_info>0</insert_sub_segment_info>
                    <sub_segment_num>0</sub_segment_num>
                    <sub_segments_expected>0</sub_segments_expected>
                </insert_segmentation_descriptor_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• segmentation_event_id – A four byte (32-bit) unique segmentation event identifier.
• segmentation_event_cancel_indicator – A one byte flag that when set to ‘1’ indicates that a previously sent segmentation event, identified by segmentation_event_id, has been cancelled.
• duration - A two byte (16-bit) field giving the duration of the program segment in whole seconds. A zero value is legal and results in the segmentation_duration_flag in the resulting section being set to ‘0’.
• segmentation_upid_type – An one byte field that specifies the type of “UPID” utilized in this program. There are multiple types allowed to insure that programmers will be able to use an id that their systems support.
• segmentation_upid_length – An one byte field that specifies the length in bytes of the segmentation_upid. If there is no segmentation_upid data, segmentation_upid_length shall be set to 0.
• segmentation_upid – An variable-length field that specifies the “UPID” value for this segment.
• segmentation_type_id – An one byte field which designates type of segmentation and takes values.
• segment_num – A one byte field that provides identification for a specific segment within a collection of segments.
  segments_expected – A one byte field that provides a count of the expected number of individual segments within a collection of segments.
• duration_extension_frames – A one byte field that shall carry a value in the range from 0 to the value of the greatest integer less than frame rate, which shall be the number of frames in the fractional second not included in duration. The total duration of the program segment is duration seconds plus duration_extension_frames frame times. If duration is 0 this field carries no meaning.
  Note: Content length is described in terms of the number of ticks of a 90 kHz MPEG counter. A value in these units is calculated from duration and duration_extension_frames by converting duration, converting duration_extension_frames and adding the resulting values.
• delivery_not_restricted_flag – A one byte flag that when set to 1 indicates there is no need for external checks prior to delivery. A value of 0 indicates the content requires external checks.
• web_delivery_allowed_flag – A one byte flag that when set to 1 indicates web delivery is allowed.
• no_regional_blackout_flag – A one byte flag that when set to 1 indicates there is not a regional blackout.
• archive_allowed_flag – A one byte flag that when set to 1 indicates the content is archiveable.
• device_restrictions – A one byte field which designates type of segmentation.
• insert_sub_segment_info - A one byte flag that indicates whether sub_segment_num and sub_segments_expected are included in the resultant segmentation descriptor. If the value is 1, the values shall be inserted. If the value is 0 or null, the values shall not be inserted. insert_sub_segment_info is not passed in the resultant segmentation descriptor.
• sub_segment_num – A one byte field that provides identification for a specific sub-segment within a collection of segments.
• sub_segments_expected – A one byte field that provides a count of the expected number of individual sub-segments within a collection of sub-segments.

Note: insert_sub_segment_info, sub_segment_num and sub_segments_expected can form an optional appendix to the segmentation descriptor. The presence or absence of this optional data block is determined by the descriptor loop’s data_length.

proprietary_command_request_data()

This is a Normal usage request, and allows for proprietary extension to the protocol. The data_length field functions in the normal manner for the data() loop within the context of multiple_operation_message().

The opID variable for the proprietary_command_data() is one of the values for user defined requests. In addition to using this opID value, each company that wishes to define proprietary commands should register with SMPTE-RA for a proprietary id value. This permits the company to create one or more proprietary commands that are uniquely theirs, each identified by their respective proprietary_command_data() structure.

The data_length field in multiple_operation_message() the must be correctly set to reflect the number of bytes utilized by the remainder of the request which follows the data_length field itself. Failure to do so will result in the commands not being processed correctly.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>268</opID>
            <data>
                <proprietary_command_request_data>
                    <proprietary_id>0</proprietary_id>
                    <proprietary_command>259</proprietary_command>
                    <proprietary_data>2A31323323</proprietary_data>
                </proprietary_command_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• proprietary_id – This number is a 32-bit identifier that has been registered with SMPTE-RA for a specific company. The contents of the command and the definition of how to process the command are proprietary.
• proprietary_command – This is a field, similar to the opID tag, which identifies individual proprietary commands for each proprietary id. The meaning of this field is not defined, but must follow the basic rules for the protocol.
• proprietary_data() – This is a variable length field that contains the data for the specific proprietary
  command. The amount of data contained in the command can be determined from the overall length field for this command.

The definition for this data is not specified, but it must follow the basic rules for the protocol.

schedule_component_mode_request_data()

The schedule_component_mode request is used for applications that wish to splice into some of the elementary streams of a program, and not others. This is an advanced method of DPI control that requires detailed knowledge of the structure of the program elements that exists in the same program as this DPI message. If component mode is used for a specific avail, then this structure may be delivered along with the associated schedule_definition_data() structure to define the components that will be spliced in that avail.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>269</opID>
            <data>
                <schedule_component_mode_request_data>
                    <component_tag>0</component_tag>
                    <time>
                        <seconds>1343401438</seconds>
                    </time>
                    <component_tag>1</component_tag>
                    <time>
                        <seconds>1343405038</seconds>
                    </time>
                </schedule_component_mode_request_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• component_tag – This field contains the associated component tag for one of the elementary streams to be spliced. The loop provides a complete list of spliced elementary streams and the time at which the splice should occur.
  time() – A 32-bit unsigned integer quantity representing the time of the signaled splice event as the number of seconds since 00 hours UTC, January 6, 1980, with the count of intervening leap seconds included.

schedule_definition_data()

This request allows a single avail definition to be collected by the Injector. Using the overall message structure, it is possible to deliver multiple splice point definitions in the same resultant splice_info_section(). This request will be issued once per splice event to be included in that splice_info_section().

A splice definition being transmitted must be contained within a splice_info_section() structure. This section has a limited size of 4096 bytes, although some implementations may have lower maximum sizes. If a schedule being transmitted exceeds the local maximum memory allocated, it is possible that the first resultant section could be formatted, packetized, and placed in the Transport Stream before the transmit_schedule request is sent to force transmission and thus make space for more schedule data in the local memory of the Injector.

This is a Supplemental request and must follow a start_schedule_download_data() in the data() structure of a multiple_operation_message().

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>270</opID>
            <data>
                <schedule_definition_data>
                    <splice_schedule_command>1</splice_schedule_command>
                    <splice_event_id>684</splice_event_id>
                    <time>
                        <seconds>1343401438</seconds>
                    </time>
                    <unique_program_id>1</unique_program_id>
                    <auto_return>0</auto_return>
                    <break_duration>0</break_duration>
                    <avail_num>0</avail_num>
                    <avails_expected>0</avails_expected>
                </schedule_definition_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• splice_schedule_command – This field indicates if the associated splice_schedule() section generated will be a splice insert (away from the network) or a splice return to the network. A cancellation may also be signaled.

splice_schedule_command	Value assigned
reserved	0
splice_insert	1
reserved	2
splice_return	3
reserved	4
splice_cancel	5

• splice_event_id – This is a 32-bit number that will be coded into the splice_event_id in the final splice_info_section.
• time() – A 32-bit unsigned integer quantity representing the time of the signaled splice event as the number of seconds since 00 hours UTC, January 6, 1980, with the count of intervening leap seconds included.
• unique_program_id – This is a 16-bit field.
• auto_return – If this field is non-zero, then the auto_return field in the resulting break_duration() of
  the section will be set to one.
• break_duration – A 16-bit field giving the duration of the insertion in tenths of seconds. If break_duration is set to zero, then the resulting splice_schedule() section will not include the break_duration() and the flags auto_return and duration_flag will be set to zero.
• avail_num – This is an 8-bit number indicating which avail within the program. It will be coded as a decimal number from 1 to 255. A value of zero indicates that the avail fields are not being used. If this field is coded as zero, so should the avails_expected field.
• avails_expected – This is an 8-bit number indicating how many avails to expect within the program currently being described. It will be coded as a decimal number from 1 to 255. A value of 0 indicates that the avail fields are not being used. If this field is coded as zero, so should the avail_num field.

insert_tier_data()

This is a Supplemental usage request. When this request is processed, the tier value shall be copied into the associated splice_info_section being created. One of the Normal requests shall be placed earlier in the same data() buffer and this value will be added to the section generated by that Normal request. If this request is missing, the Injector shall insert the value of 0xFFF into the tier field in the associated splice_info_section being created.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>271</opID>
            <data>
                <insert_tier_data>
                    <tier_data>0</tier_data>
                </insert_tier_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• tier_data – A field with the most significant nibble set to 0x0 and containing, in the lower 12-bits.

insert_time_descriptor()

This is a Supplemental usage request. When this request is processed, the time_descriptor() shall be associated with the Normal request that shall have been placed earlier in the same data() buffer and this structure will be added the section generated by that Normal request.

The request requires the AS to supply an exact PTP [TAI] sample to be inserted in the resulting message.

This request may be associated with splice_insert(), splice_null() and time_signal() requests. The injector will make no effort to verify that no other Normal request is being used.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>272</opID>
            <data>
                <insert_time_descriptor>
                    <TAI_seconds>10</TAI_seconds>
                    <TAI_ns>100</TAI_ns>
                    <UTC_offset>0</UTC_offset>
                </insert_time_descriptor>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• TAI_seconds – This 48-bit number is the TAI seconds value. unsignedLong with a restriction up to 48 bits (281474976710656).
• TAI_ns – This 32-bit number is the TAI nanoseconds value. unsignedInt
• UTC_offset – This 16-bit number shall be used in the conversion from TAI time to UTC or NTP time per the following equations.

insert_audio_descriptor

This is a Supplemental usage request. When this request is processed, the audio_descriptor() shall be associated with the Normal request that shall have been placed earlier in the same data() buffer and this structure will be added the section generated by that Normal request.

This request may be associated with splice_insert(), splice_null() and time_signal() requests. The injector will make no effort to verify that no other Normal request is being used.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>273</opID>
            <data>
                <insert_audio_descriptor>
                    <audio_count>2</audio_count>
                    <component_tag>120</component_tag>
                    <ISO_code>0</ISO_code>
                    <Bit_Stream_Mode>0</Bit_Stream_Mode>
                    <Num_Channels>2</Num_Channels>
                    <Full_Srvc_Audio>0</Full_Srvc_Audio>
                    <component_tag>121</component_tag>
                    <ISO_code>0</ISO_code>
                    <Bit_Stream_Mode>0</Bit_Stream_Mode>
                    <Num_Channels>2</Num_Channels>
                    <Full_Srvc_Audio>0</Full_Srvc_Audio>
                </insert_audio_descriptor>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• audio_count – The value of this flag is the number of audio PIDs in the program.
  There is no entry in the XML schema for audio_count. The value shall be derived when converting an XML representation of the audio_descriptor() to Bit Stream Format based on the number of audio channels.
• component_tag – An optional 8-bit value that identifies the elementary PID stream containing the audio channel that follows. If used, the value shall be the same as the value used in the stream_identifier_descriptor() to identify that elementary PID stream. If this is not used, the value shall be 0xFF and the stream order shall be inferred from the PMT audio order.
• ISO_code – This field is a 3-byte language code defining the language of this audio service which shall correspond to a registered language code contained in the Code column of the registry.
• Bit_Stream_Mode – This 3-bit code indicates the type of service that the bit stream conveys.

bsmod	acmod	Type of Service
‘000’	any	main audio service: complete main (CM)
‘001’	any	main audio service: music and effects (ME)
‘010’	any	associated service: visually impaired (VI)
‘011’	any	associated service: hearing impaired (HI)
‘100’	any	associated service: dialogue (D)
‘101’	any	associated service: commentary (C)
‘110’	any	associated service: emergency (E)
‘111’	‘001’	associated service: voice over (VO)
‘111’	‘010’ - ‘111’	main audio service: karaoke

• Num_Channels – This is a 4-bit field that indicates the number of channels in the AC-3 elementary stream. When the MSB is 0, the lower 3 bits are set to the same value as the acmod field in the AC-3 elementary stream. When the MSB field is 1, the lower 3 bits indicate the maximum number of encoded audio channels (counting the lfe channel as 1).

num_channels	Audio coding mode (acmod)		num_channels	Number of encoded channels
‘0000’	1 + 1²		‘1000’	1
‘0001’	1/0		‘1001’	≤ 2
‘0010’	2/0		‘1010’	≤ 3
‘0011’	3/0		‘1011’	≤ 4
‘0100’	2/1		‘1100’	≤ 5
‘0101’	3/1		‘1101’	≤ 6
‘0110’	2/2		‘1110’	Reserved
‘0111’	3/2		‘1111’	Reserved

• Full_Srvc_Audio – This is a 1-bit field that indicates if this audio service is a full service suitable for presentation, or a partial service which should be combined with another audio service before presentation. This bit should be set to a ‘1’ if this audio service is sufficiently complete to be presented to the listener without being combined with another audio service (for example, a visually impaired service which contains all elements of the program; music, effects, dialogue, and the visual content descriptive narrative). This bit should be set to a ‘0’ if the service is not sufficiently complete to be presented without being combined with another audio service (e.g., a visually impaired service which only contains a narrative description of the visual program content and which needs to be combined with another audio service which contains music, effects, and dialogue).

delete_ControlWord_data()

This is a Control usage request. If an Encryption Group is no longer required, then this request can be sent to remove the Control Words from the Injector’s database. This is only really necessary if one wishes to prevent messages from being sent with this Control Word, since empty Control Word index slots results in an alarm if an attempt is made to use it.

The Injector shall not produce an alarm if an undefined Control Word is deleted. This allows the AS to delete all control words without actually knowing what Control Words are present, so the Control Word database can be reinitialized.

In some architectures, the control of encryption services may be done by the PAMS rather than an automation controller. In these cases, this message would not be used, since it would delete the control words downloaded by the PAMS.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>768</opID>
            <data>
                <delete_ControlWord_data>
                    <CW_index>116</CW_index>
                </delete_ControlWord_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• CW_index – This field specifies the control word index used to reference the control word database. This field ranges from 0 to 255.

update_ControlWord_data()

This is a Control usage request, and serves to setup an authorization group. Changing the Control Words for a service is expected to be a relatively rare occurrence. This request allows the encryption group to be downloaded and then used by subsequent encrypted_DPI requests. This message will replace any existing Control Words in the specified index position.

In some architectures, the control of encryption services may be done by the PAMS rather than the AS. In these cases, this message would not be used, since it would overwrite the Control Words downloaded by the system controller. The automation system may still need to know which messages are to be encrypted and which CW_index to assign to specific messages.

<SCTE104 line=12>
    <multiple_operation_message> 
        <protocol_version>0</protocol_version>
        <AS_index>0</AS_index>
        <message_number>214</message_number>
        <DPI_PID_index>0</DPI_PID_index>
        <SCTE35_protocol_version>0</SCTE35_protocol_version>
        <timestamp>
            <time_type>2</time_type>
            <hours>16</hours>
            <minutes>50</minutes>
            <seconds>37</seconds>
            <frames>4</frames>
        </timestamp>
        <ops>
            <op> 
            <opID>769</opID>
            <data>
                <update_ControlWord_data>
                    <time_signal_request_data>
                        <CW_index>116</CW_index>
                        <CW_A>controlword</CW_A>
                        <CW_B>4</CW_B>
                        <CW_C>5</CW_C>
                    </time_signal_request_data>
                </update_ControlWord_data>
            </data> 
            </op>
        </ops>
    </multiple_operation_message>
</SCTE104>

• CW_index – This field specifies the control word index used to reference the control word database. This field may range from 0 to 255. The index sent indicates which of the 256 Control Word set should be replaced in the Injector’s Control Word database. Each Control Word set is 3 64-bit numbers. The two Single DES encryption modes only use CW_A, while Triple-DES requires all 3 64-bit Control Words. All 3 fields are always sent, but if Triple-DES is not used, CW_B and CW_C shall be zeros.
• CW_A – ControlWord_A, a 64-bit value which is always used. In the case of the two Single DES encryption modes, CW_A is used alone (CW_B and CW_C are zero filled), while Triple-DES requires all 3 64-bit control words.
• CW_B – The second 64-bit number sent as a Control Word. This value is normally zero unless TripleDES encryption is utilized, in which case it carries the second of the three control word values.
• CW_C – The third 64-bit number sent as a Control Word. This value is normally zero unless TripleDES encryption is utilized, in which case it carries the third of the three control word values.