What is SSTL, and how it keeps your stream up

SSTL stands for Super Simple Transport Layer. It is the piece of Super Simple IRL that takes your video, spreads it across every connection your phone has, and gets it to our cloud in one piece while you walk around. We wrote it from scratch, we wrote the other end of it too, and it is in no other app. This guide explains what it actually does, in plain English, and where its limits are.

First, what a transport is

A transport is the set of rules two machines use to move data across the internet: how it is cut into packets, what happens when a packet goes missing, how the far end knows what order the pieces go in, and when to give up on a piece that is too late to be useful. It is the plumbing under the stream, and normally nobody has to think about it.

For IRL streaming it is worth thinking about once, because it is the part of the system that decides whether you stay live when the network gets difficult.

The job a bonding transport has to do

A bonding transport takes on four jobs at the same time, continuously, while you are walking.

• Split the stream. Your video becomes a flow of packets, and each one has to be handed to one of your connections.
• Choose which connection. Not evenly. A link that is carrying well should get more, and a link that is struggling should get less, and that judgement has to be remade constantly.
• Repair what goes missing. Packets get lost. The transport has to notice, ask for the missing piece again, and get it there before the moment it was needed.
• Reassemble in order. The far end receives pieces from several connections at once, out of order, and has to hold them briefly and put them back into the single stream your viewers watch.

Get those four right and a viewer sees smooth video. Get any of them wrong and they see a freeze.

Why a moving phone is the hard case

On a desk with a fixed line, this is straightforward. On a phone in your hand on a street, three specific things go wrong, and they are the reason a bonding transport for IRL is a different problem from a bonding transport for anything else.

Connections fade, they do not fail cleanly. A network link almost never goes from perfect to gone. It degrades: capacity halves, then halves again, packets start going missing, delay stretches out. A transport that only knows the difference between up and down finds out far too late. It has to judge how well a link is doing, not whether it exists.

Packets arrive out of order, and the disorder keeps changing. Two connections do not have the same delay, so a packet sent later on the quick one can arrive before a packet sent earlier on the slow one. That is normal and expected. What makes it hard is that the difference between them is not fixed. As you move, one link’s delay grows while the other’s shrinks, so the far end’s idea of how long to wait before a piece counts as missing has to keep moving too.

A link can look alive while carrying nothing. This is the nastiest one. The phone still reports a connection, the bars are still there, and yet nothing is getting through: a congested mast, a handover that half completed, a network that accepted your data and quietly dropped it. A transport that trusts the phone’s own account of its connections will keep feeding a link that is swallowing everything you give it. It has to work out for itself, from what actually arrives at the other end, that a link has stopped being useful, and stop using it quickly.

Why owning both ends lets it react faster

Here is the part that matters, and it is the reason SSTL exists.

A transport that only owns the sending side has to be careful. It is talking to a receiver somebody else wrote, so it can only say things that receiver already understands, and it has to guess at what happened out there from what comes back. Guessing means waiting. When you are not sure whether a packet is lost or merely late, the safe move is to wait a bit longer before acting, and that caution is paid for in the one currency a live stream cannot spare, which is time.

We wrote both ends. The sender on your phone and the receiver in our cloud are both ours, so they can be specific with each other. The receiver can describe what it is actually seeing, connection by connection, rather than the sender inferring it. The sender can act on that description: shift the next packets onto the links that are genuinely delivering, send a repair down a connection that is currently healthy instead of the one that just failed you, and stop feeding a link that has gone quiet without waiting out a generic timeout first.

None of that is magic. It is just the difference between a conversation and a guess. It also means we can improve both halves at once, because we are not waiting for anyone else’s software to agree with us.

Where SSTL sits next to SRT and SRTLA

If you have read about IRL streaming before, you have met these names. One line each:

• SRT is a reliable way to send a stream over one connection. No bonding.
• SRTLA is the off-the-shelf way to bond several connections on top of SRT. It works, and it is what other apps use, usually with a relay you rent and configure yourself.
• SSTL is ours. Written from scratch rather than layered on SRTLA, with the sender on your phone and the receiver in our cloud both built by us, and it runs in no other app.

For the fuller comparison, see what is bonding and what is SRTLA.

The practical difference for you is that there is nothing to set up. No relay to rent, no address to paste, no bonding settings to learn. You link a destination once and tap go live.

What SSTL cannot do

This is the honest part, and it is worth saying plainly because the rest of this page is a claim about how well something works.

It cannot invent signal that is not there. If you are in a tunnel, a lift, a basement, or a valley with no mast for miles, every connection your phone has is dead and there is nothing for any transport to do with them. SSTL will hold on, keep trying, and pick your stream back up when coverage returns, but it cannot manufacture a network.

It cannot make one weak connection into two. With a single usable link, bonding has nothing to bond. It behaves like a good single connection stream, which is a perfectly reasonable thing to be, but the extra resilience comes from having more than one link to work with.

It cannot make a phone run cool. Heat and battery limits are the phone’s business, not the transport’s. If the encoder is falling behind because the phone is hot, a better transport does not help. See why your stream keeps dropping for that side of it.

What SSTL does is squeeze the steadiest stream possible out of the signal you actually have, and keep doing it while that signal changes under you. That is the whole claim, and it is the reason we wrote our own instead of using everybody else’s.

Frequently asked questions