Version 2 — Ready

01 — the core

We wrote our own HTTP server

Every competing panel puts nginx in front and PHP behind it. That means a web server and a script interpreter sitting in the path of every single stream request, doing work that has nothing to do with video. We removed both and wrote the server ourselves, for this one job. The load on your machine drops accordingly — and the ceiling that everyone else shares stops being your ceiling.

no nginx no php purpose-built engine

See the comparison →

Dashboard black theme · 296 streams, 4.57 Gbps outclick to enlarge

02 — on-demand streams

A dormant channel is live in 800 ms

On-demand channels only run while somebody is watching, which is what makes a huge line-up affordable instead of ruinous. The catch everywhere else is the wait when a viewer wakes one up. Ours is about eight hundred milliseconds — fast enough that the viewer never learns the channel wasn't already running.

starts on first viewer stops on last pay for what's watched

See the comparison →

Online vs offline dark theme · 296 live, 197 dormantclick to enlarge

03 — zapping

Channel switching with no wait

Zapping is how a customer actually judges a service. They don't measure your uptime — they hold the remote down and feel whether the picture keeps up. On our engine it does. Switching between streams is immediate, which is the difference between a service that feels like television and one that feels like a website.

immediate switching feels like tv what customers judge you on

See it side by side →

Live streams and load light theme · per-server healthclick to enlarge

04 — the database

Millions of requests, still standing

Every panel is fine at three in the morning. The test is the moment a big match kicks off and your entire customer base connects inside the same two minutes. That surge is what takes conventional panels down — the database stops answering and the whole service goes with it. Ours is built to keep answering through millions of requests, so peak traffic is a busy evening rather than an outage.

built for peak no collapse at kick-off millions of requests

Why peak is the real test →

Open connections mint theme · 2,576 live connectionsclick to enlarge

05 — gpu encoding

Encoding on your graphics cards, not your CPU

Transcoding is the most expensive thing a panel does, and doing it on a general processor is why most operators ration it. We encode on graphics hardware as standard — across unlimited cards — so converting a channel into several qualities stops being the thing you can't afford to switch on.

nvenc unlimited cards several qualities at once logo overlay

The video processing page →

// one incoming source
→ best quality fast connection
→ standard most viewers
→ lower slow or mobile

paced by vram and card temperature

06 — ai, installed for you

The AI models set themselves up on your server

Subtitles generated from a film's own audio, translated into whatever your market speaks, and burned into the picture so they work on any device. The part nobody else solves is the setup: we install and configure the models on your server automatically. You get the capability without becoming the person who maintains a machine-learning stack — and your library never leaves your hardware.

installed automatically on your server live and vod burned-in subtitles

The AI page →

// setup, handled by us
models   installed on your server
config   automatic
content never leaves your hardware

// what you get
subs     generated · translated · burned in

01 / 06

0ms dormant stream to live

An on-demand channel goes from nothing to playing in about eight hundred milliseconds. The viewer doesn't experience it as a wait.

0 nginx · php in the path

Our own HTTP server sits in the streaming path instead. Nothing is interpreting a script between your source and your viewer.

Millions database requests, holding

The database keeps answering under the request volume that takes conventional panels down at peak.

Every Ubuntu release from 20.04 · migrate from any panel · your apps keep working

The path a stream takes

source

Ingest

Live source, local disk, exchange line or direct URL

solustv core

Our engine

Our own HTTP server. No nginx, no PHP. 30–40 MB per running stream

gpu

Transcode

NVENC encoding paced by VRAM and card temperature

Translate

Live and VOD, into whatever language your market speaks

proxy

Edge

Origin address stays hidden behind the proxy layer

xtream api

Your apps

Same API contract — nothing to rebuild or resubmit

The engine

What you inherit when the core isn't yours

A panel built on the Xtream Codes core shares that core's ceiling. You can restyle the interface, but you can't fix what sits underneath it. So we replaced it instead.

Xtream Codes core SolusTV V2

Web stack

nginx + PHP in the streaming path

Neither. Purpose-built engine

GPU encoding

Rarely offered on this core

Native, on unlimited cards

Waking a dormant stream

Viewer waits, sometimes fails

~800 ms

Memory per running stream

Density limits how much one box carries

30–40 MB

SSL across load balancers

Main node only, in practice

Every server in the cluster

Supported Ubuntu

Pinned to old releases

20.04 and everything after

Client apps

Xtream API

Xtream API unchanged + active code API + our own streaming API

800msdormant stream to live

30–40MBram per running stream

∞streaming and gpu servers

Speed, where a customer notices it

The two moments that decide whether your service feels good

Nobody cancels because of a throughput figure. They cancel because a channel took too long to start, or because holding down channel-up felt like waiting. Those two moments are what the engine was written for.

Waking a dormant channel

Inherited coreViewer waits, sometimes fails

slow

SolusTV V2Our own engine

~800 ms

On-demand channels stay off until somebody wants them. The only reason not to run a line-up that way is the wake-up delay — so we made it short enough to stop mattering.

Zapping between channels

Inherited coreSpinner between channels

noticeable

SolusTV V2Immediate switching

instant

Zapping is the thing a customer tests in their first five minutes and never consciously thinks about again — as long as it works. It's also the hardest thing to fix once the core is somebody else's.

The database

Every panel is fast at 3am. The test is kick-off.

A streaming service doesn't fail gradually. It fails at 20:00, when a match starts and your whole customer base connects inside the same two minutes. On a conventional panel that surge lands on a database that was never built for it — it stops answering, and the service goes down with it, at precisely the moment your customers care most.

Ours is built to keep answering through millions of requests. Peak traffic becomes a busy evening you watch on the dashboard, rather than the night you spend explaining an outage to resellers.

Ask how it behaves at your scale

// 20:00 — kick-off
connections the whole base, at once

// conventional panel
database     stops answering
service      down with it

// solustv v2
database     millions of requests, holding
service      a busy evening

Migration

Your apps don't need to know anything changed

V2 still speaks the Xtream Codes API. If you've shipped Android apps to your customers, built middleware around the endpoints, or sold devices already configured in the field — none of that has to be rebuilt, resubmitted or re-flashed. You move the panel; your users keep opening the same app.

Ask about migrating

# existing client, unchanged

GET /player_api.php?username=…

GET /xmltv.php?username=…

GET /live/…/…/1234.ts

# after moving to V2

200 OK · same contract

GPU

One of the very few IPTV panels that encodes on the card

Real hardware encoding, not a wrapper around a CPU encoder — on as many GPU servers as you want to attach — and the messy part, getting drivers and encoder limits right on a fresh box, is one click.

setup

Drivers install themselves

Attach a GPU server and the panel installs the current driver for it, then patches the encoder session limit — the two steps that normally cost an evening and a forum thread.

throughput

Batch encoding that watches the card

Queue a hundred titles and set the pace by what the hardware can take: start the next encode only while VRAM and temperature stay under your limits, or pin it to a fixed number at a time.

placement

Encode here, serve there

Finished files move to whichever load balancer should carry them. Encoding capacity and delivery capacity stop being the same problem.

GPU1● nvidia6h 40m

VRAM38%

ENC61%

FAN42%

TEMP58°

Encoding queue18 titlesbatch

#27214%

#27147%

#27082%

pacing · vram < 80% · temp < 80°C · max 30 at once

Translate a live channel into the language your market speaks

A stream in one language sells to one audience. The AI layer translates live channels and VOD as they run — and you choose where the model lives, because that decision affects both your costs and your data.

route 01 · self-hosted

Your own GPU server

The panel sets up a local model server on hardware you already own and runs translation there. Nothing leaves your infrastructure and there's no per-token bill.

route 02 · included

SolusTV translator API

Use our translation API with free tokens on SolusTV models. The fastest way to test whether a translated channel finds an audience before you commit hardware to it.

route 03 · bring your own

Your provider, your key

Already have an account somewhere? Paste the key and the panel uses it. No lock-in to a single vendor.

OpenAIClaudeDeepSeek…

01Transcribe

Speech in the source track is turned into timed text.

02Translate

The model you chose renders it into the target language.

03Build the SRT

Output becomes a proper subtitle file with correct timing.

04Burn or attach

Burn subtitles into the video, or ship them alongside it.

Network

Your origin server stops being findable

Two problems, both about who gets to see your infrastructure: hiding where it actually is, and deciding who reaches the parts that stay public.

proxy

Hide the origin

Publish through a proxy layer so the main server's address never appears to clients. What's exposed is the edge, not the machine holding your content.

firewall

Scanners get nothing

Bots find IPTV servers within hours of them appearing online. Scans are detected and the source is blocked before it maps anything useful.

networks

Decide who's allowed

Allow or block by AS number, organisation or provider name, and write geo-IP rules that match the countries you actually sell in. Everything blocked is visible in the panel's firewall log.

Active codes

One code, and the device is set up

The panel issues active codes that receivers and apps use to log in. A customer types a short code instead of a server address, a username and a password — and everything on their device is configured from your side.

Both formats work: the short alphanumeric code, and the plain 12-digit number most IPTV providers already use on their devices. Whichever your customers are used to typing, they keep typing it.

It also means you can build your own apps against it. Code login has its own API, alongside the Xtream API and our streaming API — so an app you publish carries your brand while the panel decides who gets in and what they see.

Ask how it works

receiver · activation

4K9X-T7B2

short code

Enter this on the device. No server address, no username, no password to dictate over the phone.

works onapps

andreceivers

issued bypanel

Inside the panel

Inside the streaming panel, organised the way you work

Live streams

Streams, categories and exchanges, with mass editing
EPG import and mapping
TV archive and timeshift for catch-up
Audio mapping — choose the language in one click
Transcode profiles per stream, CPU or GPU, with logo overlay

Movies and series

Add from local disk, exchange line or direct source
Full series, season and episode management
Batch encoding with per-title progress
Custom channels assembled from several VOD inputs as one continuous stream

Users and lines

Reseller, sub-reseller and sub-sub-reseller structures
Bouquets and per-line content assignment
Live user activity and connection monitoring
Active codes — build your own apps with code login

Servers

Unlimited streaming and GPU load balancers
Per-server RAM, CPU, disk, network and throughput at a glance
Full SSL across every node
Four interface themes

Interface

Four themes. One panel.

dashboard

Manage Streams — stream list with clients, uptime, FPS, resolution and bitrate per channel — **Manage streams**Clients, uptime, FPS, resolution and bitrate, per channel

Manage Movies — batch encoding queue with per-title progress — **Batch encoding**Queue progress per title, with the batch stoppable at any point

Dialog setting how fast a batch should encode, limited by VRAM and temperature — **Encode pacing**Bounded by VRAM and card temperature, or a fixed number at a time

Transcode Profiles — GPU and CPU profiles with codec, resolution, FPS and quality — **Transcode profiles**GPU or CPU, codec, resolution, quality and overlay — reusable

Manage Episodes — series and episode list with source, duration, filesize and status — **Series and episodes**Season and episode management with source, duration, size and status

Availability

Available now

V2 is out. Take three days on your own server to test it against your streams and your hardware, then it is €100 for your first month and €200 a month after that, with the whole platform included — unlimited streaming and GPU servers, AI, active codes, resellers, archive and support.

trial

3 days free

The full panel on your own server, so you can test it against your streams and your hardware rather than a demo.

Start the trial

licence €200

€100 first month

Unlimited streaming and GPU servers, AI translation, active codes, proxy and firewall, archive and timeshift.

Get SolusTV V2

Running SolusTV V1? Your existing service is unaffected — client area