

# About the Conductor Live solution
About the Conductor Live solutionMajor revision to the guide

We have made a major revision to the guide to bring it up to date with the latest features, particularly with the new launch of AWS Elemental Statmux.Cross-version release of the guide

This guide has been modified so that it isn't for a specific version of Elemental Live. The configuration procedure doesn't change from version to version. Version 3.22 release

First release of the 3.22 software version.

AWS Elemental Conductor Live lets you create and manage channels on AWS Elemental Live and/or MPTSes on AWS Elemental Statmux. 

Each of the three products — AWS Elemental Conductor Live, AWS Elemental Live and AWS Elemental Statmux — runs on its own node. Conductor Live is a *management node*. Elemental Live and Elemental Statmux node are each *worker nodes*. And all the nodes are organized in a *cluster.* 

A cluster contains at least one Conductor Live node and one Elemental Live node. If you want to produce MPTSes, a cluster contains at least one Conductor Live node, one Elemental Live node, and one Elemental Statmux node. 

# Working with Conductor Live
Working with Conductor LiveCross-version release of the guide

This guide has been modified so that it isn't for a specific version of Elemental Live. The configuration procedure doesn't change from version to version. Version 3.22 release

First release of the 3.22 software version.

AWS Elemental Conductor Live lets you create and manage channels on AWS Elemental Live and/or MPTSes on AWS Elemental Statmux. Each of the three products—Conductor Live, Elemental Live and Elemental Statmux—runs on its own node. Conductor Live is a *management node*. Elemental Live and Elemental Statmux node are each *worker nodes*. 

All the nodes are organized in a *cluster.* 

Broadly speaking, there are two ways to work with the Conductor Live suite of products:
+ Create and run events (which are called channels in Conductor Live). You use Conductor Live to create the channel on an Elemental Live node that is in the cluster. You use Conductor Live to start and control the channel.

  For this scenario, the cluster includes Conductor Live and Elemental Live nodes.
+ Create and run MPTSes. You use Conductor Live to create an MPTS on an Elemental Statmux node that is in the cluster. You use the Conductor Live to add Elemental Live channels to the MPTS. You use Conductor Live to start and control the MPTS.

A cluster contains at least one Conductor Live node and one Elemental Live node. If you want to produce MPTSes, a cluster contains at least one Conductor Live node, one Elemental Live node, and one Elemental Statmux node. 

**Topics**
+ [

# General information
](cl3-general.md)
+ [

# Software versions
](cl3-software-versions.md)
+ [

# Licenses
](cl3-software-licenses.md)
+ [

# Centralized management
](centralized-management.md)
+ [

# Redundancy and failover
](redundancy-and-failover.md)

# General information


**Assumptions**

We assume that you are already familiar with Elemental Live. You know how to create an event using Elemental Live, and you are familiar with the various features of Elemental Live.

We don't make this assumption with AWS Elemental Statmux. Therefore, this guide explains everything you need to know to create and manage MPTSes using AWS Elemental Statmux. However, we do assume that you are familiar with SPTSes (single program transport streams) and MPTSes (multiple program transport streams). You should be familiar with the business uses of SPTS and MPTS, and you should be familiar with the SI/PSI tables used in these streams.

We also assume that you are know how to log into a Linux session, in order to work via the command line interface.

**Supported browsers**

Most browsers that are newer than two years old will support all the features of the AWS Elemental Conductor Live web interface. Supported browsers include the current versions of Firefox and Chrome. We recommend Firefox.

**JavaScript Warning**

JavaScript is required for the Conductor Live web interface. If JavaScript is disabled, the web interface presents a warning and provides general guidance to resolve the error.

**Related documentation**

For additional information about the configuration and use of Conductor Live and Elemental Live, see the following: 
+ [AWS Elemental Conductor Live API Reference](https://docs.aws.amazon.com/elemental-cl3/latest/apireference/about-this-manual.html)
+ [AWS Elemental Conductor Live Configuration Guide](https://docs.aws.amazon.com/elemental-cl3/latest/configguide/)
+ [AWS Elemental Live API Reference](https://docs.aws.amazon.com/elemental-onprem/latest/pdf/live-api.pdf)
+ [AWS Elemental Live User Guide](https://docs.aws.amazon.com/elemental-live/latest/ug)

# Software versions


This guide applies to version 2.20.3 and later of Elemental Live and Elemental Statmux, and to version 3.20.3 and later of Conductor Live. 

The AWS Elemental implementation of a statmux solution was relaunched in these versions. The earlier implementation is no longer supported.

# Licenses

+ You need the Statmux rate control add-on package for each Elemental Live node where you will produce SPTS programs that will go into the MPTS. For more information, see the section about add-on packages in the AWS Elemental Live user guide.
+ You don't need an add-on package for Elemental Statmux. The general license for Elemental Statmux is sufficient.
+ You don't need an add-on package for Conductor Live. The general license for Conductor Live is sufficient.

# Centralized management


Conductor Live lets you control both Elemental Live nodes and AWS Elemental Statmux nodes. These workers nodes must be in a Conductor Live cluster.

With Conductor Live, you do not work on each individual Elemental Live or AWS Elemental Statmux node. Instead, you work on all nodes from one centralized web interface on the Conductor Live. 

**Conductor Live and Live Nodes**

Centralization via Conductor Live has several advantages for encoding work:
+ You create and run events (referred to as *channels*) from Conductor Live, specifying which node the channel is to run on. It is possible to move channels from one node to another. 
+ You create profiles (which hold most of the data for channels) in Conductor Live. Any channel on any node can use the same profile. With Elemental Live as standalone, there is no profile sharing across nodes.
+ You can view the activity on all nodes in a cluster. The Elemental Live interface lets you view activity only for the individual standalone node.
+ You can start and stop channels on any node in the cluster. You can add or delete a channel on any node.
+ You can perform some changes on several channels at once, even if those channels are not on the same node. For example, if several channels (distributed across several nodes) all use the same profile, you can change all those channels so that they use a new profile (that is a revised version of the original profile).

**Conductor Live and AWS Elemental Statmux**

Centralization via the Conductor Live also has several advantages for creation of an MPTS:
+ You can create an MPTS and add channels to that MPTS from Conductor Live. 
+ You can start and stop an MPTS. 
+ You can add or remove a channel on any AWS Elemental Statmux node. 
+ You can change properties of an MPTS in order to change the behavior of the MPTS. 
+ You can view the activity on all AWS Elemental Statmux nodes in a cluster

# Redundancy and failover


Running Elemental Live events and Elemental Statmux MPTSes in Conductor Live lets you implement several resiliency features. These features help reduce outages in your workflows.

To clarify the terms:
+ *Resiliency *refers to the ability to continue when errors occur. 
+ *Redundancy *refers to duplication of hardware or software components to protect against single points of failure. Therefore, redundancy is one way to achieve resiliency. 

Conductor Live offers resiliency solutions in all areas of the workflow:
+ Node redundancy for Conductor Live nodes, Elemental Live nodes, and Elemental Statmux nodes. This redundancy protects against failure of an entire node.

  Node redundancy is the foundation for some resiliency options within the worker nodes. For example, within Elemental Live, there are some resiliency options that only work with specific types of redundancy. Keep this fact in mind when planning node redundancy.

  When you first deploy your Conductor Live cluster, you should plan redundancy for the nodes in the cluster.

  After your initial deployment, you should review your node redundancy design when you add more nodes or when your workflows change dramatically.

  For more information about planning node redundancy, see [Setup: Planning resiliency in a cluster](cl3-resiliency.md). 
+ Resiliency features in different types of workflows:
  + Encoding workflows: workflows that involve only Elemental Live.
  + MPTS workflows: workflows that involve Elemental Live and Elemental Statmux.

  As part of the design procedure for a workflow, decide which resiliency features you want to implement. An encoding workflow and in an MPTS workflow have slightly different resiliency options.

  For more information about resiliency features, see [Resiliency features in Elemental Statmux](worker-nodes-other-resiliency.md).

# Working with AWS Elemental Live in a cluster
Working with Elemental Live

Running AWS Elemental Live in a AWS Elemental Conductor Live cluster provides two key benefits that are not available when you run Elemental Live in stand-alone mode:
+ Centralized creation and control of channels on the nodes. 
+ Resiliency through configuration of *redundancy groups* of nodes. 

**Topics**
+ [

# Components of Elemental Live in a cluster
](el-cluster-usage-components.title.md)
+ [

# Comparison of profiles
](comparison-of-profiles-in-cl3-vs-live.md)

# Components of Elemental Live in a cluster
Components of Elemental Live

When you work with Elemental Live using Conductor Live, you work with channels (events), profiles, and nodes. 

**Channels and Events**

A *channel* is a session that decodes and encodes a live video stream or a video file and produces a live output. Video input comes into the channel and video output is the final outcome of the channel. All the encoding activity occurs within a channel. 

The channel that you create using Conductor Live becomes an event on the Elemental Live node.

**Profiles**

The encoding activity is defined in a *profile*: the information contained in the profile includes the source of the video input, the kinds of processing that the video will undergo, the types of output protocols to produce (for example, Archive or UDP/TS), and the types of outputs (the containers).

**Nodes**

The physical computer where the video activity is handled is called a *node*. When you are deploying Conductor Live, nodes are grouped into a cluster: by adding a node to a cluster, you make it known to Conductor Live. If a node is not in a cluster, it is not being managed by Conductor Live. 

**Channel – Profile – Node Association**

When you create a channel, you associate it with one profile and one node. So the associations between these three entities is via the channel.

![\[Image file diagram-ncp.png\]](http://docs.aws.amazon.com/elemental-cl3/latest/ug/images/diagram-ncp.png)


In addition, keep the following in mind:
+ One profile can be used by multiple channels: so profiles are multi-use.  
![\[Image file diagram-cp.png\]](http://docs.aws.amazon.com/elemental-cl3/latest/ug/images/diagram-cp.png)
+ One node can handle multiple channels: so nodes are multi-taskers.  
![\[Image file diagram-nc.png\]](http://docs.aws.amazon.com/elemental-cl3/latest/ug/images/diagram-nc.png)

# Comparison of profiles


The way that channels (which you create using Conductor Live) and events (which you create using Elemental Live) use their profiles is different. The way that channels use profiles has some distinct advantages in terms of visibility and maintenance. 

If you have been using AWS Elemental Live in standalone mode or if you think you might occasionally run work in Elemental Live in standalone mode, you should read the information in the table to understand the differences. 


| Conductor Live | Elemental Live | 
| --- | --- | 
| Conductor Live profile can be used only with a channel created in Conductor Live. It cannot be used by an Elemental Live event. | An Elemental Live profile can be used only with an event created in Elemental Live. It cannot be used by an Conductor Live channel.  | 
|  After a channel is created, it is linked to its profile. A link exists between a channel and the profile used.  You can view the channels-profile association on the Channels page.  |  After an event is created, it is not linked to the profile. After the event is created, the data from the source profile exists in the event, but no link exists for that profile.  You cannot query the event to find out which profile was originally used.  | 
|  You cannot change a profile.  Instead, you can create a new profile with a new name. You can also duplicate an existing profile and then change it.  | You can change a profile. | 
|  Two channels can share a profile.  If channel\$1A was created using profile\$1X and channel\$1B was created using profile\$1X, then they all have the same “profile values.”  |  There is no idea exists of two events “sharing” the same profile.  If event\$1A was created using profile\$1X and event\$1B was created using profile\$1X, they do not automatically therefore have all the same “profile values.” (For example, if event\$1B was created after profile\$1X was modified, A and B have different values.)  | 

# Working with AWS Elemental Statmux
Working with AWS Elemental Statmux

Include AWS Elemental Statmux nodes in your AWS Elemental Conductor Live cluster if you want to create MPTS outputs. A multi-program transport stream (MPTS) is a UDP transport stream (TS) that carries multiple programs. Conductor Live lets you create an MPTS that contains all variable bitrate programs, a mix of variable and constant bitrate programs, or all constant bitrate programs.

You use AWS Elemental Statmux to ingest SPTS outputs from AWS Elemental Live and produce MPTSes. 

For Elemental Statmux, Conductor Live is a requirement. You can't run MPTSes without Conductor Live. 

**Topics**
+ [

# Components of AWS Elemental Statmux in a cluster
](smux-cluster-usage-components.md)
+ [

# Features of AWS Elemental Statmux
](cl3-statmux-features.md)

# Components of AWS Elemental Statmux in a cluster
Components of Elemental Statmux

To create an MPTS using Elemental Statmux, you need:
+ Elemental Live channels that produce an SPTS output.
+ An MPTS that you create using Elemental Statmux. Elemental Statmux*muxes* two or more SPTS outputs into one MPTS output.

![\[Diagram showing three Channel boxes connected to a single MPTS box.\]](http://docs.aws.amazon.com/elemental-cl3/latest/ug/images/diagram-cmpts.png)


# Features of AWS Elemental Statmux


**Topics**
+ [

## What you can mux
](#cl3-smux-content)
+ [

## Support for multiple output configurations
](#cl3-statmux-features-outputs)
+ [

## Bitrate allocation
](#cl3-statmux-features-bitrate)
+ [

## Closed-loop bitrate allocation
](#cl3-statmux-features-allocation)
+ [

## Resiliency in a statmux workflow
](#cl3-statmux-features-resiliency)

## What you can mux


Elemental Statmux supports muxing of the following:
+ Standard muxing that includes statmuxing: An MPTS can include an SPTS that is the output of a channel (event) from an Elemental Live node that is in the same Conductor Live cluster. For more information, see [Creating a standard MPTS](mpts-design-step-channels.md).
+ Program passthrough: An MPTS can include an SPTS program that you pass through from another source – either an MPTS from a third-party source, or an SPTS from an Elemental Live node that is in a different Conductor Live cluster. For more information, see [Including passthrough programs](mpts-passthrough-program.md).
+ Custom stream passthrough: An MPTS can include packets from a custom PID. For more information, see [Passing through custom streams](mpts-passthrough-high-pids.md).
+ SI/PSI table passthrough: An MPTS can include SI/PSI tables that you have generated outside of Elemental Statmux. For more information, see [Passing through SI/PSI tables](mpts-passthrough-PSI-pids.md).

## Support for multiple output configurations


The MPTS can include different types of SPTS channels from Elemental Live. Elemental Statmux has the ability to mux channels with the following characteristics:
+ Different resolutions: SD, HD, and 4K.
+ Different codecs: MPEG-2, AVC, and HEVC.
+ Different color ranges: SDR and HDR.

## Bitrate allocation


The following rules apply to the bitrate for an MPTS:
+ The MPTS has a maximum bitrate that you specify. As much as possible, Elemental Statmux uses up this maximum. However, when necessary, it includes NULL bits in the MPTS.
+ Each SPTS has either a constant bitrate (the video stream is CBR) or a bitrate range (the video is VBR). Elemental Statmux allocates the available bitrate among the SPTSes. Elemental Statmux continually adjusts the bitrate allocation among the SPTSes.

When you run the MPTS, Elemental Statmux automatically allocates a bit rate to each SPTS. 

The automatic bitrate allocation deals with the video and audio and all ancillary data. 

Within the MPTS, you can prioritize SPTS channels. For example, you can assign a higher priority to the SPTS channel that is the live sports event. Elemental Statmux will always assign more bitrate to more important channels, to ensure that these channels always have higher video quality. 

## Closed-loop bitrate allocation


The Elemental Statmux implementation of statmuxing follows a *closed-loop bitrate allocation model*.

A continual dialog is maintained between the Elemental Statmux node and the Elemental Live nodes. 

For each segment in each SPTS channel, Elemental Live sends complexity information to Elemental Statmux. Elemental Statmux assesses the demands of all SPTS channels and sends a bitrate allocation response for that segment to each Elemental Live. Each Elemental Live uses the allocation response to determine the bitrate for the segment. 

![\[Diagram showing data flow between channel and MPTS components for complexity and allocation.\]](http://docs.aws.amazon.com/elemental-cl3/latest/ug/images/smux-allocation-conversation.png)


## Resiliency in a statmux workflow


You can configure the statmux workflow for resiliency in various components of the workflow, including redundant inputs in the Elemental Live nodes and Elemental Statmux nodes. 

# AWS Elemental Statmux tutorial


This tutorial describes how to create a statmuxed MPTS workflow.

All the data in this tutorial is an example. You can adapt the workflow and create it yourself if, you have one AWS Elemental Conductor Live node, one AWS Elemental Statmux node, and one AWS Elemental Live node, if you have at least two sources that can be set up as inputs into Elemental Live, and if you have a multicast address where you can send an MPTS output.

## Assumptions about existing knowledge


We assume the following:
+ We assume that you have some familiarity with the basic features of Conductor Live. You are familiar with setting up nodes in a cluster, and with creating redundancy groups to provide resiliency for CL3 outputs.
+ We assume that you are very familiar with the structure and purpose of the events (channels) that you create using Elemental Live. 
+ We assume that you are familiar with the uses of statmux MPTS, and with multicast and unicast. You don't need to be familiar with how to create MPTSes using Conductor Live and Elemental Statmux.

## Step 1: Check your cluster and redundant nodes


We're not going to show you how to create the cluster. Assume you've already set up the following:
+ Conductor Live is set up in a redundancy group as a high availability (HA) pair. This setup ensures that the MPTS workflow doesn't stop if one Conductor Live node fails.

  Assume that the redundancy group is named CL\$1pair.

  Assume that the two nodes are called CL\$11 and CL\$12.
+ A pair of Elemental Statmux node in a 1-to-1 redundancy group. Both nodes actively process the same MPTS, which means they are both *hot* nodes. Conductor Live manages which output gets delivered. This setup ensures that there is no interruption if one node fails.

  Assume that the redundancy group is named SM\$11-to-1\$1hot.

  Assume that the nodes are called SM\$1X and SM\$1Y.
+ Several Elemental Live nodes in an N-to-M redundancy group. Let's say there are three active nodes and one backup node serving those three active nodes. This setup ensures that encoding of the SPTS channels can quickly recover if the active Elemental Live node fails.

  Assume that the redundancy group is named Live\$1NM.

  Assume that the three active nodes are called EL\$1A, EL\$1B, and EL\$1C.

  Assume that the two backup nodes are called EL\$1D and EL\$1E.

  When you've read this tutorial, you can get more information about [redundancy](cl3-resiliency.md).

This is what you would see on the web interface for a cluster that is set up in this way:
+ When you chose **Cluster**, then **Nodes** on the Conductor Live main menu, you would see the following:
  + **CL\$11**, with the following information:

    A key icon that indicates that it is currently the primary node.

    The redundancy type set as **HA**. 
  + **CL\$12**, with the same information, but without the key icon.
  + **SM\$1X** and **SM\$1Y** with the following information:

    The name of the redundancy group. 

    Note that both nodes and in the same redundancy group, and that they are the only nodes in the group. From this you can infer that the nodes are set up as a 1-to-1 redundancy group.

    The number of MPTSes that exist on each node.

    Channels will always be 0 for an Elemental Statmux node.
  + The five Elemental Live nodes with the following information:

    The name of the redundancy group. 

    Notice that all the nodes are in the same redundancy group, and that there are more than three nodes in the group. From this you can infer that the nodes are set up as an N-to-M redundancy group.

    The number of channels that exist on each node.

    MPTS will always be 0 for an Elemental Live node.
+ When you chose **Cluster**, then **Redundancy** on the Conductor Live main menu, you would see the following:
  + In the** CL\$1pair** redundancy group, you would see **HA**.
  + In the **SM\$11-to-1\$1hot** redundancy group, you would see two nodes in the **Active Nodes** tab, and no nodes in the **Backup Nodes** tab. This is a 1-to-1 redundancy group, so it doesn't have backup nodes.
  + In the **Live\$1NM** redundancy group, you would see three nodes in the **Active Nodes** tab, and two nodes in the **Backup Nodes** tab.

After you've read this tutorial, you can get more information about [redundancy](cl3-resiliency.md).

## Step 2: Create the profiles


You must create the profiles that you require for the SPTS channels that will produce the output from Elemental Live. 

1. On the Conductor Live main menu, choose **Profiles**. On the **Profiles** page, choose **New Profile** (on the top right corner of the page). 

1. Give the profile a name such as **SPTS-high-resolution**. 

1. Create the profile in the usual way for everything except the output groups and outputs.

1. To set up the outputs on the profile, scroll down to **Output Groups** and choose the **UDP/TS** tab.

1. In the **New Output** section, choose the **Add Output** button. 

1. For **MPTS membership**, choose **Remote**. This output section changes to display different fields. Leave the defaults for these fields.

1. In the **Streams** section, in the **Video** section, choose **Advanced** to display more fields. Set the following field:

   **Rate Control Mode**: Set to **Statmux**. This value indicates that the muxer will control the rate control for the output. 

   Note that when you set this value, the **Bitrate**, **Max Bitrate**, and **Min Bitrate** fields don't apply, so these fields become disabled.

1. Choose **Save**. 

The profile that you created is listed on the **Profiles** page. Conductor Live assigns a unique numerical ID to the profile.

Under the **Channels** column, the profile displays 0 0. This indicates that the profile is not yet being used by any channels.

## Step 3: Create the SPTS channels


You must create the SPTS channels that produce the SPTS outputs. In the Conductor Live main menu, choose Channels to display the Channels screen.

1. On the Conductor Live main menu, choose **Channels**. On the **Channel** page, choose **New Channel** (on the top right corner of the page). 

1. Give the channel a name such as **Program\$1A**. Select the profile you just created. 

1. In **Node**, choose the Elemental Live node where you want the channel to run. Note that the dropdown list shows only active Elemental Live nodes. It doesn't show backup Elemental Live nodes or any Elemental Statmux nodes.

1. Choose **Save**.

1. Repeat these steps to create the second channel. Name the channel **Program\$1B**. Choose the same profile as you did for the first channel. Choose the same Elemental Live node.

The channels that you created are listed on the **Channels** page. Conductor Live assigns a unique numerical ID to each channel. The row for each channel specifies its profile and node.

Choose the **Profiles** page again. Note that the profile that you created now displays **0 2**, to indicate that the profile is being used by two channels but none of the channels is active.

## Step 4: Create the MPTS


You are now ready to create the MPTS. You set up this MPTS to include the two channels that you created. 
+ On the Conductor Live main menu, choose **MPTS**. On the **MPTS** page, choose the **MPTS** button at the top right corner. The **Create a New MPTS** dialog appears.
+ In the **Node** field, choose the arrow to show the dropdown list. The list shows both the Elemental Statmux nodes. In **1-to-1 redundancy** group, both nodes are active, so both nodes are listed in this dropdown. With a 1-to-1 redundancy group, there is no sense of one node being the leader and the other being the follower. 

  Therefore, you can choose either node.
+ Choose one of the nodes where the MPTS will run. 
+ Complete the other fields. Pay particular attention to these fields:
  + **Name**. Give the node a name. For example, **MyMPTS**.

    For example, choose the node **SM\$1X**.
  + **Transport Stream Bitrate**. Enter a value here. This value is the total bitrate for the MPTS. All the SPTS channels in the MPTS will use a portion of this bitrate.
  + **URI**. This is the address to the destination on the downstream system. Conductor Live will deliver the MPTS to this address.
  + **Output listening**. Leave this field unchecked. This field applies if you want Elemental Statmux output listening resiliency. After you've finished this tutorial, you can get more information about [output listening](worker-nodes-other-resiliency.md). 
  + **Add Destination**. Don't choose this button because we won't create another destination. You create a second destination for this MPTS only if you want statmux output redundancy. After you've finished this tutorial, you can get more information about [output redundancy](worker-nodes-other-resiliency.md). 
  + Leave the default values for other fields.
+ Choose the **Advanced** tab. This tab shows information for the SI/PSI tables. Remember that when you created the profiles, you ignored the fields for the SI/PSI tables. The tables on this tab let you create tables that apply to the entire MPTS. For now, leave the defaults.
+ Choose **Save**.

The MPTS appears in the list of MPTSes. The node where you created the MPTS (node **SM\$1X**) is part of a 1-to-1 redundancy group. Therefore, Conductor Live creates two instances of the MPTS. 

The two MPTSes have identical URLs in the **Destinations** column, because the two MPTS instances are exactly identical. One node is tagged as **Primary**, the other as **Secondary**. 

Conductor Live assigns a unique numerical ID. The **Channels** column displays **0 0 0**. The last 0 specifies that the MPTS doesn't have any programs yet. We'll add those in the next step.

After you've finished this tutorial, you can get more information about [Elemental Statmux node redundancy](redundancy-worker.md). 

## Step 5: Add programs to the MPTS


After you create the MPTS, it has no programs in it. You must add programs before you can run the MPTS.

1. Still on the **MPTS** page, choose the MPTS by its name (**MyMPTS**). Choose the primary instance of the MPTS. The **Details** page for the MPTS appear. The page has four tabs, and the **Channels** tab is currently selected.

1. On the upper right side of the page, look for the **Add Channel** field in the gray section.

1. Choose the down arrow and choose one of the channels that you added. 

   An empty row appears for the new channel.

1. In the **Basic** tab, complete the **Service Name** and **Provider Name**. Elemental Statmux uses this information to create the SDT in the MPTS.

1. Leave the other fields blank. Note that you don’t need to enter a minimum and maximum bitrate.

1. Choose **Save**.

1. Repeat to choose the other channel. 

1. If you want to look at how these channels look in the MPTS, choose **MPTS** on the Conductor Live main menu. 

   On the **Basic** tab, note this information:
   + **\$1**: A numerical ID for each program in this MPTS. The number is unique within this MPTS.
   + **ID**: A numerical ID for each program. This number is unique among all MPTSes in this Conductor Live cluster.
   + **Encoders**: Specifies the number of Elemental Live encoders that are currently providing programs (channels) to this MPTS. 
   + **Program Number**: The PID for this program. When you added the channel to the MPTS, you had the option to specify this ID. In this tutorial, we didn't do that, so Conductor Live assigns a unique ID to each program in this field in the MPTs.
   + **Min and Max Bitrate**. Remember that when we added the program, we left these fields empty. Therefore, Conductor Live automatically assigns values. 

The other tabs display information that Conductor Live automatically assigns. Typically, there is no need to change these values.

## Step 6: Start the MPTS


There are two steps to starting the MPTS: start all the channels, then start the MPTS. You should start processing in this order so that when the MPTS starts, it immediately starts with its full complement of programs (channels).

1. Start the channels: On the Conductor Live main menu, choose **Channels**. 

1. Normally, you would identify the channels that belong to the MPTS you are starting. In our example, there is only one MPTS, so you don't need to do that.

1. In the row for each channel, choose the green arrow button on the far right. 

   Look at the **Status** column and make sure that all the channels are running.

1. Start the MPTS: On the Conductor Live main menu, choose **MPTS**.

1. In the row for the first instance of **MyMPTS**, choose the **Start** (green arrow) button on the far right. 

1. Repeat for the second instance of **MyMPTS**.

1. The **Status** column shows both the MPTSes as **Running**. 

   They are both running, because the Elemental Statmux node is set up in a 1-to-1 redundancy group.

   One instance of the MPTS is running on one node. The other instance is running on the other node.

1. On the **MPTS** page, choose the MPTS by its name. The **MPTS Details** page appears.

1. On the left side of the page, choose the **Performance** tab. The graphic indicates the bandwidth allocation that Conductor Live is continually applying to the entire MPTS and to each program in the MPTS.

This tutorial has walked you through creating and starting an MPTS.