Before incoming services can be passed to an outgoing TS, the output port must be provided with one or more outgoing TSs. Since an ASI output port only has one TS, each ASI port is by default provided with one TS with default settings. In contrast with the ASI output ports, the Ethernet ports accept multiple outgoing TSs.
During the TS creation process, particular parameters are configured with default values. To change these default values, see Changing Default Values of Outgoing Transport Stream Settings .
When the outgoing TSs are created, the corresponding parameters can be changed as described in Changing Standard Settings of Outgoing Transport Streams and Changing Advanced Settings of Outgoing Transport Streams.
For each new created MPTS, the SID of the services can automatically be incremented. Therefore, the Auto Increment SID parameter must be enabled and the Start SID value must be specified. For each new created SPTS, the Start SID value is then used as default SID for the service. See Using the SID Auto Increment Feature for Newly Created TSs.
Using TS Auto
TS auto pass rules
for an incoming TS can be assigned to each outgoing TS. When TS auto pass rules
are assigned to an outgoing TS, the complete content of the incoming TS is
passed to this outgoing TS, including EMMs and unreferenced components. TS auto
pass rules also determine the content of the outgoing TS if the content of the
incoming TSs varies. Meaning, when new services, EMMs, or unreferenced
component are added to the incoming TS, this new content is automatically
passed to the outgoing TS depending on the assigned TS auto pass rules.
The following TS
auto pass rules can be assigned:
Pass Unreferenced PIDs — All unreferenced components are automatically passed to the output.
Pass EMMs — All EMMs are automatically passed to the output.
Pass Services — All services are automatically passed to the output.
We advise you against performing processes such as forcing PIDs (packet identifier), PID remapping, passing components or services from other incoming TSs, DPI (digital program insertion), scrambling, and so on, on the content of outgoing TSs with Pass Unreferenced PIDs rule assignment, without the knowledge of the packet identifiers of the unreferenced components that can be added to the corresponding incoming TS. Otherwise conflicts between unreferenced components passed from the input and components present at the output can arise resulting in CC errors.
The TS auto pass rules can automatically be assigned during the outgoing TS creation process by passing an incoming TS to a port. The TS auto pass rules can also be assigned to an existing outgoing TS. When TS auto pass rules are automatically created during the TS creation process, the rules automatically refer to the passed incoming TS. The PSI/SI/PSIP (program-specific information, service information, and program and system information protocol) information of the outgoing TS to which TS auto pass rules are assigned, is by default regenerated by the DCM (Output Mode = Generate). To change this mode, see Changing the PSI/SI/PSIG Output Mode.
or EMMs are removed from the input, their nodes are indicated by their
nonpresent icon and configuration settings are kept. Removing these nodes must
be done manually. When unreferenced components are removed, all references at
the output are removed.
are passed to an outgoing TS with pass services rule assignment and services,
which are still present at the input, are manually removed from the outgoing
TS, these services are passed again when the service population of the incoming
When services are added to an incoming TS, which is passed with pass services rule assignment to an outgoing TS with a TR all services rate control group, the services are automatically added to the rate control group. These new services get default configuration settings.
When services are added to an incoming TS, which is passed with Pass Services rule assignment to an outgoing TS with a TR selective services rate control group, the services are not added to a rate control group.
When no TS auto pass
rules are assigned to an outgoing TS, no unreferenced components are passed
from the incoming TS to the output and the content of the outgoing TS remains
static. Meaning, when new services, unreferenced component, or EMMs are added
to the incoming TS, this new content is not automatically passed to the output.
Using Transparent Loop Through TSs
To pass an incoming TS to the output without manipulating the content of the TS, the transparent loop through feature can be used. This feature transparently passes incoming TSs (including stuffing) to the output and is useful for interface conversion (ASI [asynchronous serial interface] to GbE [Gigabit Ethernet] or conversely) or for monitoring purposes.
When an input TS is transparently passed to the output, all input components are dynamically passed to the outgoing TS. Extra configuration to the outgoing TS, service, and components is no longer possible and advanced MPEG processing, such as rate control, scrambling, and so on, cannot be done. Only interface related settings, such as the destination IP address, the destination UDP port, VLAN (virtual local area network), RTP (real-time transport protocol)/UDP, and FEC (forward error correction), can be modified.
When the card, to which the TS is passed, is provided with the coprocessor functionality, the TS can be delayed from 5 to 100 ms. For more information about this feature, see Delaying Transparent Passed Transport Streams.
To pass an incoming TS transparently to an output, see Passing Transport Streams Transparently to the Output.
In the Outputs tree, transparent loop through TSs are indicated by a white TS icon.
A transparent loop through TS branch has no children. Meaning, the services and components of such branch are not displayed because those are the same as at the input.
Incoming TSs without PAT can transparently be passed.
When an incoming TS with errors is transparently passed to the output, these errors are also present in the outgoing TS.
The packet format of an outgoing TS on an ASI port is 188 bytes with output mode set to Packet, independent of the packet format of the incoming TS.
To protect the content of transparent loop through TS, TS backup is possible. For more information about TS backup, see Transport Stream Backup.
To facilitate the DCM configuration, different TS creating methods are foreseen:
outgoing TSs by adding individual TSs. TS auto pass rules must be manually
assigned if necessary.
Creating an outgoing TS by passing one or multiple incoming TSs to a port. For an Ethernet port, TS auto pass rules can be automatically assigned. For an ASI port, the existing outgoing TS is replaced by the incoming TS and TS auto pass rules are automatically assigned.
multiple outgoing TSs by passing incoming TSs to a port.
Creating multiple SPTSs (single program transport streams) by passing individual incoming services to an Ethernet port. TS auto pass rules must be assigned manually if necessary.
Creating a transparent loop through TS.
During the TS creation process on an Ethernet port, an IP address must be assigned. Assigning multicast IP addresses to outgoing TSs has the following restrictions.
For SSM, use address from the range 22.214.171.124 - 126.96.36.199. Exception: addresses 188.8.131.52 ... 184.108.40.206 are reserved.
For ASM, use address from the range 220.127.116.11 - 18.104.22.168. Exception: addresses 22.214.171.124 ... 126.96.36.199 are reserved.
Streaming MPEG data packets to addresses in the range 188.8.131.52 - 184.108.40.206 is discouraged because this may cause problems on, for instance, routers.
For more information, refer to RFC 3171 or to Cisco's Guidelines for Enterprise IP Multicast Address Allocation.
During, for instance, a service or TS backup transition, a PCR discontinuity at the output of the DCM may occur. Some downstream equipment uses the PCR for dejittering purposes and does not tolerate a PCR discontinuity. To deal with this, the PCR continuity feature can be enabled to keep the PCR continuous. For more information about this feature, see Configuring the Coprocessor Functionality of an Interface Card.