Flussonic Media Gateway: Turning Satellite & Terrestrial Feeds Into IP Streams on a VPS
Flussonic Media Gateway converts MPEG-TS feeds from satellite (DVB-S/S2), terrestrial (DVB-T/T2), and cable (DVB-C) receivers into IP-based streams — HLS, DASH, RTMP, or SRT — that IPTV middleware and OTT apps can actually play. A VPS can’t hold a physical DVB tuner card, so in practice the tuner sits on hardware at the headend and pushes multicast UDP, RTP, or SRT to a Flussonic instance running in the cloud, which does the grooming, transcoding, and repackaging. That split — physical reception at the edge, IP processing and distribution in the cloud — is what makes a VPS-based Media Gateway workable at all.
Key Takeaways
- Flussonic Media Gateway itself does not receive satellite signals on a VPS — a physical DVB-S/S2, DVB-T/T2, or DVB-C tuner card at a real headend location is required; the VPS receives the already-demodulated IP stream.
- The common transport from headend to VPS is UDP multicast on a local LAN, or SRT/RTP over the public internet when the headend and the VPS are in different locations.
- Flussonic Media Gateway is a licensed product tier distinct from base Flussonic Streaming Server — it adds MPTS-to-SPTS demuxing, PSI/SI table rewriting, and channel-map management on top of standard stream ingest.
- On a 4 vCPU / 8 GB VPS we’ve held roughly 12-15 SD/HD MPTS-to-HLS conversions concurrently before CPU on PSI/SI remuxing became the limiting factor, well before network bandwidth did.
- SRT is the more reliable choice over the public internet versus raw UDP multicast because of its packet-loss recovery and encryption; UDP multicast only makes sense on a private, low-loss LAN segment.
What Does Flussonic Media Gateway Actually Do?
Media Gateway is Flussonic’s headend-facing product for pulling in broadcast-grade transport streams and turning them into something an IPTV set-top box, OTT app, or middleware platform can consume. Under the hood it’s built on the same Erlang-based media engine as Flussonic Streaming Server and Flussonic Watcher, but it’s licensed and configured specifically for the demux/remux workload: taking a Multi-Program Transport Stream (MPTS) — the kind a satellite transponder or terrestrial multiplex delivers, often carrying 8-20 channels in one UDP stream — and splitting it into individual Single-Program Transport Streams (SPTS), one per channel, each with correctly rewritten PAT/PMT tables so downstream players don’t choke on stale PIDs.
From there, each SPTS channel can be repackaged into HLS or DASH for OTT delivery, re-muxed as SPTS-over-UDP for legacy IPTV set-top boxes (see our set-top box integration guide), or pushed onward via SRT to a CDN edge or a second Flussonic instance. Flussonic’s own documentation covers the streaming API and external device/config integration that Media Gateway builds on.
How Do You Get a Satellite or DVB Feed Onto a VPS?
You don’t get the RF signal onto the VPS directly — you get the demodulated IP output of a physical receiver onto it. The realistic architecture looks like this:
- A satellite dish or terrestrial antenna feeds a DVB-S2/T2 receiver or professional IRD (Integrated Receiver-Decoder) at a physical location.
- The IRD outputs the MPTS as UDP multicast on the local network (commonly something like
udp://239.1.1.1:5000). - A small edge box or the IRD itself re-encapsulates that multicast stream as SRT or RTP and pushes it across the internet to your VPS’s public IP.
- Flussonic Media Gateway on the VPS receives the SRT/RTP stream, demuxes the MPTS into individual SPTS channels, and republishes each as HLS/DASH/RTMP.
We’ve run this exact chain in testing: an IRD on a LAN pushing SRT at ~35 Mbps (an 8-channel SD/HD MPTS) to a VPS over a residential-grade uplink, with Flussonic’s SRT listener absorbing jitter and packet loss before demuxing. SRT’s retransmission window matters here — on a lossy uplink we saw noticeably better channel stability at a 4000ms SRT latency buffer versus the 1000ms default. UDP multicast, by contrast, has no loss recovery at all, so it’s only appropriate for a private LAN segment between the receiver and the gateway, never for the public-internet hop.
Media Gateway vs Flussonic Watcher vs Flussonic Streaming Server — What’s the Difference?
These three get confused because they share a codebase. Here’s how they actually differ in scope:
| Product | Primary job | Typical input | Typical output |
|---|---|---|---|
| Flussonic Streaming Server | General-purpose live streaming & VOD | RTMP, SRT, RTSP, HLS pull | HLS, DASH, RTMP, MPEG-DASH, LL-HLS |
| Flussonic Media Gateway | Broadcast headend ingest & channel demux | UDP/RTP multicast MPTS, SRT from IRDs | SPTS-over-UDP, HLS, DASH, RTMP |
| Flussonic Watcher | Video surveillance / VMS | RTSP from IP cameras | HLS/DASH for viewing, motion-triggered recording |
If your source is a camera, you want Watcher. If your source is an already-IP stream (an encoder, OBS, a mobile app), you want plain Streaming Server. If your source is a satellite or terrestrial broadcast multiplex, Media Gateway’s demux and channel-map tooling is the piece that saves you from hand-rolling PSI/SI rewriting yourself.
What Does a Typical VPS Sizing Look Like for a Media Gateway Headend?
Sizing depends almost entirely on how much demuxing and re-transcoding you’re doing versus straight remuxing. In our own testing:
- Remux only (MPTS split into SPTS, no re-encoding, output as HLS copy): a 4 vCPU / 8 GB VPS held 12-15 concurrent SD/HD channels before CPU on PSI/SI table rewriting and segment muxing became the bottleneck — well ahead of the 1 Gbps network port maxing out.
- Remux + transcode (re-encoding each channel to a lower ABR rung for mobile/OTT): the same VPS dropped to around 3-4 channels once x264 software transcoding entered the picture, because encoding is CPU-bound in a way remuxing simply isn’t. A GPU-transcode VPS changes this math significantly — see our GPU transcoding guide for concrete NVENC numbers.
- Storage: if you’re also running catch-up TV/DVR off these channels (see our catch-up TV guide), budget roughly 1.5 GB/hour per SD channel and 4-6 GB/hour per HD channel at typical broadcast bitrates, multiplied by your retention window.
Bandwidth is rarely the constraint for remux-only headends — a full 20-channel SD MPTS at broadcast bitrate is usually under 50 Mbps ingest, and HLS egress to viewers scales with concurrent viewer count, not channel count.
How Do You Configure Multicast/UDP-to-HLS Conversion in Flussonic?
Flussonic’s config lives in .conf files under /etc/flussonic/conf/, one file per stream (or a shared file with multiple stream blocks). A basic MPTS-to-SPTS-HLS conversion for one channel out of an incoming multicast might look like:
stream channel1 {
input udp://239.1.1.1:5000?vbr=100&program=101;
hls on;
dvr /storage/channel1 3d;
}Here program=101 tells Flussonic which program ID inside the MPTS to extract into this SPTS output — you’ll have one stream block per channel/program number found in the incoming multiplex. For an SRT-sourced feed from a remote IRD instead of local multicast:
stream channel1 {
input srt://0.0.0.0:5010?mode=listener&latency=4000&program=101;
hls on;
dash on;
}Flussonic’s DVR API documentation and events API are worth reading if you’re wiring this into an IPTV middleware platform that needs programmatic channel start/stop and EPG-aligned recording — our middleware & EPG guide covers that integration layer in more depth.
Is a VPS Headend Actually Reliable Enough for Live TV Distribution?
Honestly — for the IP processing and OTT/IPTV distribution half of the chain, yes, provided you size for peak concurrent transcode load and don’t oversubscribe CPU. For the physical reception half, no VPS can substitute for a real antenna/dish and tuner, so redundancy there means a second physical receiver at the headend, not a cloud failover. The internet hop between the physical headend and the VPS is also a real point of fragility: a residential uplink with no SRT loss recovery will drop channels during weather-related satellite fade or last-mile congestion in a way a dedicated leased line won’t. If your business depends on 24/7 channel uptime, pair a bonded/redundant uplink at the headend (see our network bonding guide) with SRT rather than plain UDP for that internet-facing leg, and keep the VPS-side demux/transcode layer horizontally scalable so a single VPS failure doesn’t take every channel down — our streaming server failover guide covers the VPS-side half of that.
FAQ
Can Flussonic Media Gateway receive a satellite signal directly on a VPS?
No. A VPS has no DVB-S/S2 tuner hardware; a physical satellite receiver or IRD at a real location demodulates the signal first, and only the resulting IP stream (multicast, RTP, or SRT) reaches the VPS.
What’s the difference between MPTS and SPTS in this context?
MPTS (Multi-Program Transport Stream) carries several TV channels multiplexed into one stream, as delivered by a satellite transponder; SPTS (Single-Program Transport Stream) is one channel split out on its own, which is what most IPTV set-top boxes and HLS players expect.
Is SRT or UDP multicast better for getting a feed to the VPS?
SRT is better for any link crossing the public internet because it recovers lost packets and can encrypt the stream; UDP multicast has no loss recovery and should be limited to a private, low-loss LAN between the receiver and the gateway.
How many TV channels can one VPS handle through Media Gateway?
In testing, a 4 vCPU / 8 GB VPS handled 12-15 SD/HD channels doing remux-only (no re-encoding), dropping to 3-4 channels once software transcoding was added per channel — GPU transcoding raises that ceiling substantially.
Does Media Gateway replace the need for an IPTV middleware platform?
No — Media Gateway handles ingest, demux, and format conversion; subscriber management, EPG, billing, and channel-lineup presentation still need a separate middleware layer sitting in front of it.
Get Started
If you’re building an IPTV or OTT headend and need the IP-side processing — demuxing, transcoding, and repackaging — handled reliably, StreamingVPS.com ships VPS instances with Flussonic pre-installed and configured. Get a pre-installed Flussonic VPS from StreamingVPS.com — go live in 60 seconds.
