Impact of Nulls on Remux Capacity

Upon first hearing about the Null packet congestion problem, one's first thought might be "well my MPEG re-multiplexer takes care of that", and maybe it does.  But did you ever ask your remux vendor if their unit has an ingest rate limit?  Perhaps you have learnt the hard way that it has a very real limit. It turns out that most re-multiplexers do have an ingest rate limit, which can be as low as 450 Mbps on their Gig-E ports.  These include re-multiplexers such as RGB's BNP, Arris' (formerly EGT) VIPr, Harmonic's ProStream and many others.

You may think that 450 Mbps is more than enough to handle the aggregation of quite a few programs. But there are two things that throw a wrench in the works: 1) the trend to aggregate many ASI feeds before feeding them into a re-multiplexer and 2) the flood of MPEG Null packets in each of the satellite feeds.

In the Re-multiplexing Aggregated Content Diagram shown below, let's say there are 24 Satellite streams being aggregated onto a single Gig-E connection to the re-multiplexer.

Let's say that just 9 of these inputs are fed by Motorola satellite receivers. These receivers would output data at 54 Mbps each regardless of what the content is. The total output of the aggregation device will then be 486 Mbps which is already over the ingest rate limit of a 450 Mbps re-multiplexer. If the remux ingest rate limit was 600 Mbps, then just 12 inputs would cause the remux to be overloaded. If each receiver is an SPTS receiver that is pulling down a single 3.75Mbps SD program, then the Gig-E remultiplexer is overloaded when asked to process just 9 SD programs or 33.75Mbps of content in the case of the first remux.

Clearly this is a huge problem and will artificially force the un-necessary deployment of extra remultiplexer resources or the reduction of the number of inputs to be processed.

Solving Null Packet Clogging

By inserting WooshCom's MPA-1212, Null Packet Filter, before the aggregation device the ingest data load on the MPEG re-multiplexer is drastically reduced. Not only enabling the remux to operate correctly within its specifications but also moving the remux into more reliable operating territory by virtue of the percent load that is now placed on its CPU. This is depicted below in the Re-multiplexing Aggregated & Filtered Satellite Content Diagram.

The remux is now processing only 33.75 Mbps of data instead of 486 Mbps! So it can be seen that there is now plenty of capacity to add more inputs to the aggregator. In fact many of the remaining 15 input ports on the aggregator may now be occupied by full 38.8 Mbps transport multiplexes.

The approach enables the re-multiplexer to use its CPU horse-power on the important tasks of rate shaping and multiplex formation instead of wasting that power on sorting through all the Null packets.

Not only does a greater capacity result from this approach but also greater reliability as re-multiplexers are not pushed to operate at the edge of their limits thereby increasing the possibility of system crashes and/or degraded rate-shaping.