Quick answer: T2-MI carries inner DVB-T2 multiplex data inside a DVB-S/S2 transport stream. SATLINE.TV SAT>IP Streamer Pro performs native decapsulation in the streaming pipeline, exposes t2mi_pid, t2mi_plp, and t2mi_pids, and removes separate IRD, T2-MI decapsulator, and ASI/IP gateway stages from the chain. That is why the feature matters technically and financially.
t2mi_pid, t2mi_plp, and t2mi_pids instead of an external decapsulation chain.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.
SATLINE introduces native T2MI 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 | IRDs, 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 |
| Parameter or fact | What it does | Practical note |
|---|---|---|
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.TV uses 8 tuners and 720 Mbps aggregate LDPC per card. | Power is roughly 5W per card excluding LNB power, which matters in dense headends. |
Example meaning: lock the DVB-S2 transponder, identify the T2-MI PID automatically, extract PLP 0, then emit only the required inner TS PIDs.
| Reason | Technical meaning | Why it matters operationally |
|---|---|---|
| 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. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.TV 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 |
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.”
t2mi_pid=auto and verify the result.t2mi_pids intentionally from day one.T2-MI is a way to carry inner DVB-T2 multiplex data inside a DVB-S/S2 satellite transport stream. It matters when the real goal is to recover the usable inner DVB-T2 TS or a specific PLP for terrestrial distribution or rebroadcast workflows.
SATLINE.TV performs native T2-MI decapsulation inside the streaming pipeline itself. The platform locks the satellite transponder, identifies the T2-MI PID, selects the required PLP, and outputs the recovered inner TS/IP stream without handing the job to a separate external appliance.
t2mi_pid identifies the outer T2-MI PID, t2mi_plp selects the target PLP, and t2mi_pids filters the recovered inner TS after decapsulation.
In the legacy model the chain often includes a separate IRD, a dedicated T2MI decapsulator, and an ASI/IP gateway. SATLINE.TV moves decapsulation into SAT>IP Streamer Pro, so those stages can disappear where they existed only to make the inner DVB-T2 stream usable.
The indicative planning range is €4,000 – €12,000 per chain when a T2MI decapsulator, IRD receiver, and ASI/IP gateway can be removed from the legacy design.
For a legacy design that used discrete IRD, T2MI decapsulation, and ASI/IP gateway hardware per chain, the planning range in this page is €100,000 – €400,000+ in total savings compared with moving the function into the SATLINE platform.
Because the monthly burden of maintaining separate T2MI decapsulators, duplicate IRD stages, power, cooling, and the ASI/IP gateway layer can disappear once the same function lives inside the SATLINE streaming platform.
It reduces added latency by removing extra decoder, gateway, and remux stages from the chain. The point is not “zero latency”; the point is a shorter and cleaner signal path with less buffering overhead.
No. In the SATLINE workflow, T2-MI decapsulation happens inside the SAT>IP Streamer Pro software-defined streaming core, so no external FPGA or ASIC-based decapsulation appliance is required.
PMT-based SPTS selection is not supported in T2-MI mode. When t2mi_pid is active, inner filtering should be done explicitly with t2mi_pids.
Use the SATLINE.TV 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.