An AI-tuned bandwidth controller measures the path between your two devices in real time, classifies it as fiber LAN or anything-else WAN, and picks the bitrate envelope that minimises both lag and pixelation. Not a one-size-fits-all curve, not a slider you have to drag — different rules for a gigabit LAN and a 4G hotspot, chosen automatically in the first second of the session.
Round-trip time — how long a tiny test packet takes to bounce from your client to your host and back — is the single number that separates a fiber LAN from anything else. Remio measures it in the first one to two seconds of every connection, then never has to ask again.
The moment the two devices say hello, Remio sends a tiny packet to the other end and times how long it takes to come back. On a direct gigabit LAN that round-trip is around one to five milliseconds. Over Wi-Fi on the same network it sits closer to ten. On a 4G or 5G link it lands somewhere between forty and a hundred. Through a relay that has to bounce traffic across a region or two, it can climb past eighty even on a fast modem.
Anything under 15 ms gets treated as fiber LAN — the picture is going to look pixel-perfect, the encoder can hand off frames as fast as it can make them, and there is no need to be conservative. Anything 15 ms or more is treated as the wider world. Wi-Fi from another room, a coffee-shop hotspot, an LTE link on a train, a relay server in another city. The bandwidth controller switches gears.
This single threshold is the whole decision. It runs once per session, so the encoder is not constantly second-guessing itself mid-stream, and the user never feels the picture wobble while the algorithm makes up its mind. Where one curve would constantly chase a moving target, two envelopes lock in the right behaviour and let the encoder do its job.
The choice is hidden from you on purpose. You connect, the picture appears, the lag is appropriate to the network you happen to be on. There is no setup screen, no quality slider, no “LAN mode” toggle to remember to flip. The first round-trip is the input, the right envelope is the output, and the rest of the session inherits the good decision.
A single adaptive curve has to compromise between two networks that have nothing in common. Two envelopes — one for fiber, one for everything else — let each network type get the bitrate behaviour it actually needs.
The LAN envelope starts at eight megabits per second, holds that as the floor, and lets the encoder spike up to thirty when a keyframe demands the headroom. The point of the eight-megabit floor is simple: that is the rate the encoder is actually producing for desktop content at 60 frames per second, so the network pipeline never throttles below what the encoder is putting out. If the floor sat lower, the encoder would queue, and a queue is just another word for lag.
The WAN envelope starts at two megabits, drops as low as three hundred kilobits when the link gets ugly, and caps at fifteen megabits because pushing harder on a constrained path just causes packet loss. A bad cellular handoff or a saturated relay does not have to drop the stream — the encoder simply gives the network less to chew on, holds the frame rate, and trades a little detail until the path recovers.
Both envelopes share the same encoder, the same decoder, and the same frame-by-frame render policy. What changes is where the floor sits, where the ceiling sits, and how aggressively the encoder is allowed to push when a brief surge happens. On a LAN that surge is a routine keyframe; on a WAN it is the difference between a tolerable session and one that drops out completely.
Picking the envelope once per session matters as much as the envelope itself. Switching mid-stream means the encoder has to re-base its rate-control state, which causes a visible quality drop while it settles. The first round-trip is the commitment — we live with it for the rest of the connection, and the connection is the better for it.
Four numbers do all of the work. The threshold, the LAN window, the WAN window, and the render policy. They are the same across every codec and every platform Remio runs on.
Bitrate is only half the story. The other half is the rules around what to render when packets arrive late, when the network briefly stalls, or when a frame goes missing entirely.
The encoder runs ultra-low-latency H.265 with B-frames disabled. That means every frame depends only on what came before it — never on what is coming next. B-frames squeeze out extra compression by referencing the next frame too, but they cost a round-trip of buffer to do it. For a movie that is invisible. For a remote desktop where you are clicking and typing, that buffer is the lag.
One screen capture per frame interval, one encoded frame out, sent immediately. No frame pacing, no encoder queue, no “catch up” logic. If the screen has not changed, the encoder still ticks — it just sends a tiny frame — so the cadence stays locked at 60 frames per second and the client never has to guess whether the next frame is late or simply skipped.
On the receiving side, the client renders the newest frame on every frame interval and throws away anything older. There is no playout buffer. If a packet goes missing, the client does not ask for it to be retransmitted — it asks for a fresh keyframe instead. Replaying a frame that is now half a second stale would mean showing the user an old picture of their desktop, and an old picture of a remote desktop is just a lie.
Add it up — one frame to capture, one to encode in hardware, one or two milliseconds on a LAN to transit, one to decode in hardware on the other end, and the pixel arrives in front of you in under twenty milliseconds end-to-end. On a WAN the network leg gets longer, but the rules around frames stay the same: render the newest, drop the rest, and ask for a keyframe instead of waiting for a retransmit.
The LAN and WAN envelopes are not tied to a specific codec or a specific operating system. The same two rules apply whether the connection is H.265 between two Macs, H.264 to an older Windows machine, or AV1 to an Android device with the right hardware.
H.265 is the primary codec because it gives the best quality-per-bit for desktop content, and because every Mac, every iPhone, every iPad, every modern Windows GPU, and every recent Android chipset has a hardware encoder or decoder for it. Hardware means the work happens on a dedicated silicon block instead of the main CPU — it is faster, more energy-efficient, and leaves the rest of the machine free to do what it was doing before the session started.
H.264 is the fallback for the small set of devices that cannot hardware-encode or hardware-decode H.265. It uses slightly more bandwidth for the same picture quality, but it works everywhere, and the same LAN-or-WAN envelope wraps around it without any change to the algorithm. AV1 sits on the third tier — it is the most efficient codec of the three but the hardware story is still catching up, so Remio uses it where it is supported and falls back gracefully where it is not.
On the encoding side, that means VideoToolbox on macOS, AMF on Radeon GPUs, QSV on Intel integrated graphics, and NVENC on NVIDIA cards under Windows. On the decoding side, it is VideoToolbox on Apple devices and MediaCodec on Android. None of this is exposed to the user — you pair two devices, the engine picks the best codec both sides can hardware-handle, and the envelope picks itself based on the network.
The result is that the same adaptive behaviour ships on every supported platform without separate code paths for each operating system. A Mac talking to an iPhone gets the same envelope logic as a Windows PC talking to an Android tablet, with hardware acceleration on both ends and no software fallback to slow anything down.
Numbers in a table are easy. Here is what the adaptive envelope buys you in three settings most users will actually meet.
On a gigabit fiber LAN with both devices wired or on the same Wi-Fi 6 router, the picture is pixel-perfect at 4K and there is no measurable lag between moving the cursor and seeing it move. Text is razor sharp at 100 percent zoom. Scrolling a website at full speed looks identical to scrolling on the host machine itself. This is the LAN envelope doing what it was built for — the encoder is producing at eight megabits, the network has thirty to spare for keyframe headroom, and nothing in the pipeline is throttling anything.
On a coffee-shop Wi-Fi network shared with twenty other laptops, the stream holds 60 frames per second and the picture stays clean. When the network briefly congests — a microwave goes on, someone joins a video call — you might see a fraction of a second of blockiness in a corner of the screen, then it clears. The encoder traded a little detail for the frame rate, the client did not stall, and the session never felt like it was about to drop. This is the WAN envelope absorbing a punch the LAN envelope would have flinched from.
On a 4G LTE hotspot from a phone in your pocket, the stream sustains a clean 1080p picture at 60 frames per second on most modern carriers. Detail in high-motion scenes is softer than it would be on the LAN — the encoder is being asked to fit the picture into two or three megabits instead of eight — but the responsiveness is the same. You click, the click registers. You type, the keys echo. The remote desktop feels like a remote desktop, not a video call of one.
None of these three sessions required a settings change, a quality selection, or a network test before starting. The first round-trip arrived, the envelope picked itself, and the experience matched the network you happened to be on.
Five questions the adaptive-quality model tends to raise — honest answers below.
Install Remio on the computer you want to reach and on the device you want to reach it from. The bandwidth controller picks the right envelope on the first round-trip — you do not configure anything, you just see the picture.
macOS, iOS, iPadOS, Windows, and Android. Adaptive quality on by default.