User guide
Your SRTCloud server, start to finish.
An SRTCloud server takes one SRT stream from your encoder and hands it to as many receivers as you have paid for. This guide walks through everything the console can do, in the order you will need it. Nothing here requires a Linux login: all of it happens in the browser.
Sections marked Pro apply only to the PRO edition, where every receiver gets its own port.
Contents
- 1. Getting started in three steps
- 2. The console at a glance
- 3. Sending your stream
- 4. Giving the stream to receivers
- 5. Setup Server
- 6. Passphrases
- 7. Reading the telemetry
- 8. The performance graph
- 9. Connection log
- 10. Drops
- 11. Live connections and bans
- 12. A port per receiver Pro
- 13. Traffic and restarts
- 14. If something is wrong
1. Getting started in three steps
- Open the console. Sign in at app.srtcloud.eu and select your server in the list on the left. The console appears as soon as the server is ready. A server that has just been created needs about a minute before it answers.
- Point your encoder at the IN address. Copy the IN: address from the top panel and paste it into your encoder as an SRT caller destination. Within a few seconds the Server Status turns into connected from your encoder's address and the graph starts moving.
- Give the OUT address to whoever is receiving. Copy the OUT: address and send it to your decoder, player or colleague. Click either address in the console to copy it to the clipboard.
That is the whole workflow. Everything below is detail you may never need on a good day.
2. The console at a glance
The console is one screen with four areas.
| Area | What it holds |
|---|---|
| Top panel | Server name, region, console version, IN and OUT ports, how many output streams you have, and the full IN and OUT addresses. Click an address to copy it. |
| Middle left | Three views that share the same space: Graph, Log and DropsPro plus Outputs. |
| Middle right | Live Telemetry — the numbers of the stream that is arriving right now — and the Reset Drop/Loss, Restart Server and SETUP SERVER buttons. |
| Bottom | Live connections — one box per output, showing who is connected. |
3. Sending your stream
Your encoder is the caller; the server is always listening. Set it up like this:
| Setting | Value |
|---|---|
| Mode | Caller |
| Address | the IN address from the console, for example srt://198.51.100.10:9100 |
| Stream ID | leave empty — the server never asks for one |
| Latency | at least three times the round-trip time the console shows; 120–200 ms suits most links |
| Passphrase | only if you turned input encryption on (see section 6) |
Only one encoder can publish at a time. If a second one connects to the input port it will not take the stream away from the first.
No stream ID, ever. Some professional decoders have no field for it, so neither the input nor the output address will ever require one. A plain srt://address:port is always enough.
4. Giving the stream to receivers
The OUT address works in any SRT decoder, in VLC, in ffmpeg and in the free SRT player apps for phones and tablets. The receiver is the caller here as well.
With an output passphrase set, the address carries it:
How many receivers may connect at the same time is set in No. of output streams. When every place is taken, the next receiver is refused until someone disconnects. The boxes under Live connections show how many places you have and which are in use.
5. Setup Server
The SETUP SERVER button under Live Telemetry opens everything you can change about the ports and the encryption.
| Field | Meaning |
|---|---|
| IN PORT | Where your encoder sends. Allowed 9100–9200, normally 9100. |
| No. of output streams | How many receivers may watch at the same time: 2, 4, 6, 8 or 10. |
| Output stream encryption | One passphrase for every receiver on the shared output port. |
| OUT PORT | Where receivers connect. Allowed 9201–9999, normally 9202. |
| Input stream encryption | A passphrase your encoder must use to be let in at all. |
Save & Restart writes the settings and restarts the streaming service. This cuts every connection — the incoming stream and all receivers — and the server needs roughly 30 seconds to a minute to come back. The encoder and most receivers reconnect by themselves once it is up. Do it between programmes, not during one. Cancel closes the window and changes nothing.
6. Passphrases
SRT encrypts with AES-128. A passphrase is 10 to 79 characters: letters, digits and . _ -. The Generate button next to each field creates a strong random one; copy it before you save.
On the input
Tick Use passphrase on input port and only an encoder that knows it can publish. Anything else is refused during the SRT handshake, before a single packet of video is accepted. Put the same passphrase in your encoder, or it will not connect at all.
On the output
Tick Use one passphrase for all viewers on the shared output port. From then on the address alone is not enough to watch — the receiver needs the passphrase too. The console writes it straight into the OUT address so you can hand over the whole URL in one piece.
Both settings apply after Save & Restart, which restarts the server: everyone already connected is cut off for roughly 30 seconds to a minute and has to reconnect — with the new address or the new passphrase.
7. Reading the telemetry
Live Telemetry describes the stream arriving from your encoder. It refreshes every second.
| Field | What it tells you |
|---|---|
| Server Status | listen when nothing is publishing, or connected from and the encoder's address. |
| Stream started at | When the current encoder connected. |
| Last drop/loss reset at | When the loss and drop counters were last cleared. |
| Output traffic | How much this server has sent out this month. This is the figure your traffic allowance is measured against. |
| Duration | How long the current stream has been running. |
| msRTT | Round-trip time to the encoder, in milliseconds. Steady is good; jumping around means a congested path. |
| pktRcvLoss | Packets that arrived damaged or out of order and had to be asked for again. SRT recovers these — a slowly rising number on a long stream is normal. |
| pktRcvDrop | Packets that arrived too late to be used and were thrown away. This is the one that costs you picture. It should stay at zero. |
| msRcvBuf | How much video is sitting in the receive buffer. It should sit near your latency setting. |
| mbpsRecvRate | Incoming bitrate in Mbit/s. |
| msRcvTsbPdDelay | The latency the two sides agreed on. |
Both counters reset to zero when a new stream starts, so the numbers always describe the stream you are watching now. Reset Drop/Loss clears them without touching the stream — useful when you have fixed something and want to see whether it worked.
8. The performance graph
The Graph view draws the last minutes of three values: msRTT, msRcvBuf and pktRcvDrop. The two lines show the shape of the link; the red bars appear only in the second a packet was actually dropped, so a graph with no red in it is a clean link.
9. Connection log
The Log view is a permanent record of every connection and disconnection — your encoder on the input and every receiver on the output. Nothing is ever removed from it.
- Each row carries the time, the event (connect or close), the side, the port and the address with its source port.
- The drop-down filters by side; the port box narrows it to one port.
- .csv and .log download the record for your own archive or for a report to a client.
- ban at the end of a row blocks that address. A banned address appears in the bar at the top with an unban button next to it.
A ban on the output side cuts that receiver off within seconds and frees the place for someone else. A ban on the input side stops that encoder from publishing again.
10. Drops
The Drops view lists episodes of dropped packets on the incoming feed — the encoder-to-server path only. An episode is a run of consecutive bad seconds, and each row shows when it started, when it ended, how long it lasted, how many packets were lost and the worst round-trip time during it.
This is what you show when someone says the picture broke up: either there are episodes at that minute, and the network is at fault, or there are none, and the problem is somewhere else. On a healthy link the window simply says there is nothing to report.
11. Live connections and bans
At the bottom of the console there is one box per output you have paid for. A green dot and an address mean somebody is watching; a red dot and No connection mean the place is free. The ban button next to a connected receiver cuts it off immediately.
12. A port per receiver Pro
In the PRO edition every recipient gets their own port with their own passphrase, instead of everyone sharing one address. You can hand a different URL to each client, see what each of them is doing, and cut one off without disturbing the others.
The ports are created when the server starts and are listening from the first moment, so giving a port to a new client is only bookkeeping — nothing restarts and nobody is interrupted.
The Outputs table
| Column | Meaning |
|---|---|
| Name | Whatever you want to call this recipient. Click to set it. |
| Port | The port they connect to. |
| Block | Closes the port in the firewall, without a restart. Use it to park a port between clients. |
| State | Free, assigned, or connected. |
| Viewer | The address currently watching on that port, shown in red while connected. |
| Ban | Blocks that one address on that one port. |
| kbps / RTT | Live bitrate and round-trip time for that recipient alone. |
| Drop | Packets dropped on that port since the viewer connected; shown in red once it is above zero, and cleared when they disconnect. |
| 🔒 | The port has its own passphrase. |
| Limit | How many viewers that port accepts. |
At the end of each row: clear releases the port and wipes the name, log opens the connection history of that port alone, and copy URL puts the complete address, passphrase included, on the clipboard — ready to paste into an e-mail.
Output ports in Setup
| Setting | Meaning |
|---|---|
| Number of ports | How many output ports to create, 1 to 100. |
| Viewers per port | How many viewers each port accepts. |
| Port range | The range the ports are taken from, between 9201 and 20000. |
| Protect every port with its own passphrase | Strongly recommended. Without it, anyone who finds the port can watch. |
| Pick ports randomly inside the range | Scatters the ports instead of taking them in sequence. |
| Shared output port open to the internet | Opens or closes the single shared port. Closed by default on a PRO server, and this one switch works immediately, without a restart. |
Ports that stay inside the range keep their passphrase, so the URLs you have already handed out keep working when you add more ports. The server reads this list when it starts, so Save output ports takes effect after a restart; the console tells you when a restart is still pending.
13. Traffic and restarts
Output traffic in the telemetry is the total this server has sent out during the month. Ten receivers of an 8 Mbit/s stream is 80 Mbit/s leaving the server, which is roughly 860 GB a day — worth a thought before you hand the address to more people than you planned.
Capacity. All packages and their default settings are tested with an input stream of about 22 Mbit/s. The top bar of the console shows the load of the server (CPU, RAM and load). You are free to try a higher bitrate or more receivers at your own risk — keep an eye on that bar and try to keep the server below 80 % CPU; above that it can start dropping packets.
Restart Server restarts the streaming service, not the machine. It takes a few seconds, the encoder reconnects on its own, and receivers have to reconnect. Your settings, your log and your bans all survive it.
14. If something is wrong
The encoder will not connect
Check that it is in caller mode, that the port matches the IN address, and that the passphrase is exactly right if input encryption is on. A wrong passphrase fails during the handshake, which most encoders report only as a generic connection error. Check the Log view: if there is no connect line on the input side, the packets are not reaching the server at all — look at the firewall at your end.
A receiver cannot connect
Either every place is taken — count the green dots under Live connections — or the address or passphrase is wrong, or that address has been banned. The banned addresses appear in the bar at the top of the Log view.
The picture breaks up
Look at pktRcvDrop and at the Drops view. If drops are climbing, raise the latency in your encoder: the usual cause is a latency set too low for the round-trip time of the link. If drops stay at zero while the picture is still bad, the problem is before the server — the encoder itself or the camera feed into it.
The numbers look stuck
The console refreshes once a second. If every field has frozen, reload the page in the browser; if that does not help, use Restart Server.
Where to get help
Write to info@srtcloud.eu. It helps a great deal if you include your server name, the time the problem happened, and the .csv download from the Log view.