Latency policy \ Lfr and various fixes #443
Open
+2,519
−2,526
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit d4ef087.
- seems to be too aggressive in logs
- Early in my experiments, I had accidentally forced balanced pacing and inverted LFR logic . I've since fixed these issues in my experimental branch, and it's now time to port those fixes here.
- Universal LFR and renderer-default timeout when off. Minimal logging aligned to behavior.
- fixes: java.lang.ClassNotFoundException: com.samsung.android.view.SemWindowManager on non samsung devices
- Drop reflective setFrameRate + FIXED_SOURCE (causes stutter)
…0 fps stream \ Lfr fixes - LFR: drain to newest and update per dequeued frame - Decode latency is now measured on all decoded frames, not only on displayed ones. - Numbers with hz \ stream fps mismatch may look higher than before, but they’re finally accurate. - Update stats before any drop/pacing logic. - Old metric sampled mostly frames that survived to render - New metric includes every decoded frame, so it reflects the real decoder cost. I noticed the bug with my tab. If the G99 needs ~6–7 ms to decode at 60 FPS, it won’t hit 3.5 ms at 120 FPS for 1440×900/25 Mbps. Higher FPS lowers input lag, but it won’t cut decode time especially on weaker SoCs.
- LFR bypassed on Balanced/CapFPS to avoid heavy drops \ stuttering on weaker devices (eg.mtk g99) - Per-profile dequeue timeouts: Balanced 1000 µs, CapFPS 1500 µs, Max Smoothness 2000 µs, others 500 µs. - 0 µs dequeue only in LFR My S20 FE can run Balanced mode with LFR enabled without any issues, but my Tab with the G99 processor struggles significantly, experiencing heavy frame drops and severe stuttering. Instead of leaving this choice to users, we should force LFR off with both Cap FPS and Balanced modes. Max Smoothness \ LFR appears to work well together with both devices, so I'll leave that untouched for now, but i'll monitor this in the future.
- Add hdrActive flag on decoder renderer - Detect HDR via BT.2020 + (PQ|HLG) on output format change - Append "HDR"/"SDR" in Perf Lite next to rendered FPSPS
- Use standard Android color constants and proper BT.2020 + PQ/HLG criteria for HDR detection
Owner
|
Thank you, I'll take a look when I get some time. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello,
I've just finished importing and refining some fixes from my experimental branch. This should address some issues present on my early experimental branch merged previously.
In short:
Fix Fps\Hz mismatch on most devices
Fix decoding latency stat mismatches when FPS > refresh rate
Various fixes around LFR , bypassing it with Balanced and CapFps modes ( heavy stuttering / drops on low end devices with these two , better safe than sorry)
Show HDR/SDR information in the overlay lite
Gate SemWindowManager to Samsung devices only
Reverted some commits that were causing regressions
I've done some quick testing on my devices and everything seems to be working properly. However, since I haven't had much time to playtest extensively, testing is needed.
There are additional fixes I could import from my fsr_reboot branch, but I currently don't have time to look into them further (I forced myself to complete this PR tonight).
EDIT:
Noticed a problem with a commit, pushed another branch:
https://github.com/derflacco/moonlight-android/tree/moonlight-noir_PR2
I'm not sure why, but sometimes Git displays some commits as if the entire codebase was changed, even though in Android Studio I only see the specific lines I modified. Pushing again (or force pushing, which I won't do anymore) seems to resolve the issue fo me.
If you want, i will open a new PR tomorrow. Goodnight!