-
-
Notifications
You must be signed in to change notification settings - Fork 11.1k
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
SCRCPY Broken for Bliss OS #4784
Comments
I'm experiencing the same problem with BlissOS 16.9.7 and scrcpy ( both versions 1.25 AND 2.7 ) on Ubuntu 24.04. |
Same issue |
I encountered a similar issue when using scrcpy to remotely connect to the virtual machine BlissOS 15.9.2 created on Proxmox.
|
Try the latest version (scrcpy 3.1) first. |
I'm using BlissOS 16.9.7 running in virtualbox and trying version 3.1 gives the following results.
|
Same issue some logs from logcat
The above may be a key log |
[server] INFO: Device: [unknown] QEMU Generic Android-x86_64 (Android 13)
[server] ERROR: Capture/encoding error: java.lang.IllegalStateException: null
[server] INFO: Retrying with -m1024...
INFO: Renderer: direct3d
INFO: Texture: 1280x800
[server] ERROR: Capture/encoding error: java.lang.IllegalStateException: null
[server] INFO: Retrying with -m800...
[server] ERROR: Capture/encoding error: java.lang.IllegalStateException: null
[server] ERROR: Exception on thread Thread[video,5,main]
java.lang.IllegalStateException
at android.media.MediaCodec.native_dequeueOutputBuffer(Native Method)
at android.media.MediaCodec.dequeueOutputBuffer(MediaCodec.java:3572)
W at com.genymobile.scrcpy.video.SurfaceEncoder.encode(SurfaceEncoder.java:202)
at com.genymobile.scrcpy.video.SurfaceEncoder.streamCapture(SurfaceEncoder.java:110)
A at com.genymobile.scrcpy.video.SurfaceEncoder.lambda$start$0$com-genymobile-scrcpy-video-SurfaceEncoder(SurfaceEncoder.java:296)RN
: at com.genymobile.scrcpy.video.SurfaceEncoder$$ExternalSyntheticLambda0.run(D8$$SyntheticClass:0)
at java.lang.Thread.run(Thread.java:1012)
Device disconnected Same issue. This is the output with --no-audio appended |
I have the same issue, when I try to connect with scrcpy, I get :
BlissOs16.9.7 comes with a lot of different boot options, so one could boot for instance
I am not sure, if one of this boot options is related to the problem with scrcpy. I tried "Default FFMPEG", "QEMU KVM - Virgl - SW-FFMPEG", "No HW Acceleration" and I always could see the regular android display, but no success with scrcpy. Even a screenrecord could never be done. When I simply try to do a screen record via adb shell of my blissos 16 X86 Qemu android VM, it fails like this.. So I think this is not a concern with scrcpy but more related to the x86/bliss android..
Logcat tells me that there seems to be some trouble with the AVC Enc, but I sadly do not understand, what is causing this error. It would be great if someone give hints for a workaround, how to fix this on android x86/bliss os, so that scrcpy could work..
Full logcat ist here
|
mark |
Saw the same logcat error with the encoder on camera crashes and when I checked with scrcpy, I too hit this. Somehow wrong (ARM64) libraries are being picked up by the encoder. Some issue with linker paths maybe? Likely more an issue with Bliss than scrcpy. A really heavy-handed way out of this is |
Ah, interesting observation! Anyway, libbase.so and others are loaded and screen is correctly recorded. scrcpy works also in this situation. For sure, no other of my arm64 apps from appstores is working, as the compytibility layer is overriden by my mount of the directory /system/vendor/lib64/arm64. Maybe this "sphal" namespace mentionend in the error I reported, is in some way incorrectly configured, so that it maps an x68 binding to the arm64 folder ?
It might be a dynamic mapping problem, as the static mappings of the libbase.so from my error msg look elsewise correct for me: So if anybody has an idea, why is vndksupport loading from "/system/lib64/arm64" instead from "/system/lib64/", this might be the answer for this general issue. But it is probably a bliss, or AG related bug, anyway.
|
@onlineapps-cloud I think this is not an scrcpy issue, anyway. The scrcpy tool only forwards an error message of the android system, that is not able load a viable encoder to capture your screen. scrcpy can't work without an encoder. You could verify this, by opening a root adb shell to your Bliss os and running Here is my first workaround for the Problem: I reasoned, that the "sphal" namespace of the vndk loader may be incorrectly configured in the android bliss (I use Bliss-v16.9.7-x86_64-OFFICIAL-foss-20241011.iso), at least for the com.android.media.swcodec subsystem. My bet is, that while AG (android generic project) or Bliss maintainers took some updated code from AOSP code base, they forgot to patch the linker namespace to reflect the X86 arch of Bliss in favor of android ARM64 default, when the dynamic linker detects X86 arch on bootup. After digging a bit in the vndk linker docu, this suspicion seems to hold. The Bliss video codec loader is configured in a single process HAL environment (sphal), meaning that the os provides it with an separated and isolated shared objects loader environment, (mainly) not shared with other programms. The general bliss/android NS configuration is done on boot time dynamically (maybe here
So, A simple fix seems to prepend the /system/lib64 path to the arm64 search path. I did it and created this little patch file here
Applying this patch with The best thing would be, if Bliss or AG system developers adapt the dynamic runtime linker configuration, to generate a correct namespace for the template file |
Looks like Bliss OS team has already reverted this change: BlissRoms-x86/android_system_linkerconfig@58c81f6#diff-27120287ce2b9781e8160a020c5045a1d26c3cbe87e799e9a7a654f1d2f0d816 |
Hm, true. I did not watch out for this. Looks like head of the x86 linker will skip the arm64 folders, so that system/lib64 comes to play.. sphal.cc |
Not hopefully, it's working. I already tested that. |
Great to read :) @rom1v I suggest to close this issue.. |
Sorry that was due to running Blissos in VMWARE. |
Environment
Describe the bug
A clear and concise description of what the bug is.
On errors, please provide the output of the console (and
adb logcat
if relevant).Please do not post screenshots of your terminal, just post the content as text instead.
The text was updated successfully, but these errors were encountered: