Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

performance factors #1537

Closed
flyingduck234 opened this issue Jun 23, 2020 · 11 comments
Closed

performance factors #1537

flyingduck234 opened this issue Jun 23, 2020 · 11 comments

Comments

@flyingduck234
Copy link

I wonder what are the factors that plays role in performance

In terms of no of frames, resolution, bit rate and latency .

why does FHD resolution has more latency than 800? is it the cpu on mobile or desktop or its limited due to adb speed?

@rom1v
Copy link
Collaborator

rom1v commented Jun 23, 2020

It takes a bit more time to encode/decode a big video than a small one. And the bandwidth is also not the same (more data to transmit, to parse, etc).

So in practice, when mirroring in 1920×1080, the latency is about twice as high as when mirroring in 800×448: #646.

@flyingduck234
Copy link
Author

Why does it take 2x more time to transmit FHD frame compared to 800?

Is it the CPU , GPU or code?

@rom1v
Copy link
Collaborator

rom1v commented Jun 23, 2020

I think the main latency increase is the encoder (on the device) and the hardware decoder (on the computer).

@flyingduck234
Copy link
Author

flyingduck234 commented Jun 23, 2020

How can we improve the encoder and decoder performance?

Considering 8 cores on mobile and a i7 desktop cpu

@rom1v
Copy link
Collaborator

rom1v commented Jun 23, 2020

Your encoder and decoder are probably hardware components (independent of CPU) dedicated to H.264 encoding/decoding.

The only possible ways to decrease latency is to decrease encoding complexity, by changing encoding parameters.

The most obvious are width and height, but you could play with others, especially profile/level. You could custom these options using scrcpy --codec-options .... See Advanced codec options in v1.14 highlights.

@flyingduck234
Copy link
Author

flyingduck234 commented Jun 23, 2020

Thank you Very much for answering

According to this very fast profile can be used to increase faster encoding , the con would be very high file size.

Can I use this with scrcpy

@rom1v
Copy link
Collaborator

rom1v commented Jun 23, 2020

the scrcpy struggles to maintain 60fps when there is a 3d application running on the device.

The encoding is done on the device side. One frame is sent every time the surface changes, no more. So if you run an app that renders at 60 fps, you'll get 60 fps. If you play a 25 fps video, you'll get 25 fps.

If you don't get more than 60 fps, the device does not render more than 60 frames per second (many devices displays are limited to 60Hz).

#1524 (comment)

Does usb 3.1 port on mobile improve performance compared to usb 2.0?

No, the bandwidth of USB 2.0 is enough to transmit the video stream, it should not change anything.

@flyingduck234
Copy link
Author

Thank you once again.
One final question , what can I do if I wanna achieve low latency without reducing resolution. Does high end chipset like sd865 helps?

@rom1v
Copy link
Collaborator

rom1v commented Jun 23, 2020

Does high end chipset like sd865 helps?

High end chipsets are probably better (but they are "more" better on low definition).

what can I do if I wanna achieve low latency without reducing resolution?

Did you try changing the profile/level? #1537 (comment)

@masterchiang
Copy link

masterchiang commented Jun 30, 2020

@rom1v @flyingduck234

i think is a cpu performance no enough, not the usb2.0 cable bandwidth problem,. see my issue

#1553

@flyingduck234
Copy link
Author

under right circumstances scrcpy can achieve very low latency.
A high end chipset
A good computer
Try lowering resolution

You should be seeing low latecy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants