T2-MI Explained: Why Direct Processing Matters in Broadcasting

T2-MI carries inner DVB-T2 multiplex data inside a DVB-S/S2 transport stream. SATLINE SAT>IP Streamer Pro handles decapsulation natively inside the streaming pipeline. This removes three legacy hardware stages – the IRD, the T2-MI decapsulator, and the ASI/IP gateway – from the signal chain. That is why the feature matters technically and financially.

T2-MI Direct Processing: Key Takeaways

• T2-MI matters when you need the inner DVB-T2 stream or one PLP, not just the outer satellite transport container
• SATLINE handles that natively inside SAT>IP Streamer Pro with t2mi_pid, t2mi_plp, and t2mi_pids instead of an external decapsulation chain
• The practical gain is concrete: fewer boxes, shorter signal path, lower rack/power/cooling load, clearer failure domains, and measurable CAPEX/OPEX savings

Below is the engineering view: what T2-MI is, how SATLINE decapsulates it, what hardware disappears, how the parameters work, and where the savings actually come from.

What Is T2-MI?

T2-MI, short for DVB-T2 Modulator Interface, is a protocol that lets broadcasters carry terrestrial DVB-T2 television signals over satellite. It packages the terrestrial multiplex inside a satellite transport stream so that a central headend can feed multiple regional transmitter sites from one uplink. Before that content can be re-broadcast, streamed over IP, or monitored, the inner DVB-T2 data has to be extracted from the T2-MI container – a process called decapsulation. Traditionally, this requires a separate chain of broadcast hardware, which is exactly the cost and complexity SATLINE’s native T2-MI processing removes.

SATLINE T2-MI Decapsulation: Native Processing Inside SAT>IP Streamer Pro

SATLINE introduces native T2-MI decapsulation directly inside the SAT>IP Streamer Pro platform. This eliminates the need for external broadcast hardware and simplifies the signal chain.

Architecture comparison	Legacy workflow	SATLINE workflow
Signal chain	DVB-S/S2 → IRD → T2MI Decapsulator → ASI/IP Gateway → Encoder → Output	DVB-S/S2 → SAT>IP Streamer Pro → IP Output
Where decapsulation happens	In a separate external decapsulation stage	Inside the SATLINE streaming pipeline
Removed stages	None	YIRDs, T2MI Decapsulators, ASI/IP Gateways
Engineering effect	Long chain, more handoff points, more rack and power overhead	Shorter path, fewer boxes, simpler support, and lower infrastructure load

SAT>IP T2-MI Parameters: Quick Engineer Reference

• t2mi_pid identifies the outer PID carrying T2-MI packets. auto tries common PIDs such as 4096 first, then 4095
• t2mi_plp selects the target DVB-T2 Physical Layer Pipe inside the T2-MI container. Use it when only one PLP is operationally relevant
• t2mi_pids filters the recovered inner TS after decapsulation. This is inner-TS filtering, not outer transport filtering

Output behavior: when t2mi_pid is set, the output becomes the inner TS. That is the core difference between T2-MI pass-through and usable extraction.

Known limitation: PMT-based SPTS selection is not supported in T2-MI mode. Use t2mi_pids explicitly instead of PMT-based assumptions.

Platform density: SATLINE uses 8 tuners and 720 Mbps aggregate LDPC per card. Power usage is roughly 5 W per card excluding LNB power, which matters in dense headends.

10 Reasons T2-MI Direct Processing Matters: At a Glance

1. Direct inner TS recovery. Recover the usable inner DVB-T2 transport stream from the T2-MI container. Turns a T2-MI source into something downstream systems can actually use.
2. PLP-aware extraction. Select the correct Physical Layer Pipe with t2mi_plp. Avoids pulling unwanted multiplex data.
3. Inner PID control. Filter the extracted TS with t2mi_pids. Delivers cleaner output to downstream systems.
4. Native decapsulation in SAT>IP Streamer Pro. Keep T2-MI decapsulation inside the streaming pipeline. Removes an external processing stage.
5. IRD / T2MI / ASI-IP chain removal. Replace the legacy discrete hardware chain. Fewer boxes, simpler integration, clearer failure domains.
6. Lower rack, power, and cooling footprint. Reduce the physical hardware per chain. Cleaner headend design and lower infrastructure load.
7. Lower added latency and cleaner signal path. Remove extra buffer/remux hops. Better timing consistency and faster turn-up.
8. Dense platform economics. 8 tuners, 720 Mbps LDPC per card, ~5W per card. Makes scaling T2-MI practical.
9. Per-chain CAPEX savings. Indicative saving of €4,000 – €12,000 per chain. Easier ROI case when discrete hardware existed before.
10. Headend-scale CAPEX/OPEX savings. 32-transponder designs can remove large amounts of hardware. Six-figure savings range plus lower monthly overhead.

10 Reasons T2-MI Direct Processing Matters: Detailed Breakdown

1. Direct inner TS recovery
   T2-MI matters only when the inner DVB-T2 content matters. If you stay at the outer satellite transport layer, you still have the container, not the usable multiplex. Direct processing solves that by recovering the inner TS inside the SATLINE pipeline itself.
   From an engineering view this is the first non-negotiable reason the feature exists: without extraction, downstream DVB-T2 rebroadcast, gateway, or PLP-specific workflows cannot start.
2. PLP-aware extraction
   A single T2-MI stream can carry one or more PLPs. t2mi_plp lets SATLINE target the exact Physical Layer Pipe that the workflow needs instead of forwarding everything and filtering later.
   This matters operationally because regional or service-specific terrestrial workflows rarely want the whole container; they want one PLP, cleanly and predictably.
3. Inner PID control
   After extraction, t2mi_pids filters the inner TS itself. That is an important distinction: once T2-MI mode is active, the filtering target is the recovered inner stream, not the outer transport.
   That makes the output immediately more useful for downstream gateways, recorders, or monitoring tools, and it removes one more place where engineers normally add sidecar processing.
4. Native decapsulation in SAT>IP Streamer Pro
   SATLINE keeps T2-MI decapsulation inside SAT>IP Streamer Pro rather than sending the stream to a separate dedicated appliance. The same workflow locks the transponder, identifies the T2-MI PID, selects the PLP, and emits the usable inner TS/IP output.
   This is the core engineering change behind the page. The feature is not just “T2-MI awareness” as a label; it is native decapsulation inside the streaming pipeline.
5. IRD / T2MI / ASI-IP chain removal
   The legacy chain is familiar: DVB-S/S2 → IRD → T2MI Decapsulator → ASI/IP Gateway → Encoder → Output. Every extra stage adds another box, another PSU, another set of ports, and another failure domain.
   SATLINE collapses that into DVB-S/S2 → SAT>IP Streamer Pro → IP Output. That is why the value proposition is concrete: IRDs, T2MI decapsulators, and ASI/IP gateways can disappear from the design where they existed only for this task.
6. Lower rack, power, and cooling footprint
   Once discrete IRD, decapsulation, and gateway stages disappear, the headend is physically smaller. The practical effect is lower rack occupation, less cabling, fewer power feeds, and less cooling load around the T2-MI chain.
   The planning ranges used here are 30–70% less rack space and 20–50% lower power usage for the T2-MI handling footprint. The exact number depends on the legacy design being replaced, but the direction is consistent.
7. Lower added latency and cleaner signal path
   Each external decoder, gateway, or remux layer can add buffering and timing noise. By keeping extraction native, SATLINE shortens the path between locked satellite source and usable IP output.
   No serious engineer should read this as “magic zero-latency”, but it is a valid improvement: fewer stages generally means lower added latency, cleaner signal flow, and more consistent behavior under load.
8. Dense platform economics
   The economics only work if the reception platform itself is dense. SATLINE builds on the Max SX8 Pro layer with 8 DVB-S/S2/S2X tuners and 720 Mbps aggregate LDPC per card at roughly 5W per card excluding LNB power.
   That density matters because T2-MI stops being a one-off exception box and becomes a function of the same reception platform that already handles the transponders.
9. Per-chain CAPEX savings
   Per-chain savings become straightforward when you map the removed hardware. The planning ranges used in this page are €2,000–€8,000 for a T2MI decapsulator, €1,500–€6,000 for an IRD receiver, and €500–€2,000 for an ASI/IP gateway.
   That is why the indicative saving per chain is €4,000–€12,000. The engineer’s question is not whether the number is universal; it is whether those boxes existed in the legacy design. If yes, the savings logic is real.
10. Headend-scale CAPEX/OPEX savings
    At headend scale the effect compounds. In a 32-transponder design, the legacy model can land in the €160,000–€450,000 range when each chain carries its own IRD, T2MI decapsulation, and gateway footprint.
    SATLINE moves that function into the platform itself. That is why the planning range for total savings is €100,000–€400,000+, and why a recurring OPEX figure such as roughly €7,200 per month can be a credible operational quote in the right multi-transponder environment.

T2-MI Decapsulation Cost Savings: Pricing Breakdown

These blocks are the clean commercial reference version of the engineering case above. They keep the prices, savings, and operational effects aligned so the page can serve both engineers and press readers.

Removed hardware stage	Typical unit CAPEX range	What SATLINE replaces it with
T2MI Decapsulator	€2,000 – €8,000	Native T2-MI decapsulation inside SAT>IP Streamer Pro
IRD Receiver	€1,500 – €6,000	SATLINE reception layer with 8 DVB-S/S2/S2X tuners per card
ASI/IP Gateway	€500 – €2,000	Direct TS/IP output from the streaming pipeline
Indicative saving per chain	€4,000 – €12,000	Fewer boxes, fewer handoff points, simpler integration

32-transponder headend reference	Indicative total cost	Outcome
Legacy chain with discrete IRD + T2MI decapsulator + ASI/IP gateway per transponder	€160,000 – €450,000	Large rack footprint, more discrete hardware, longer integration cycle
SATLINE SAT>IP Streamer Pro with native T2-MI decapsulation	Integrated into the platform	Single software-defined workflow across the headend
Indicative total savings	€100,000 – €400,000+	Removed decapsulation, IRD, and gateway stages

Rack & power

• 30–70% less rack space
• 20–50% lower power usage
• Reduced cooling requirements

Operational (OPEX)

• Fewer failure points
• Less cabling (no ASI chains)
• Reduced maintenance
• Faster deployment

Key statement: We’ve moved T2MI decapsulation from external hardware into software-defined streaming – cutting infrastructure costs by up to 70% per signal chain.

“By moving T2MI decapsulation from dedicated appliances into SAT>IP Streamer Pro, we saved roughly €7,200 per month in a typical multi-transponder headend — by removing standalone T2MI decapsulators, collapsing duplicate IRD stages, and eliminating the ASI/IP gateway layer we used to maintain alongside them.”

— Gleb Sazanov, CTO, SATLINE

T2-MI Deployment Checklist

• Do you actually need the inner DVB-T2 stream or one PLP? If yes, T2-MI extraction is the real technical problem.
• Do you know the outer T2-MI PID? If not, start with t2mi_pid=auto and verify the result.
• Do you need full inner MPTS or selected inner PIDs? Use t2mi_pids intentionally from day one.
• Does the current design still depend on IRD, T2MI decapsulator, or ASI/IP gateway stages? If yes, that is exactly where the savings come from.
• Are rack, power, cooling, latency, and maintenance part of procurement pressure? If yes, native decapsulation has clear operational value beyond the feature list.

T2-MI Technical Documentation and Resources

Use the SATLINE T2-MI technical sheet for parameter-level reference, then review the infrastructure overview if you want the platform-density and hardware context behind native decapsulation.

Open the T2-MI technical sheet →

Open the SATLINE infrastructure overview →