Understanding MTPS and SPTS Inputs
This topic aims to help you understand the difference between SPTS and MPTS transport streams and also explains how to create a special type of PID Interleaver SPTS input , in which elements of other streams (such as an audio track or an overlay) can be merged into the primary SPTS stream.
Overview of MTPS and SPTS
MPTS = Multi-Program Transport Stream
SPTS = Single Program Transport Stream
In an MPTS, multiple programs (channels) are multiplexed together in one TS (each program has its own set of PIDs for audio, video, metadata, etc.). In an SPTS, the TS carries just one program’s audio/video/metadata set, making it simpler and often used for contribution, processing, or IP delivery where one service per stream is preferred.
You may have an MPTS created outside of the Broadcaster, and they can be added as inputs in the same way SPTS inputs are. You can also create an MPTS in Broadcaster itself by combining multiple SPTS inputs into one Multiplex input. This is useful if you have multiple destinations for your content, and some prefer to receive one MPTS output while others prefer multiple SPTS outputs. See Adding Multiplex Streams for details of creating a Multiplex input.
Note that a Multiplex or any other MPTS input can be output using any protocol you prefer.
On the other hand, you may have a Multiplex or other MPTS input that you need to extract one or more programs from to deliver as SPTS streams. You can easily do this using the instructions found in Demuxing an MPTS Stream .
Creating a PID Interleaver SPTS Input
Note: creating a PID Interleaver SPTS Input requires Broadcaster v19.
The special type of SPTS that combines elements of other streams (such as the audio track or an overlay) into the main program cannot currently be created in the Broadcaster UI, but can be created using the Broadcaster API.
Note: SPTS sources can also be created using the ZEN Master UI. See Adding a Source - SPTS Multiplex. This will still require using a Broadcaster v19 or later.
Before we get to an example API request, here are some notes to help you understand it:
- PID interleaver is based on the MPTS muxer
- In this new source type the user specifies which stream is acting as primary_source and the pids which they want to preserve. It is also possible to map them (in order to avoid pid collisions).
- Source PID and target PID are comma separated.
- Source/Target PID pairs are separated by semi-colons.
- The user needs to define all other sources and their pids using source=
- Syntax for preserving and mapping pids of source streams is identical to that for the primary_source
- Always include the primary_source first.
Sample API Request
http://127.0.0.1:4444/zixi/add_stream.json?type=pid_interleaver
&id=pidi&matrix=1&max_outputs=-1&mcast_out=0
&time_shift=0&enc-key=&fast-connect=0&kompression=1&target_bitrate=45000000&rec_duration=7200&rec_template=%25S_%25Y%25M%25D-%25T.ts
&s3=0&rec_history=0&dejitter=0&primary_source=bbb2:1001,5001;1002&source=BadenTV:68&source=480i:272 Sample API Request Annotated
http://127.0.0.1:4444/zixi/add_stream.json?type=pid_interleaver
&id=pidi
&matrix=1
&max_outputs=-1
&mcast_out=0
&time_shift=0
&enc-key=
&fast-connect=0
&kompression=1
&target_bitrate=45000000
&rec_duration=7200
&rec_template=%25S_%25Y%25M%25D-%25T.ts
&rec_history=0
&s3=0
&dejitter=0
&primary_source=bbb2:1001,5001;1002 <-- this is the primary stream. preserve pid 1001 and map it to 5001. preserve pid 1002 (no map)
&source=BadenTV:68 <-- secondary source BadenTV. preserve pid 68, no mapping
&source=480i:272 <-- secondary source 480i. preserve pid 272, no mapping