1 · Encode budget
Per-frame budget
33.3ms per frame
1000 ÷ 30 fps
Typical hardware encode time
~5 ms
Headroom inside the frame
28.3 ms
Free tool · screen sharing and remote desktop
Screen sharing latency & bandwidth calculator
Plan a screen-share pipeline before you ship it. Set the resolution, frame rate, codec, available bandwidth, and round-trip time; the page returns the per-frame encode budget, an estimated bitrate, a latency split, and what to downgrade when the link is tight.
Every number on this page is an estimate. The figures come from the formulas shown below, not from a measurement of your encoder, network, or device. Treat them as planning inputs, then verify against your own pipeline.
Inputs
Describe the stream
AV1 hardware encoding is not available on every GPU or mobile SoC. The estimate below assumes hardware encoding; a software fallback can be several times slower and may miss the frame budget.
Results
2 · Bitrate need
Estimated bitrate
6.8Mbps
Range 5–8.7 Mbps, at a mid assumption of 0.11 bits per pixel per frame (bpp).
Available bandwidth
20 Mbps
Headroom over the upper estimate
11.3 Mbps
3 · Latency budget
End-to-end estimate
150ms
around the 150 ms interactive reference
| Stage | Estimate | Share | Allowance | Flag |
|---|
4 · Degradation trade-off
Keep resolution, or keep frame rate?
At 20 Mbps with the mid bpp assumption for H.264, the two downgrade strategies land here:
| Metric | A · Keep resolution, drop fps | B · Keep fps, drop resolution |
|---|---|---|
| Frame rate | 30 fps | 30 fps |
| Resolution | 1920 × 1080 | 1920 × 1080 |
| Scale vs input | 100% | 100% |
| Estimated bitrate | ~6.8 Mbps | ~6.8 Mbps |
| Estimated encode time | ~5 ms | ~5 ms |
| Encode vs frame budget | — | — |
| Binding limit | — | — |
| Estimated end-to-end latency | ~150 ms | ~150 ms |
| Motion | Smooth at the target rate. | Keeps the target cadence. |
| Text and fine detail | Full resolution; text and UI stay sharp. | Unchanged. |
| Best for | Documents, code, dashboards, slides. | Video, animation, cursor motion, cloud gaming. |
Recommendation
Formulas and assumptions — open to check the math
Frame budget
budget_ms = 1000 / fps
The time each frame may spend in an encode step before the next frame is due.
Bitrate
Mbps = width × height × fps × bpp / 1,000,000
A coarse planning estimate. Screen content with large static regions can cost far less; noise, motion, and 4:4:4 chroma can cost more.
Max fps at full resolution
max_fps = bandwidth_bps / (width × height × bpp)
Column A holds the input resolution and solves for the frame rate the link can carry.
Downscale factor
scale = √( bandwidth_bps / (width × height × fps × bpp) )
Column B holds the target frame rate and solves for the pixel count. The linear scale is the square root of the area ratio.
Encode-fit scale
scale_enc = √( 2,073,600 × (budget_ms / base_ms)^(1 / 0.85) / pixels )
Column B takes the smaller of the bandwidth scale and the encode-fit scale, so the target frame rate also fits the encoder. If the input already fits, the scale is capped at 100%.
Encode time
t ≈ base_ms × (pixels / 2,073,600)^0.85
Planning estimate for a hardware encoder. Base at 1080p: H.264 5 ms, HEVC 8 ms, AV1 11 ms. Device, preset, content, and thermal state move this a lot.
Decode time
decode ≈ 0.6 × encode
A rough asymmetry factor; hardware decoders usually run ahead of encoders.
Total latency
capture + encode + RTT/2 + 2 × frame + decode + render
Capture is one frame interval. Network is one one-way trip. Jitter buffer is two frames. Render is 16.7 ms for a 60 Hz display.
bpp assumptions
H.264 0.08–0.14 · HEVC 0.05–0.09 · AV1 0.035–0.07
Bits per pixel per frame. The calculator uses the midpoint for single-value outputs and the ends of the range for the bitrate band.
- These are estimates, not measurements. No encoder, device, or network is benchmarked here.
- The bpp bands are planning assumptions for interactive video and screen content. They are not codec guarantees and do not include rate-control behavior.
- Encode and decode times assume hardware acceleration. AV1 in particular may fall back to software, where encode time can be several times higher.
- Column A is capped by the lower of the bandwidth limit and the encoder throughput (1000 / encode time). Column B downscales until both the bitrate and the per-frame encode time fit.
- Network latency is modeled as RTT ÷ 2, with no retransmission, queueing, or congestion. Wi-Fi, relays, and busy uplinks add real delay.
- The jitter buffer is fixed at two frames. Real implementations often use one to five frames, or adapt the buffer at runtime.
- The 150 ms line is a common interactive reference, not a requirement. Cloud gaming often targets lower; remote support and presentations tolerate higher.
- Raising the frame rate shrinks the frame-interval and jitter terms but increases the bitrate. Lowering the frame rate does the opposite.
Next step
Want the full checklist and the measurement scripts?
The checklist covers the pipeline stages above, the signals worth capturing, and how to read them without guessing. The scripts are the ones to run on your own build.
Get the checklist — code FIRST50 →The link carries discount code FIRST50. No tracking script is used on this page.
Screen sharing FAQ
Why does my screen share stutter with 0% packet loss?
Packet loss is only one source of delay. The model here separates encode time, bitrate, and jitter: if encode time runs past the per-frame budget of 1000 ÷ fps, expect dropped frames or a lower effective frame rate; when bandwidth is the binding constraint, the stream degrades instead. The jitter buffer is fixed at two frames, and the latency estimate excludes retransmission, queueing, and congestion, so Wi-Fi, relays, and busy uplinks can add real delay.
What latency budget should screen sharing target?
The 150 ms line is a common interactive reference, not a requirement. Cloud gaming often targets lower, while remote support and presentations tolerate higher. Treat it as a planning input, then verify against your own pipeline.
Does resolution or frame rate matter more for screen sharing?
It depends on the content. Keeping resolution and dropping frame rate is best for documents, code, dashboards, and slides; keeping frame rate and dropping resolution is best for video, animation, cursor motion, and cloud gaming. For text use the first; for motion use the second.