Best scrcpy settings to fix lag and stuttering

My scrcpy mirror used to freeze for a full second every time I swiped between home screens on a Pixel 6a, plugged into a cheap USB-C hub. Swapping the hub for a direct cable and capping --max-size at 1024 fixed it in under two minutes.

Two flags, and the freeze was gone.

If you’ve landed here from the scrcpy GitHub repo, there’s a years-long thread, issue #4494, full of people describing this exact problem on wildly different phones and host machines. scrcpy is free and open source, so there’s no support ticket to file when the mirror looks fine on the maintainer’s test rig and stutters on yours. What you’ve got is a CLI with roughly forty flags, and most write-ups just paste the full scrcpy --help output and leave you to guess which ones matter.

This list is for anyone running scrcpy to control or record an Android device from a desktop: phone testers, support staff mirroring a customer’s screen, QA people scripting against a real device. It’s narrowed to the seven flags that actually move the needle on lag and stutter specifically, not window behavior or audio sync. I tested each one the way I’d troubleshoot a support call: change one flag, reproduce the stutter, note what got better and what it cost. For getting scrcpy connected in the first place, I’ve got a separate walkthrough at /blog/scrcpy-guide-control-android-from-desktop, and more adb troubleshooting sits in the rest of the blog.

how I picked

• had to be a real, current scrcpy flag, not a third-party fork or a registry hack that breaks on the next update
• tested by trade-off: what fixing the stutter costs you in latency, cpu, or picture quality, not just whether it looks smoother
• weighted toward flags that show up repeatedly in scrcpy’s own GitHub issues as the fix people actually reported
• had to work on all three platforms scrcpy officially supports, Windows, macOS, and Linux
• excluded anything that only touches window chrome, hotkeys, or clipboard sync, since none of that affects frame delivery
• ranked partly on how often I reach for it myself mid-session when a mirror goes choppy

One honest caveat: this is built from Pixel and Samsung hardware I’ve actually had in hand, plus the patterns that repeat across that GitHub thread. On some obscure MediaTek chipset with a quirky encoder, your mileage may vary, and scrcpy --list-encoders becomes more useful than anything on this page.

the picks

–video-codec: stop av1 and h265 fighting your hardware

scrcpy defaults to h264, and for lag and stutter specifically, that default is usually right. h264 has the widest hardware decoder support on both the phone’s encoder side and your desktop’s decoder side, so it’s the cheapest option computationally. h265 buys better quality per megabit and av1 buys even more, but both ask more of whichever chip decodes on your desktop. If that’s an older Intel iGPU without AV1 hardware decode, you’ve traded a network problem for a decode problem, and the stutter doesn’t go away, it just moves.

Run scrcpy --list-encoders to see what your specific device actually offers before switching. Not every phone exposes h265 or av1 encoders even when the SoC technically supports them.

pros: - h264 has the broadest hardware decode support, the safest default when troubleshooting from scratch - switching codec is one flag, cheap to test and cheap to revert - --list-encoders shows exactly what’s available instead of guessing

cons: - h265 and av1 can make stutter worse on older desktop hardware even though they look sharper in screenshots - not every device or Android build exposes all three codecs

cost: free, it’s a stock scrcpy flag. scrcpy repository

–max-size: the single biggest lag fix on this list

This is the flag I reach for first. --max-size=1024 (or -m 1024) caps the longer edge of the mirrored image in pixels. Mirroring a 1440p flagship phone at native resolution means the device encodes, and your desktop decodes, roughly twice the pixel count of a 1024px cap. On a mid-range phone or an older laptop, that gap alone causes visible stutter, especially during fast scrolling or video playback inside the mirrored app.

Dropping to 1024, or even 800, usually resolves it outright. You lose some sharpness on small text, which matters if you’re reading fine print, but for control and testing work it rarely does.

pros: - often fixes stutter on its own, no other flag needed - scales cleanly, dial it up or down with one number - helps every downstream stage, encode, transfer, and decode, at once

cons: - visibly softer image at low caps, noticeable on small text - doesn’t help if the bottleneck is the network link rather than raw pixel count

cost: free. scrcpy repository

–video-bit-rate: match the pipe, not the panel

Default bit rate is 8 Mbps (-b 8M), picked as a reasonable middle ground, not a fit for your specific connection. Over a loaded USB 2.0 hub, or Wi-Fi shared with a few other devices, 8 Mbps of video arrives in bursts rather than a steady stream, and scrcpy drops or delays frames to keep up. That reads as stutter.

Lowering it to -b 2M or -b 4M smooths playback at a real cost in picture quality, you’ll see compression artifacts in fast motion. Going the other way, if your connection is solid, a real USB 3 cable, not a hub, and the picture looks blocky rather than choppy, raising it to -b 16M improves quality without adding lag, since the bandwidth is actually there.

Older scrcpy releases called this flag --bit-rate rather than --video-bit-rate. If yours doesn’t recognize the current name, check scrcpy --version and scrcpy --help on your installed copy, current as of September 2026, when I put this list together.

pros: - direct, proportional control over bandwidth demand - fixes bursty, congested-link stutter that resolution capping alone won’t touch - safe to raise on a strong connection if quality, not lag, is the complaint

cons: - too low and the image turns visibly blocky during motion - doesn’t fix stutter caused by the host machine’s own decode or render bottleneck

cost: free. scrcpy repository

–video-buffer: trade latency for smoothness on purpose

Default buffering is 0ms. scrcpy shows each frame the instant it arrives, prioritizing responsiveness over smoothness. If your connection delivers frames in uneven bursts, common over --tcpip or a congested USB bus, a zero buffer means every burst shows up as a visible stutter, even when the average frame rate is fine.

--video-buffer=50 tells scrcpy to hold frames for 50ms before displaying them, giving it room to smooth out that jitter. It’s a real trade-off, not a free fix. Every millisecond you add here is a millisecond of extra delay between something happening on the phone and you seeing it on screen.

For passive viewing, fine. For precise taps or timing-sensitive input, that lag is exactly what you don’t want.

pros: - directly targets jitter-driven stutter that codec or bit-rate changes don’t touch - adjustable in small increments, so you can find the minimum that works - combines well with the other picks here instead of replacing them

cons: - adds real input lag proportional to the buffer size, a bad trade for precise control work - doesn’t fix the underlying cause, it papers over it

cost: free. scrcpy repository

–max-fps: stop chasing a 120Hz panel you don’t need

Plenty of current Android phones run 90Hz or 120Hz displays, and scrcpy tries to mirror at that native rate unless told otherwise. Encoding and decoding 120 frames a second takes real work on both ends, and if either side can’t keep up, frames drop, which is stutter by another name.

--max-fps=30 or --max-fps=60 caps the capture rate outright. For anything short of fast-motion gaming, 30fps mirroring looks and feels fine, and it cuts encode and network load substantially. This is the flag I’d try second, right after --max-size, if the first didn’t fully clear things up.

pros: - cuts load on both encode and decode sides without touching resolution or bit rate - particularly effective on 90Hz and 120Hz phones, an increasing share of the market - easy to raise again for the rare case where frame rate genuinely matters

cons: - visibly less fluid for gaming or fast-scroll testing, by design - won’t help if your device already runs well below your --max-fps value

cost: free. scrcpy repository

–render-driver: rule out your desktop’s GPU, not just the phone

This one’s different, it doesn’t touch encoding or the network at all. scrcpy renders the mirrored video through SDL, and SDL picks a render backend automatically, opengl, direct3d on Windows, or a software fallback if it can’t find a working GPU path. On machines with flaky GPU drivers or an old integrated chip, SDL sometimes falls back to software rendering without telling you, and that shows up as stutter indistinguishable from an encode or network problem.

--render-driver=opengl or --render-driver=direct3d forces a specific backend. If stutter persists after you’ve capped resolution, bit rate, and frame rate, and you’re on a laptop with a dated GPU, try this before assuming it’s a phone or connection problem.

pros: - catches a category of stutter, host-side rendering, that the other flags can’t touch - fast to test, one flag and an immediate visual result - useful diagnostic even if you end up leaving it on the default

cons: - only helps when rendering is actually the bottleneck, a minority of cases - available driver names differ by OS, so check what your platform actually supports

cost: free. scrcpy repository

USB cable vs –tcpip: pick your transport before you touch a flag

This last one isn’t a tuning flag so much as a decision, but it undoes half the flags above if you get it wrong. A direct USB cable, ideally USB 3 rather than 2, gives you a stable, dedicated pipe between phone and desktop. Connecting over --tcpip instead routes the same video stream through your Wi-Fi network, which means router congestion, other devices on the same band, and NAT overhead are now part of your stutter problem. No amount of bit-rate or buffer tuning fully compensates for a noisy radio link.

I’ll say the unpopular thing here: wireless mirroring is convenient, but if lag is your actual complaint, plug in the cable first and see if the problem disappears before touching a single flag. I’ve watched people spend an hour tuning --video-bit-rate on a Wi-Fi connection that was the real problem the whole time. For when wireless adb makes sense and where it doesn’t, I wrote up the trade-offs at /blog/adb-over-wifi-wireless-debugging.

pros: - removes an entire category of network jitter no scrcpy flag can fully compensate for - USB 3 gives meaningfully more bandwidth headroom than most home Wi-Fi - free to test, just plug in a cable and compare

cons: - a cheap cable or passive hub can reintroduce the exact jitter you were trying to avoid - not always practical if the device is physically out of reach or being tested remotely

cost: free, assuming you own a decent USB cable. Android developer docs: adb

comparison table

setting	price	primary strength	primary weakness
–video-codec	free	keeps decode overhead low with h264	h265/av1 need real decoder support on both ends
–max-size	free	biggest single fix for encode and decode load	softens fine detail and small text
–video-bit-rate	free	direct control over bandwidth vs picture quality	too low and motion turns blocky
–video-buffer	free	smooths bursty, jittery frame delivery	adds real input lag, ms for ms
–max-fps	free	cuts load fast on 90Hz/120Hz panels	less fluid for gaming or fast-scroll use
–render-driver	free	fixes GPU-side render stutter the others can’t touch	only helps if rendering is the actual bottleneck
USB vs –tcpip	free	removes network jitter entirely	cheap cables and hubs can undo the benefit

how to choose

Work out which layer is actually broken before touching anything. Stutter has three plausible sources: the phone can’t encode fast enough, the transport (USB or Wi-Fi) can’t move the data fast enough, or your desktop can’t decode or render fast enough. --max-size and --max-fps fix the first, --video-bit-rate and a USB cable fix the second, --render-driver fixes the third. Cycling through all seven flags without narrowing the layer first is how an hour disappears without a fix.

If lag shows up specifically over Wi-Fi or --tcpip, try the cable before anything else. It’s free, takes thirty seconds, and rules the network variable in or out in one step. That’s also where remote or fleet-testing setups hit a wall no scrcpy flag solves: if the device genuinely isn’t near you, there’s no cable to plug in. For that specific case, controlling a real Android phone that isn’t physically on your desk, cloudf.one rents real Android phones on dedicated hardware in Singapore, each with a persistent Singapore mobile IP, controlled straight from the browser, so you’re not depending on someone else’s home Wi-Fi at all. Worth flagging: it’s Singapore-only, and it isn’t a drop-in scrcpy replacement for adb work specifically. There’s no self-service adb, an adb or Appium connection to a rented phone goes through a WireGuard tunnel set up on request by emailing [email protected], not something you configure yourself.

If you’re scripting against the device rather than watching it, mirror lag mostly doesn’t matter, adb commands and UI automation frameworks talk to the device directly and don’t route through scrcpy’s video pipeline. I compared the two main automation approaches at /blog/uiautomator2-vs-appium-android-automation, and covered when a real device beats an emulator for that kind of testing at /blog/emulator-vs-real-device-testing.

Start conservative and add quality back once things are smooth. My order is --max-size=1024, then --max-fps=30, then check if it’s still choppy before touching bit rate or buffer at all. Most of the reports in that GitHub thread I mentioned earlier resolve at that point without needing the other four flags. Only automate devices you own or are authorized to test, none of this is a workaround for a device’s security or integrity checks.

verdict / top pick

If I had to keep exactly one flag from this list, it’s --max-size. Best ratio of effort to result, one number, tested in under a minute, and it addresses the most common cause of scrcpy stutter, a phone encoding more pixels than the pipe or the desktop can comfortably handle. Pair it with --max-fps=30 and you’ll clear most of the reports I’ve seen in that issue thread without touching bit rate, buffer, or codec at all.

Reach for --video-buffer second, specifically if the stutter is uneven rather than constant, small freezes rather than a uniformly slow feed, since that’s the signature of jitter rather than raw throughput. And if you’ve tuned everything and it’s still choppy, stop suspecting the phone and check the cable. I’ve lost more time to a bad USB hub than to any flag on this page.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-09-15.