scrcpy
scrcpy copied to clipboard
Genymobile
Slow Connection
Environment
- OS: Windows 10
- scrcpy version: ScrCpy 1.21
- installation method: Windows release via zip file
- device model: Xiaomi Redmi Note 7
- Android version: Android 10 / MIUI 12
Describe the bug Getting slow connection to my phone. Sometimes it goes to 41Mbps, then slows down to a crawl. Other times, I get 0.6/0.7Mbps and doesn't speed up. Read in these forums that it's because of WiFi. If it's because of WiFi, why the f*** do we need the cable for other than keep it connected? I don't get frameskips in the console, but it's clear the viewer is skipping frames. Also, I'm running it at max resolution my phone supports. I know the speed problem isn't PC performance since SCRCPY barely puts a dent on performance. CPU use with it is barely 11%. Also, I have a very powerful router with 5Ghz capacity and the phone is close to it. Console logs follows below. Despite the "reported" speed, it's pretty slow.
scrcpy 1.21 <https://github.com/Genymobile/scrcpy>
C:\Apps\SCRCPY\scrcpy-server: 1 file pushed, 0 skipped. 41.8 MB/s (40067 bytes in 0.001s)
[server] INFO: Device: Xiaomi Redmi Note 7 (Android 10)
INFO: Renderer: direct3d
INFO: Initial texture: 1080x2336
Please do not post screenshots of your terminal, just post the content as text instead.
If you record the video (scrcpy --record file.mp4), then play the file, is it laggy?
I don't get frameskips in the console, but it's clear the viewer is skipping frames
What is the framerate in the console? (copy few lines of the output of scrcpy --print-fps)
If you reduce the resolution (scrcpy -m1024), is it better?
If you reduce the bitrate (scrcpy -b2M), is it better?
Over USB, is it better?
Is there in fact a way to change it to pure USB instead of going through WiFi?
By default, it's over USB. You need explicit actions to connect via wifi.
https://github.com/Genymobile/scrcpy#tcpip-wireless https://github.com/Genymobile/scrcpy#multi-devices
Issue continues, whenever I scroll the screen, the screen goes pixelized. On a USB 3.0, I expect at least a stable bitrate.
Issue continues, whenever I scroll the screen, the screen goes pixelized
The bitrate is independant of the connection type.
Use a higher bitrate:
scrcpy -b20M
No it's not. Even over wifi it should not be laggy.
Here is a demo I did 4 years ago (a very old version): https://www.youtube.com/watch?v=LLpcLB0QlJg
I don't get frameskips in the console, but it's clear the viewer is skipping frames.
The problem is on the device then.
scrcpy --record file.mp4
Is the recorded file laggy?
Also, does it work better with a lower definition? (scrcpy -m1024)
Or with another encoder: https://github.com/Genymobile/scrcpy#encoder
Also, does it work better with a lower definition? (
scrcpy -m1024)Or with another encoder: https://github.com/Genymobile/scrcpy#encoder
No, the device plays the game flawlessly, no lag at all. It's a quite new device and works well streaming to TV(no lag compared to SCRCPY).
No, the device plays the game flawlessly, no lag at all.
That doesn't mean that the hardware encoder on the device is able to encode at the same rate.
I asked you to do some tests to locate the source of the problem, but you did not answer.
No, the device plays the game flawlessly, no lag at all.
That doesn't mean that the hardware encoder on the device is able to encode at the same rate.
I asked you to do some tests to locate the source of the problem, but you did not answer.
Well, it does encode well when streaming to TV. I don't get lag on TV, compared to SCRCPY.
That's not the tests I asked.
How will a screen recording help solve the problem?
How will a screen recording help solve the problem?
Because of how --record is implemented, the raw H.264 stream is captured and timestamped on the device side (and muxed by the client). So if the recorded file is laggy, then the problem is on the device side (the hardware encoder), otherwise it's on the client side (rendering). You could not know if the problem is on the server on the client by just mirroring in real time.
Capture resolution and encoder selection (other tests that I also asked) might also impact the issue.
But if you don't want to track the cause of your problem, continue not to give more information :confused:
How will a screen recording help solve the problem?
Because of how
--recordis implemented, the raw H.264 stream is captured and timestamped on the device side (and muxed by the client). So if the recorded file is laggy, then the problem is on the device side (the hardware encoder), otherwise it's on the client side (rendering). You could not know if the problem is on the server on the client by just mirroring in real time.Capture resolution and encoder selection (other tests that I also asked) might also impact the issue.
But if you don't want to track the cause of your problem, continue not to give more information 😕
I made the video . It's laggy . So I guess that's a problem with my phone's hardware , right ? Sony Xperia XZ . Windows 10
just in case anyone else stumbles across this post as I did, I was having very similar problems until I killed the adb server and restarted with an updated version of adb
just in case anyone else stumbles across this post as I did, I was having very similar problems until I killed the adb server and restarted with an updated version of adb
This. I also had slow rendering with my M1 and Samsung SM-A525F (Android 13), the adb kill-server and restart worked like a charm. Thanks. :)
and restarted with an updated version of adb
The scrcpy release for Windows is shipped with the latest version of adb. Did you explicitly use another adb?
and restarted with an updated version of adb
The scrcpy release for Windows is shipped with the latest version of adb. Did you explicitly use another adb?
I've been running scrcpy for a few years, so adb version 30.0.5-6877874 was running, having shipped with scrcpy v1.17; it's hard to say in retrospect, but it's possible it was still running when I downloaded scrcpy v2.0. I don't know if it was restarting adb or the fact that I restarted with the newer adb 34.0.1-9680074 that fixed the lag issues, but it did.