Open veldenb opened 1 year ago
It should work already. It looks like the LibreELEC GBM build is basically the same display stack that the Pi and other embedded devices already run where they just talk to KMS/DRM directly. Both DrmRenderer and EGLRenderer support this.
Try running Moonlight with the MESA_DEBUG=1
environment variable set or messing with other Mesa environment variables to see if you can get it to print out the underlying error.
Does it stream in HDR? HDR will use DrmRenderer directly, rather than EGLRenderer, so it may circumvent the issue.
I think it's a OS/kernel related issue. I tried playing video's in Kodi but that also doesn't work. A snippet from the Kodi log:
2023-03-19 12:15:13.636 T:63025 info <general>: VideoPlayer::OpenFile: /storage/videos/TearsOfSteel_720p_h265.mkv
2023-03-19 12:15:13.637 T:63118 info <general>: Creating InputStream
2023-03-19 12:15:13.639 T:63118 info <general>: Creating Demuxer
2023-03-19 12:15:13.641 T:63118 info <general>: Opening stream: 0 source: 256
2023-03-19 12:15:13.641 T:63118 info <general>: Creating video codec with codec id: 173
2023-03-19 12:15:13.641 T:63118 info <general>: CDVDVideoCodecDRMPRIME::Open - using decoder HEVC (High Efficiency Video Coding)
2023-03-19 12:15:13.642 T:63118 info <general>: Creating video thread
2023-03-19 12:15:13.642 T:63136 info <general>: running thread: video_thread
2023-03-19 12:15:13.642 T:63118 info <general>: Opening stream: 1 source: 256
2023-03-19 12:15:13.642 T:63118 info <general>: Finding audio codec for: 86018
2023-03-19 12:15:13.642 T:63118 info <general>: CDVDAudioCodecFFmpeg::Open() Successful opened audio decoder aac
2023-03-19 12:15:13.642 T:63118 info <general>: Creating audio thread
2023-03-19 12:15:13.642 T:63137 info <general>: running thread: CVideoPlayerAudio::Process()
2023-03-19 12:15:13.653 T:63137 info <general>: Creating audio stream (codec id: 86018, channels: 6, sample rate: 48000, no pass-through)
2023-03-19 12:15:13.656 T:63062 info <general>: CActiveAESink::OpenSink - initialize sink
2023-03-19 12:15:13.748 T:63025 error <general>: CEGLImage::CreateImage - failed to import buffer into EGL image: 0x3003
2023-03-19 12:15:13.848 T:63062 info <general>: Skipped 3 duplicate messages..
2023-03-19 12:15:13.848 T:63062 info <general>: CAESinkALSA::Initialize - Attempting to open device "@:CARD=Generic_1,DEV=0"
2023-03-19 12:15:13.852 T:63062 info <general>: CAESinkALSA::Initialize - Opened device "sysdefault:CARD=Generic_1"
2023-03-19 12:15:13.852 T:63062 info <general>: CAESinkALSA::InitializeHW - Your hardware does not support AE_FMT_FLOAT, trying other formats
2023-03-19 12:15:13.852 T:63062 info <general>: CAESinkALSA::InitializeHW - Using data format AE_FMT_S32NE
2023-03-19 12:15:13.859 T:63025 error <general>: CEGLImage::CreateImage - failed to import buffer into EGL image: 0x3003
2023-03-19 12:15:13.876 T:63025 info <general>: Loading skin file: VideoFullScreen.xml, load type: KEEP_IN_MEMORY
2023-03-19 12:15:13.877 T:63025 error <general>: CEGLImage::CreateImage - failed to import buffer into EGL image: 0x3003
I can hear the sound of the video playing but it's not rendered, no overlay with video is created. This is the same for H.264 and H.265.
Setting the MESA-vars doesn't produce more usable information.
So I'll close this issue and consider it an LibreELEC 11 issue for now.
Hi,
I'm reopening this issue, LibreELEC 12 test-builds are now available and hardware accelerated HEVC now works on kodi. In the Kodi UI it show up as "ff-hecv-vaapi (HW)". Part of the kodi.log:
Hardware acceleration is not detected by moonlight, it looks like something is not going well while initialising VAAPI:
Details from VAAPI:
It would be nice to see if this can work and what it does to the latency and if HDR can be used on Linux this way on x86 hardware (LibreELEC supports it in some cases: https://wiki.libreelec.tv/hardware/intel-x86-64-generic).
The relevant code is here: https://github.com/moonlight-stream/moonlight-qt/blob/413993ab6fc97bbd3650d06ccb1a54a915f58fee/app/streaming/video/ffmpeg-renderers/vaapi.cpp#L123-L167
13 is SDL_SYSWM_KMSDRM
, so that means the GBM rendering path is not compiled into your build of Moonlight.
I'm pretty sure it's caused by building Moonlight with libva-drm
or libdrm
missing. There were probably some indications in your moonlight-qt build log that say what's going wrong. In your build logs, you should see:
VAAPI DRM support enabled
DRM renderer selected
If you don't see both of those messages during your build or you see compiler warnings about missing or mismatched DRM libraries, that's the issue. If you can't figure it out, attach the full Moonlight build log and I'll take a look.
I think the issue was the bug that I fixed in https://github.com/moonlight-stream/moonlight-qt/commit/ea8bccd508a31bd883f16b0dec15c8ca4a72700d. The fix is included in the v5.0.1 release.
Let me know if you still have problems with this after that fix.
Time to report back :)
System details:
This is a laptop and using moonlight with direct KMS/DRM runs pretty well if it runs. It tested a few scenario's:
Log files: Error that shows up when stuff gets borked: moonlight-qt-AMD-Error_No_connected_displays_found.log Direct connect with HDR: moonlight-qt-AMD-HDR-Error_0_drmModeSetPlane_failed_22.log Direct connect with SDR and switch to HDR: moonlight-qt-AMD-SDR-switch-to-HDR.log
This is an older 6th gen Intel NUC without HDR support, two scenario's I've tested:
SDL Error (0): EGLRenderer: Can't create shader: 0
. I tried different configurations but got none to work.Log files: Hardware accelerated decoder: moonlight-qt-Intel-Error_EGLRenderer_Cant_create_shader_0.log Software decoder: moonlight-qt-Intel-Force_software_decoder_1440p.log
If EGLFS-support could be included in the Linux AppImage it would be easier to use moonlight-qt on LibreELEC 11/12. I'm not sure if the errors I encountered are related to the drivers or moonlight-qt, but I do see potential for running moonlight-qt directly on KMS/DRM. Because very little software is needed all hardware can be dedicated to running the stream and there are almost no background processes that can interfere.
It seems that choosing a primary display using QT_QPA_EGLFS_KMS_CONFIG
mitigates the SDL Error (0): No connected displays found!
error when using the following content:
{
"outputs": [
{
"name": "HDMI1",
"primary": true,
"mode": "3440x1440"
}
]
}
But I still experience lock-ups in some situations when the stream ends. I can see a terminal with moonlight-qt logging normal output without errors, but my inputs are ignored, the only input that is registered are the ALT+SysRq
keystrokes.
@veldenb Hey, I wanted to ask what's the current situation.
Currently I can't use the Moonlight on non-legacy LibreElec builds at all (using your plugin.program.moonlight-qt
addon).
In Legacy
image everything works flawlessly, but it does not support HDR so I can't use Kodi to watch HDR files.
Software: LibreElec 12.0 Nightly latest Hardware: Intel Core i3-N305 GPU
Starting input stream establishment...
, though I can close session using Ctrl-Shift-Alt-Q and return to the main Moonlight menu. Last lines in the logs are always:
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] nal_unit_type: 19(IDR_W_RADL), nuh_layer_id: 0, temporal_id: 0
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] Decoding VPS
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] Main profile bitstream
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] Decoding SPS
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] Main profile bitstream
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] Decoding VUI
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] Decoding PPS
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] Format yuv420p chosen by get_format().
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] Output frame with POC 0.
00:00:28 - FFmpeg: [hevc @ 0x557ed60fa940] Decoded frame with POC 0.
@blind-oracle currently EGLFS-support is not included in the Moonlight-qt x86_64 AppImage build. So you'll need to build moonlight-qt yourself to enable this. Maybe @cgutman can tell if there are future plans that to support this or not.
@veldenb Thanks for the response! Is switching to build using generic_git
arch in your Addon's build script enough for this or I need to specify the ./configure
arguments to enable EGLFS additionally?
@blind-oracle if the generic_git
build works (it's maintained less because it's for testing and debugging purposes only) it should indeed build with EGLFS support without modification necessary.
@veldenb Thanks a lot! It indeed still works, though takes some 10min to build.
The result is, for sure, an improvement:
What's wrong with hardware decoding I couldn't figure out, the same SDL Error (0): EGLRenderer: Can't create shader: 0
error and black screen as you had.
00:00:31 - SDL Info (0): VAAPI driver supports exporting DRM PRIME surface handles with composed layers
00:00:31 - SDL Info (0): Color buffer is: R8G8B8A8
00:00:31 - SDL Info (0): VAAPI driver supports exporting DRM PRIME surface handles with composed layers
00:00:31 - SDL Info (0): Exporting composed layers with format and modifier: 3231564e 0100000000000002
00:00:31 - SDL Info (0): EGL passed preflight checks. Using EGL for GL context creation.
00:00:31 - SDL Info (0): Frame pacing disabled: target 60 Hz with 60 FPS stream
00:00:31 - SDL Info (0): Using VAAPI accelerated renderer on KMSDRM
00:00:31 - SDL Info (0): FFmpeg-based video decoder chosen
00:00:31 - SDL Info (0): IDR frame request sent
00:00:31 - SDL Info (0): Requesting IDR frame on behalf of DR
00:00:31 - SDL Info (0): IDR frame request sent
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] nal_unit_type: 32(VPS), nuh_layer_id: 0, temporal_id: 0
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] nal_unit_type: 33(SPS), nuh_layer_id: 0, temporal_id: 0
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] nal_unit_type: 34(PPS), nuh_layer_id: 0, temporal_id: 0
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] nal_unit_type: 19(IDR_W_RADL), nuh_layer_id: 0, temporal_id: 0
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Decoding VPS
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Main profile bitstream
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Decoding SPS
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Main profile bitstream
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Decoding VUI
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Decoding PPS
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Format vaapi chosen by get_format().
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Format vaapi requires hwaccel initialisation.
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Considering format 0x3231564e -> nv12.
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Picked nv12 (0x3231564e) as best match for yuv420p.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Direct mapping possible.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x1.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x2.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x3.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x4.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x5.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x6.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x7.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x8.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x9.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0xa.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0xb.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0xc.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0xd.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0xe.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0xf.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x10.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x11.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x12.
00:00:31 - FFmpeg: [AVHWFramesContext @ 0x7f7c90d03f40] Created surface 0x13.
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Decode context initialised: 0x13/0x10000000.
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Output frame with POC 0.
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Param buffer (type 0, 604 bytes) is 0.
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Slice 0 param buffer (264 bytes) is 0x1.
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Slice 0 data buffer (123734 bytes) is 0x2.
00:00:31 - FFmpeg: [hevc @ 0x55b2b71a3740] Decode to surface 0x13.
00:00:31 - SDL Info (0): EGLRenderer: EGLImage pixel format: 179
00:00:31 - SDL Error (0): EGLRenderer: Can't create shader: 0
00:00:31 - SDL Warn (0): Recreating renderer by internal request: 8192
00:00:31 - SDL Info (0): EGLRenderer: EGLImage pixel format: 179
00:00:31 - SDL Error (0): EGLRenderer: Can't create shader: 0
00:00:31 - SDL Info (0): V-sync enabled
00:00:31 - SDL Info (0): Opening render node for VAAPI: /dev/dri/renderD128
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_20
libva info: va_openDriver() returns 0
00:00:31 - SDL Info (0): Initialized VAAPI 1.20
00:00:31 - SDL Info (0): Driver: Intel iHD driver for Intel(R) Gen Graphics - 24.1.4 (f3b540d)
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x41524742 -> bgra.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x42475241 -> argb.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x41424752 -> rgba.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x52474241 -> abgr.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x58524742 -> bgr0.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x42475258 -> 0rgb.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x58424752 -> rgb0.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x52474258 -> 0bgr.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x30335241 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x30334241 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x30335258 -> x2rgb10le.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x30334258 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x36314752 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x56555941 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x56555958 -> vuyx.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x30303859 -> gray.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x3231564e -> nv12.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x3132564e -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x32595559 -> yuyv422.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x59565955 -> uyvy422.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x32315659 -> yuv420p.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x30323449 -> yuv420p.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x50313134 -> yuv411p.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x48323234 -> yuv422p.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x56323234 -> yuv440p.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x50343434 -> yuv444p.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x33434d49 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x30313050 -> p010le.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x32313050 -> p012le.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x36313050 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x30313259 -> y210le.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x32313259 -> y212le.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x36313259 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x30313459 -> xv30le.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x32313459 -> xv36le.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x36313459 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x50424752 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Format 0x50524742 -> unknown.
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] VAAPI driver: Intel iHD driver for Intel(R) Gen Graphics - 24.1.4 (f3b540d).
00:00:31 - FFmpeg: [AVHWDeviceContext @ 0x55b2b7bfca40] Driver not found in known nonstandard list, using standard behaviour.
I also couldn't get hardware decoding to work on Intel hardware. I'm note sure if it's because the current state of KMSDRM or incompatibilities with SDL. I had more success with AMD hardware, so I think it's because of KMSDRM.
Hi,
I'm not sure if this should be considered a bug or a feature request. LibreELEC currently supplies two x86_64 builds:
Moonlight-qt runs fine on the Xorg legacy-build, but struggles on the GBM build. I tried running moonlight-qt the GBM-build with mixed results:
SDL Error (0): EGLRenderer: Can't create shader: 0
.Full logs of both:
Is rendering with GBM on x86_64 supposed to be working or may it become usable in the near future?
For more details on LibreELEC GBM: https://libreelec.tv/2023/03/06/libreelec-nexus-11-0-0/