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

Support refresh rates over 60 FPS in NewDisplayCapture #5505

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

eiyooooo
Copy link
Contributor

When maxFps exceeds 60, use the setRequestedRefreshRate method to configure the refresh rate for the virtual display.
Otherwise, the refresh rate will default to a maximum of 60 FPS.

Related Android commit
Code limiting the frame rate to 60 FPS

@eiyooooo
Copy link
Contributor Author

I think we could make the refresh rate of the virtual display an adjustable option for users.

@rom1v
Copy link
Collaborator

rom1v commented Nov 20, 2024

Thank you 👍

However, in practice, I never get more than 60fps:

scrcpy --new-display --max-fps=120 -m720

Whereas I get 120fps if I mirror the main display.


I think we could make the refresh rate of the virtual display an adjustable option for users.

--max-fps is intended to be a "limiter", passing --max-fps should never increase the frame rate compared to not passing the option.

Instead, we could add a new --vd-fps option, but better, maybe we could specify it directly to --new-display:

scrcpy --new-display=1920x1080@120

@eiyooooo
Copy link
Contributor Author

However, in practice, I never get more than 60fps:

scrcpy --new-display --max-fps=120 -m720
diff --git a/server/src/main/java/com/genymobile/scrcpy/video/NewDisplayCapture.java b/server/src/main/java/com/genymobile/scrcpy/video/NewDisplayCapture.java
index cadba8f1..f8d9fa05 100644
--- a/server/src/main/java/com/genymobile/scrcpy/video/NewDisplayCapture.java
+++ b/server/src/main/java/com/genymobile/scrcpy/video/NewDisplayCapture.java
@@ -183,7 +183,7 @@ public class NewDisplayCapture extends SurfaceCapture {
             // If not do so, the refresh rate of the virtual display will be limited to 60.
             // https://android.googlesource.com/platform/frameworks/base/+/6c57176e9a2882eff03c5b3f3cccfd988d38488d
             // https://android.googlesource.com/platform/frameworks/base/+/6c57176e9a2882eff03c5b3f3cccfd988d38488d/services/core/java/com/android/server/display/VirtualDisplayAdapter.java#562
-            if (maxFps > 60 && Build.VERSION.SDK_INT >= AndroidVersions.API_34_ANDROID_14) {
+            if (Build.VERSION.SDK_INT >= AndroidVersions.API_34_ANDROID_14) {

Since my monitor doesn’t support 120Hz, I removed the condition and tested with scrcpy --new-display --max-fps=30 -m720 and scrcpy --new-display --max-fps=60 -m720. The difference in refresh rates is clearly noticeable, confirming that the setRequestedRefreshRate method is indeed necessary.


Maybe we could specify it directly to --new-display:

scrcpy --new-display=1920x1080@120

I agree with this approach. 👍

@rom1v
Copy link
Collaborator

rom1v commented Nov 20, 2024

The difference in refresh rates is clearly noticeable, confirming that the setRequestedRefreshRate method is indeed necessary.

I'm not sure to understand, even without setting setRequestedRefreshRate(), you will see a difference between --max-fps=30 and --max-fps=60 (it's a limit applied to the encoder). So setRequestedRefreshRate() would be useful to go beyond 60fps.

@eiyooooo
Copy link
Contributor Author

I'm not sure to understand, even without setting setRequestedRefreshRate(), you will see a difference between --max-fps=30 and --max-fps=60 (it's a limit applied to the encoder). So setRequestedRefreshRate() would be useful to go beyond 60fps.

diff --git a/server/src/main/java/com/genymobile/scrcpy/video/NewDisplayCapture.java b/server/src/main/java/com/genymobile/scrcpy/video/NewDisplayCapture.java
index cadba8f1..f7dc49c0 100644
--- a/server/src/main/java/com/genymobile/scrcpy/video/NewDisplayCapture.java
+++ b/server/src/main/java/com/genymobile/scrcpy/video/NewDisplayCapture.java
@@ -183,11 +183,11 @@ public class NewDisplayCapture extends SurfaceCapture {
             // If not do so, the refresh rate of the virtual display will be limited to 60.
             // https://android.googlesource.com/platform/frameworks/base/+/6c57176e9a2882eff03c5b3f3cccfd988d38488d
             // https://android.googlesource.com/platform/frameworks/base/+/6c57176e9a2882eff03c5b3f3cccfd988d38488d/services/core/java/com/android/server/display/VirtualDisplayAdapter.java#562
-            if (maxFps > 60 && Build.VERSION.SDK_INT >= AndroidVersions.API_34_ANDROID_14) {
+            if (Build.VERSION.SDK_INT >= AndroidVersions.API_34_ANDROID_14) {
                 VirtualDisplayConfig.Builder builder = new VirtualDisplayConfig.Builder("scrcpy", displaySize.getWidth(), displaySize.getHeight(), dpi);
                 builder.setFlags(flags);
                 builder.setSurface(surface);
-                builder.setRequestedRefreshRate(maxFps);
+                builder.setRequestedRefreshRate(24);
                 virtualDisplay = ServiceManager.getDisplayManager().createNewVirtualDisplay(builder.build());

I did make a mistake. Now, I directly set the refresh rate to 24 and tested using scrcpy --new-display -m720. The difference in refresh rates is still noticeable.

@rom1v
Copy link
Collaborator

rom1v commented Nov 20, 2024

scrcpy --new-display=1920x1080@120

I agree with this approach. 👍

I implemented that on branch display_capture_fps.

However, I will not merge it, because the virtual display rate feature in Android is very unstable/experimental (tested on Pixel 8):

  • setting a value over 60 fps just does not work (I never get more than 60 fps, contrary to the main display)
  • on low fps (not always the same value, but until 12 fps), there are either no frame at all, or a black screen
  • on any other fps value, the target is very unstable: if I request 35 fps, I get 15~22, whereas with scrcpy --new-display=1920x1080 --max-fps=35 gives a "perfect" 35 fps.

So a scrcpy feature to configure the virtual display rate would be basically broken, it would just "not work" as expected.

I keep the branch for later if the situation improves.

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

Successfully merging this pull request may close these issues.

2 participants