moonlight-stream / moonlight-embedded

Gamestream client for embedded systems
https://github.com/moonlight-stream/moonlight-embedded/wiki
GNU General Public License v3.0
1.48k stars 323 forks source link

Libreelec Amlogic S905 : "Could not initialize SDL - SDL not built with video support" #506

Closed danykaufman closed 7 years ago

danykaufman commented 7 years ago

I have two amlogic boxes S805 and S905 both running kszaq libreelec krypton builds. On the S805 (latest 8.0.2a build, moonlight installed from kszaq repository) moonlight is working just fine. On the S905 (latest 8.0.2a build, moonlight installed from kszaq repository) I get the following error: "Could not initialize SDL - SDL not built with video support" (same issue also reported by others).

reported version: Moonlight Embedded 2.2.2 (SDL;EMBEDDED;PULSE;CEC;AML)

From kszaq's reply on the main forum there should not be any significant difference between the builds: "S805 and S905 builds have pretty much the same config and they follow official LE builds."

Can you suggest what may be the difference preventing moonlight from working on S905 ?

irtimmer commented 7 years ago

It looks like the S905 build can't get access to the video decoder. Try to run with the option -platform aml to force the correct video output instead of SDL and hopefully get some more meaningful error message.

shantigilbert commented 7 years ago

@irtimmer I also use the same version of LE as @danykaufman and I was able to compile a version that works fine with SDL, but it does not work with the -platform aml option, I have the libmoonlight-aml.so file in /usr/lib but it doesn't seem to make a difference.

Note that I have to do a manual installation of moonlight, so there is a big possibility I am missing something, maybe a configuration file that tells moonlight where to look for the platform libs?

irtimmer commented 7 years ago

Does not work is a very vague description of what's happening. Please check if _/sys/module/amvdec_h265/parameters/dynamic_buf_nummargin is at least 16 and the user running Moonlight has access to /dev/amvideo and /dev/amstream_hevc. Then provide output of Moonlight with -platform aml so the issue can be further debugged.

shantigilbert commented 7 years ago

you are right and I apologize for the vague error.

Here is the information:

cat /sys/module/amvdec_h265/parameters/dynamic_buf_num_margin  
16

The user in LE is always root, and I assume it has access to /dev/amvideo and /dev/amstream_hevc

ls /dev/amvideo -la
crw-------    1 root     root      264,   0 Jan  1  2015 /dev/amvideo
ls /dev/amstream_hevc  -la
crw-------    1 root     root      255,   8 Jan  1  2015 /dev/amstream_hevc

and here is the output

moonlight stream -debug -verbose -platform aml
Moonlight Embedded 2.4.0 (SDL;EMBEDDED;ALSA;PULSE;CEC;AML)
Searching for server...
Connect to 192.168.1.71...
NVIDIA GeForce GPU, GFE 3.6.0.74 (gs_03_70_22061309, 7.1.370.0)
Platform Unknown
Platform 'aml' not found

and a bit more info: if I run moonlight with no -platform I get the SDL version with this info:

moonlight stream -debug -verbose
Moonlight Embedded 2.4.0 (SDL;EMBEDDED;ALSA;PULSE;CEC;AML)
Searching for server...
Connect to 192.168.1.71...
NVIDIA GeForce GPU, GFE 3.6.0.74 (gs_03_70_22061309, 7.1.370.0)
Platform SDL2 (software decoding)
sh: setterm: not found
Stream 1280 x 720, 60 fps, 10000 kbps
Initializing platform...done
Resolving host name...done
Starting RTSP handshake...done
Initializing control stream...done
Initializing video stream...done
Initializing audio stream...done
Initializing input stream...done
Starting control stream...done
Starting video stream...done
Starting audio stream...done
Starting input stream...done
Returning RTP packet queued for too long
Received OOS audio data (expected 62256, but got 62257)
Decode failed - Invalid data found when processing input
Decode failed - Invalid data found when processing input
ls /usr/lib/libmoo* -la
-rw-r--r--    1 root     root          5704 Jun 14 19:49 /usr/lib/libmoonlight-aml.so
lrwxrwxrwx    1 root     root            24 Jun 14 19:49 /usr/lib/libmoonlight-common.so -> libmoonlight-common.so.1
lrwxrwxrwx    1 root     root            28 Jun 14 19:49 /usr/lib/libmoonlight-common.so.1 -> libmoonlight-common.so.2.4.0
-rw-r--r--    1 root     root         84636 Jun 14 19:49 /usr/lib/libmoonlight-common.so.2.4.0

Thanks for your help! And please let me know if there any other information I can provide.

irtimmer commented 7 years ago

That look strange as the only two reasons libmoonlight-aml.so is not loaded are it can't be found (or its dependency libamcodec.so) or it has no access to /dev/amvideo

As libmoonlight-common.so is already loaded it should be able to find libmoonlight-aml.so

shantigilbert commented 7 years ago

Yes it is very strange as it seems everything is in place for it to work.

Is there any other information I could provide to help with this?

danykaufman commented 7 years ago

I tried to add some basic debugging to src/platform.c

ifdef HAVE_AML

if (std || strcmp(name, "aml") == 0) { void *handle = dlopen("libmoonlight-aml.so", RTLD_NOW | RTLD_GLOBAL); printf(handle); if (handle != NULL && access("/dev/amvideo", F_OK) != -1) { printf("Returning AML\n"); return AML; } }

the moment i added "printf(handle);" aml platform got detected

moonlight --verbose stream 192.168.1.100 -platform aml -mapping /storage/.kodi/addons/script.moonlight/share/moonlight/mappings/xbox360.con f Moonlight Embedded 2.4.0 (SDL;EMBEDDED;ALSA;PULSE;CEC;AML) Connect to 192.168.1.100... NVIDIA GeForce GTX 970, GFE 3.6.0.74 (gs_03_70_22061309, 7.1.370.0) Returning AML Platform AMLogic VPU No mapping available for /dev/input/event1 No mapping available for /dev/input/event0 No mapping available for /dev/input/event2 Stream 1280 x 720, 60 fps, 10000 kbps Initializing platform...done Resolving host name...done Starting RTSP handshake...done Initializing control stream...done Initializing video stream...done Initializing audio stream...done Initializing input stream...done Starting control stream...done Starting video stream...done Starting audio stream...done Starting input stream...done

can you explain why it worked ?

edit: new issue now is that even after everything seems to start properly I am getting a black screen... Will continue to check.

nope... during execution, looking at /proc/$moonlight_pid/maps i see it is still not linking to libmoonlight-aml.so

danykaufman commented 7 years ago

Something is not building right... I went back to the original 2.2.2 package that comes from libreelec repository (moonlight-embedded-9301898) and added the following debug to platform.c:

ifdef HAVE_AML

if (std|| strcmp(name, "aml") == 0) { void *handle = dlopen("libmoonlight-aml.so", RTLD_NOW | RTLD_GLOBAL); printf("Handle error: %s\n", dlerror()); printf("Access /dev/amvideo: %i\n", access("/dev/amvideo", F_OK)); if (handle != NULL && access("/dev/amvideo", F_OK) != -1) return AML; }

Got this: LibreELEC:~/downloads # ./moonlight stream -p aml Moonlight Embedded 2.2.2 (SDL;VDPAU;EMBEDDED;PULSE;CEC;AML) Handle error: /usr/lib/libamcodec.so: undefined symbol: codec_sw_decoder_set_ratio Access /dev/amvideo: 0 Platform 'aml' not found

This happens even if I build the whole libreelec image from the same sources I compiled moonlight... If I copy libamcodec.so from S805, moonlight starts with amlogic platform but nothing gets displayed to the screen.. Guess i can't just copy a library like that..

Since it looks like a build issue I moved the question back to the libreelec forum. Will update..

@irtimmer maybe it is good to add dlerror() output to moonlight-embedded to allow more detailed error reporting. what do you think ?

dead commented 7 years ago

+1 dlerror. Try copying the libamcodec.so from build.LibreELEC- ... -devel/toolchain/aarch64-libreelec-linux-gnueabi/sysroot/usr/lib/

irtimmer commented 7 years ago

Main reason no dlerror is shown is because failing isn't necessarily a problem. It is used as a detection mechanism to check if the platform library is available and to otherwise check for the next possible platform. This allows a single build to be run on different platforms if they use the same architecture (unlike the s805 armv7 and s905 armv8 ;) ). In this case its clearly a build issue as the application is linked to another library version than actually available on the device and I don't think its very useful to add runtime errors/checks for build time issues. But maybe I will add a dlerror() message (only visible when adding verbose/debug argument) if their is high enough demand.