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 docid\ rafjhshdvxnxqakiofeif , 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 docid\ wqxj4baipjwwjyx6kmm8o 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 docid\ fil363whm6ibixibmn2fz creating a pid interleaver spts input 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 docid\ xflbxevje2ud 0uvtnnx7 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