-
Notifications
You must be signed in to change notification settings - Fork 554
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
[RK] SDL Error (0): Unable to open decoder for format: 1 #509
Comments
You'll need to build FFmpeg with RKMPP enabled, and Moonlight will use that and render using DRM. For the latency to not be horrible, you'll probably want this patch too - cgutman/FFmpeg@3371567 |
The Rockchip Mpp is the vendor blob solution (https://github.com/rockchip-linux/mpp) for media procession iirc but LE uses the mainline kernel + staging patches https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/linux/default which relies on the v4l2 stateless codec interface. One of the Kodi devs had a quick look at your code and told me |
What is the custom FFmpeg decoder called? do you have a link to the FFmpeg patch set? |
These APIs and decoders are still wip & in staging but once they are complete mainline kernel will use them afaik right now some 5.11.y patches were backported but basically it works with Kodi. The v4l2 stateless decoder: Rockhip project & patches: FFmpeg: |
ok, give it a shot with this latest commit ed3a544 |
nice -> I'll make some tests then! |
Actually I think I may have done that wrong. I think the v4l2requests support is an HWAccel not a codec. Can you attach the output of |
According to the package file it is indeed a HWAccel https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/ffmpeg/package.mk#L31-L43 |
Build config for ffmpeg
|
OK, try now - 5417843 |
Still no working decoder but I guess a step in the right direction:
I'm updating to the latest upstreamed kernel version/patches and check again if there is some fix too, will report back. |
latest kernel 5.10.11 + updated DRM patches:
The video decoder works as you see in Kodi Ignore the black picture, it's a Kodi dev bug afaik, if you watch tv there is a proper video output. I've also tried the latest build with a Vim3 (Amlogic A311D) which reports working decoders:
But the reason is according to a Kodi dev |
I got my RK3288-based TinkerBoard out of storage and flashed Armbian Focal on it, so I'd be able to actually test this thing. I fixed the I wasn't able to coerce I also plumbed EGLImage support with ac947d3 which lets us use the EGLRenderer that supports running with X or Wayland and renders in a window. With that I did manage to actually render, though the output is only a green screen (but the stats overlay does render fine on top of it). The cause of the green screen appears to be a Linux kernel bug or something as each call to
I'm not sure if this is supposed to work on RK3288, but you should give it a shot on your RK3399 and see if it works better for you. |
Thanks for the heads up 👍🏻 well I guess armbians kernel is not "up-to-date" |
Looks like some progress 😃 -> I've bumped SDL2 to spurious/SDL-mirror@b7ab7a4 as your latest version depends on recent patches. Now moonlight doesn't nag anymore about a missing decoder and I can connect & start a stream but I end up with "starting input stream establishment...." All the gamestream host recognizes my inputs & I can hear the sound but still no video output.
|
Nice, I was going to ask you to pull in that SDL change if you wanted to run without X. The remaining problem is that DRM master issue between Qt and SDL. For now, you can try launching moonlight with: That will have Qt use the LinuxFB backend, allowing SDL to become the DRM master and allowing rendering to work properly. With LinuxFB, it does render for me (though with the green screen issue detailed before). |
My Qt5 package is only build with EGLFS and the DRM stuff but LinuxFB is disabled. The latest SDL2 version also breaks Emulationstation rendering 👀 |
On my dev machine, I use Fedora 33's Qt packages which are 5.15.2. On my Tinkerboard with Armbian Focal, I'm using the Focal Qt packages which are 5.12.8. Moonlight should run fine with anything between 5.9 and 5.15, though some features are degraded with versions prior to 5.11. You should report that SDL Emulationstation bug on https://bugzilla.libsdl.org/ to ensure SDL 2.0.16 doesn't ship with it. |
It's SDL version 2.0.15-dev so I guess they iron out those quirks until next release although it could be linked to mesa-git etc. etc. Basically it's all somewhat bleeding edge mainline staging driver stuff 🙈 you found a solution for the issue between Qt & SDL? |
I'm going to try destroying my Qt window before streaming to see if that lets SDL gain DRM master. I was able to confirm that my code that imports DRM PRIME buffers to EGLImages is correct by using the LibreELEC v4l2-drmprime patch which allows the v4l2m2m codecs to output DRM PRIME buffers. It rendered correctly (though slowly) on my Raspberry Pi 4 using h264_v4l2m2m. |
Cool! Sounds like steady progress! 🥇 I guess SDL2-dev is still a dependency for DRM PRIME? Because I guess I have to start look for the "garbage" commit which broke emulationstation then ^^ |
The Qt/SDL DRM master coexistence was a big headache, but I finally got it working. Please try again with a88a3c9 |
Well that looks like a rather complex addition but I'm eager to test it soon 👍🎊 |
@SupervisedThinking any luck with the latest code? |
@cgutman LE will be bumped to v10.0 in the next days & a beta releases will start. IIRC some updated RK video decoder patches will be released & I'm rebuilding currently and will test it then 👍🏻 |
looks like you did it 🥇 I've made a clean rebuild and tried this sdl2 commit
|
Wow nice! Latency looks low too. I wish the V4L2+EGL path worked that well on my Raspberry Pi or (worked at all) on my RK3288 TinkerBoard. |
Well I have no clue if the Rk3288 & the RK3399 share the same video decoder unit or if the mainlining process is at the same stage.
https://libreelec.tv/2021/02/upcoming-changes/ I have no clue which distribution you use but LE has a lot of (staging) patches tailored for ffmpeg & linux: https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/ffmpeg So I guess this just needs to mature a bit & your Tinkerboard will benefit too. The latency should be low since the desktop is just 5m away & connected by Gbit Ethernet ^^ beside that the RK3399 vpu should be able to decode 4k@60Hz or something so no big deal to handle h.264 1080p@60Hz anyway it's quite cool that this is up and running because just connecting a controller in the kitchen, guest room etc. and play a bit is always nice 🥇 |
FYI: these are the logs of my regularly used HTPC with i3-6100 CPU
RK3399
Full log:
|
Describe the bug
I'm building moonlight-qt for RK3399 devices based on latest LibreELEC master, my package https://github.com/SupervisedThinking/LibreELEC-RR/blob/master-rr/packages/supervisedthinking/emulation/streaming/moonlight-qt/package.mk
Once you start moonlight it does not find a working decoder:
I've chatted with one of a mainatiner and he gave me the hint that:
h264_v4l2m2m is stateful codec interface, rockchip needs stateless codec interface, e.g. request api
https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-stateless-decoder.html
Anyway I'm not sure if it's a ffmpeg bug, rk mainline kernel bug or moonlight. But Kodi, Emulationstation & Pegasus FE can play videos by using either ffmpeg or gstreamer.
Moonlight Logs (please attach)
https://pastebin.com/E5bT2vcG
The text was updated successfully, but these errors were encountered: