PBroadcast infrastructure
The DVB-to-IP engine developed specifically for SATLINE.TV and proven in demanding 24/7 broadcast workflows.
About productOverview
Originally engineered specifically for the SATLINE.TV platform, SAT>IP Server Pro turns physical and remote DVB resources into controllable IP infrastructure. Its direct MPTS, T2-MI PLP and raw DVB-S2 BBFrame paths solve specialist contribution and distribution cases alongside standards-based RTSP, HTTP and encrypted SRT delivery.
For broadcasters and platform operators who need resilient DVB reception, specialist multiplex processing and controlled IP delivery.
Features
SAT>IP Server Pro was developed specifically for the SATLINE.TV project, where satellite reception, multiplex processing and reliable IP contribution must operate continuously as one system. The product packages that field work into a compact Linux service for broadcasters, teleports, headends and distributed reception sites.
Deliver a complete transponder as MPTS, derive a single-program transport stream from its PMT, or select an explicit PID set. Multiple clients on the same transponder can share one tuned resource while requesting different PID scopes, reducing unnecessary retunes and making better use of reception hardware.
For carriers that place several services behind a shared MPS wrapper, select the required MPS sub-stream and inner service instead of redistributing the entire outer structure. The same nested-service route can be used with HTTP, RTSP and SRT outputs.
Extract the inner DVB-T2 transport stream carried inside a satellite T2-MI feed. The server can discover the wrapper PID, select the first data PLP, address a specific PLP or merge all PLPs when a common PSI PLP and data PLPs must remain together. Inner-stream PID filtering is available for focused downstream delivery.
On compatible STiD135-based reception hardware, raw DVB-S2 BBFrame mode bypasses unreliable hardware MIS-to-TS de-encapsulation. The server reconstructs the outer transport stream in software and passes it into the T2-MI demultiplexer, preserving feeds that otherwise suffer severe packet loss despite a clean RF lock.
RTSP supports SAT>IP session control over UDP or interleaved TCP, HTTP provides direct streaming and device description services, and encrypted SRT carries selected PIDs, PMT-derived services or full multiplexes across less predictable networks. The same T2-MI processing path is available to HTTP, RTSP and SRT outputs.
Hardware CI, DDCI and DVBAPI workflows integrate authorized conditional-access environments. Tuner lockers retain a known reception state, while operator APIs, signal telemetry, session visibility and automatic recovery tools support commissioning and 24/7 operations without exposing administration data through the client-facing monitor.
Integrated modules
The same processing pipeline carries a conventional service, complete multiplex or specialist T2-MI/BBFrame feed from tuner to consumer.
Local DVB-S/S2/S2X, terrestrial, cable and ATSC resources can serve multiple clients. Compatible requests share one transponder lock while retaining independent PID selections.
Carry every PID from a transponder, derive a service from its PMT, or define an exact PID list. The scope stays explicit from reception through the selected output protocol.
Address a sub-stream and service inside a shared MPS wrapper, preserving nested broadcast distribution workflows without moving the complete outer multiplex.
Discover the T2-MI wrapper, select one data PLP, choose a specific PLP or merge all PLPs, then deliver the inner DVB-T2 multiplex or a filtered inner PID set.
Compatible STiD135 hardware can emit raw BBFrames for software reconstruction before T2-MI processing, avoiding the packet loss produced by problematic hardware MIS de-encapsulation.
Serve SAT>IP consumers locally, expose direct HTTP transport streams, or cross less predictable links with AES-protected SRT and selectable per-client stream scope.
Integrate hardware CI, DDCI and DVBAPI/OSCam workflows for correctly entitled services, with PMT, CAT, ECM and mapping paths designed for operational use.
Retain known tuner states, inspect sessions and signals, and recover stalled reception paths. Client-safe signal XML stays separate from firewalled administrative state and APIs.
Architecture
The service coordinates reception resources, shares compatible tuning work and exposes the delivery path required by each consumer.
Physical DVB or remote SAT>IP
Tuning, sharing and control
RTSP · HTTP · SRT
Players, services and broadcast systems
Platforms
Builds target common x86 systems and selected ARM and MIPS platforms. Exact tuner hardware, drivers, conditional-access workflow and network design must be confirmed together.
Manual
This deployment sequence keeps reception, transport, access and operational acceptance in one technical plan.
List the physical DVB adapters and remote SAT>IP sources that will feed the service. Confirm drivers, supported delivery systems and network reachability before designing the output paths.
Plan the expected transponders, services and simultaneous consumers. Clients tuned to the same transponder can share a tuner while requesting different PID selections, so demand should be modeled at both transponder and service level.
Use RTSP or HTTP for compatible local and network consumers. Use encrypted SRT where the build and topology support it. Decide whether a consumer needs one service, an explicit PID list or a complete multiplex.
Hardware CI, DDCI and DVBAPI workflows depend on compatible equipment, software and valid entitlements. Confirm the authorized subscription and exact integration before commissioning.
Prepare the supported architecture, tuner permissions, service account, network bindings and any required libraries. Keep administrative interfaces separate from public signal delivery.
Verify tuning, signal state, requested PID scope and every output protocol with representative consumers. Use operational diagnostics to establish a known-good baseline before production handover.
Support
Ask about compatibility, access, troubleshooting or deployment requirements.
Downloads
Public packages appear in the download centre. Customer-specific releases require an authorized account.
