FROM ANY VENUE.
TO EVERY
DESTINATION.
Broadcast-grade contribution and multi-destination delivery. Send us SRT or Zixi from wherever the event actually is — every taker receives it in the protocol their receiver wants.
A small MCR room in Osijek, Croatia
The room your feed is monitored from. Ingest watched, delivery to each taker started and stopped from here, for the whole window your event is on air.
The person who built the chain is the person who answers when you write during the match.
No rota, no ticket queue, no handover at shift change.
What we can take in
Five ways in. Most customers use the first, because every modern encoder speaks SRT and it costs them no licence.
| You have | How it works | What we need from you |
|---|---|---|
| An encoder that can push out | SRT — we listen, your encoder calls in. The default, and the simplest. | Your public source IP, encoder make and model, bitrate, codec |
| A firewall that will not let you push | SRT — we dial out to your listener instead. | Your listener address and port, and a stream ID if you use one |
| Zixi already running | Zixi push, straight in. Your licence covers your end, ours covers ours. | Your public source IP, Zixi sender version, bitrate, agreed stream ID |
| A bonded unit | LiveU, TVU, Dejero. Your platform hands us SRT out of it — nothing extra to buy. | The egress details from your platform |
| A feed already in the cloud | A direct cloud-to-cloud handoff, so the feed never touches the public internet. Cheapest and cleanest path where it applies. | Which platform and which region — we will confirm whether it applies |
Not sure which applies? Say what your encoder is on the request form and we will tell you.
What we can send out
Each taker gets what their receiver actually wants. Different protocols to different destinations off the same feed is normal, not an extra.
| The taker’s situation | What they receive |
|---|---|
| Static public IP, no NAT | Zixi push or SRT — we push to them |
| Behind a firewall or NAT, has to pull | Zixi pull — we need their remote ID and stream ID |
| Wants SRT and will call in | SRT — one caller per listener, so a backup receiver needs its own |
| Runs RIST or RTP | RIST, RTP or RTP-FEC |
| OTT, social, or any CDN ingest | RTMP |
Frame rate and scan
The usual mismatch: the source is 1080i50 and the takers want 1080p50. We convert in the path, so neither end has to change what it already does. Tell us the source format on the request form — it is the field that most often changes the answer.
Five steps. No season to sign.
A single fixture is a normal job. There is no minimum and no capacity contract.
Send the fixture details
Use the request form, or write to ops@dps.sbs. It asks when and where, what you are sending and in what format, and how many destinations.
Terms come back by email
Priced against the actual job — the feed hours and the number of destinations. No minimum, no season commitment, nothing to sign up to.
You get the connection details
Ingest address, port, latency and passphrase where encryption applies. Each taker’s endpoint is configured from what you send us.
A test before the day — always
A real feed down the real path, at a slot you pick on the form. Never a promise that it will work on the day.
Event day
The path is up ahead of your start time and watched throughout. If something needs saying during the match, you write to the person who built it.
Live production
Two to sixteen cameras, direction, replay, graphics, audio and world-feed output. The production side of DPS.SBS, for events that need the pictures made as well as moved.
See live production →
SEND THE FIXTURE
DETAILS.
When and where, what you are sending, how many destinations. Terms come back by email.
Request a transmission →