Raspberry Pi 4 with Libreelec v19 / Kodi Matrix, no grabber is working

[DaPeace]

I am using the latest Testbuild from Milhouse from here https://forum.kodi.tv/showthread.php?tid=343068
I cant get the framebuffer-grabber nor anything else to work. I installed the alpha7 where the webif is not working and then i moved backwards in the releases till the webif was working. I ended up with alpha4. When i start hyperion_dispmanx i get the following error:

[hyperion-dispmanx DISPMANXGRABBER] <INFO> Display opened with resolution: 4x1053483292 [hyperion-dispmanx FLATBUFCONNECTION] <INFO> Connecting to Hyperion: 127.0.0.1:19400 [hyperion-dispmanx DISPMANXGRABBER] <ERROR> Snapshot failed: -1

I found some conversations here how to solve that but that did not help. I tried the fb-grabber too but there i get the right resolution but only a black picture on fb0.

Is there any solution on RPI4 to get the grabber running? I need hyperion to bypass the led-data via udp to a wled-esp8266.

Regards, DaPeace

[Paulchen-Panther]

Is there any solution on RPI4 to get the grabber running? I need hyperion to bypass the led-data via udp to a wled-esp8266.

No. Not yet. We must implement V4l2/GBM to grab the screen on Kodi 19.
Alternative you can downgrade to a not milhouse build.
Or use another OS for Kodi.

[tefracky]

Hey,
is there anything new on it? I tested it and it is still not working.

[accessone67]

Wold also like to use this in kodi 19 with libreelec. any updates? :/

[MPowed]

Any word on this?

[KrX3D]

im also interested if there is some progress made on this

[tefracky]

Will #1119 fix this?

[sansillusion]

I would also like to be able to get my hyperion to work again. It's the only thing not working at all tight now and it bugs me. My LEDs turn off when I play something and I dont want to disable hyperion has it serves as a reminder to check back on it once in a while in hope that someone had a breakthrough.

[rudihorn]

I've been spending a little time experimenting with the DRM apis to perform screen grabbing at https://github.com/rudihorn/drm-vc4-grabber with some progress. I have been able to show that it is definitely possible to write a grabber this way, but at the same time my knowledge of the Linux rendering system is limited and I am not entirely sure how to correctly take the image in its in-memory format and convert it into the true image (let alone how to ensure that the performance is sufficient, though the in memory reading bit should be reasonable given the shared memory architecture). I assume V4L2 may be helpful in doing the rest.

Unfortunately I won't have a huge amount of time to work on this, so would be happy if anyone wants to help out on this.

Also this seems to be related to #954.

(Also apologies if the project is a bit hacky, given I'm currently still just trying to figure things out. If there are any questions just ask)

[Paulchen-Panther]

Hi @rudihorn
I will gladly have a look at your project. I have also worked a little with the DRM/GBM API but failed to convert the memory image. Maybe I am missing a crucial snippet that you have integrated in your project. I will let you know. Thanks for your time and work.

[rudihorn]

No worries. I suspect the last thing missing from my code was some de-interlacing for each 32x32 pixel square. The framebuffer uses a modifier with value 504403158265495553 (hex 0x700 0000 0000 0001) which seems to be driver specific. I have not quite yet found a reference to this.

[rudihorn]

So my grabber now at least copies a correct image. I still need to see if the performance is efficient enough though, and there is certainly some room for optimization. It might also be worth adding some domain specific code for downsizing the image. It should be possible to write some pretty efficient code for reducing the resolution by a factor of 4.

Edit: Rewrote it so it should be a little bit more efficient. Still not sure this is fast enough though.

[rudihorn]

I've done a little more work and the screen grabber can now connect to hyperion and upload the image. This seems to work, but revealed that video image buffers are uploaded into a different framebuffer. The current setup is that there is the CRTC with a framebuffer which is used for video, and then an extra plane containing the XBMC ui.

This is actually quite nice though, because when video is playing UI elements are not captured. Unfortunately this also means that the video buffer is in a different (and potentially many) different pixel formats. As it is not rendered though, it does not use the tiling format by the VC4. I've implemented YUV420, but I'm not sure how many other must implement formats there are. It probably suits most of my purposes though. For YUV420 it is possible to implement an efficient half resolution grabber which is nice.

@Paulchen-Panther I'm not entirely sure I understand the current concept of how registration is supposed to work, but it seems I need to repeatedly resend the registration message.

[chcore]

Thanks for your efforts rudihorn. You mentioned it not capturing UI elements while video is playing, which is indeed nice. But does this mean that things will not work when running other applications which don't play video? e.g Retroarch

[rudihorn]

@chcore best to just try it out. When it doesn't detect a video it does fall back to the ui framebuffer, so when displaying images for example it still works. If retroarch renders in some odd way more work may be necessary

[Chaphasilor]

@rudihorn talking about trying it out, which steps would be needed for that? From your readme I got that I have to compile your rust code to the platform-specific binary, and then it seems like I have to run that in the background and it "connects to hyperion"? Does that mean hyperion will auto-detect the new grabber or do I have to change some additional settings in hyperion?

[rudihorn]

Yeah just compile and run it. Hyperion starts a TCP socket that the image grabbers connect to, so no further configuration is necessary.

[chcore]

@chcore best to just try it out. When it doesn't detect a video it does fall back to the ui framebuffer, so when displaying images for example it still works. If retroarch renders in some odd way more work may be necessary

That's good to hear. Will test it tonight.

What are the chances of this working on x86 as well?

[emc02]

Is there any progress in libreelec 10 for internal frame grabber working?
Will it ever work? Are the devs just waiting for final libreelec version?

[Johnny1982fd]

Alpha 10 is coming, but Kodi 19 / LE 10 will not work.
PR#1119 wont fix this.

So, just hope for the next release.

[zyrill]

I just updated LibreELEC to 10 thinking PR 1119 would get things rolling again with my rpi4 so thanks for the infos, everybody... Now I at least know I shouldn't have. @rudihorn do I understand your post correctly that there's a workaround you built with that grabber of yours? I'm a bit lost as I don't understand the peculiars of the graphics system so I would appreciate some more guidance, if anybody had some time... Thanks!

[tefracky]

I just updated LibreELEC to 10 thinking PR 1119 would get things rolling again with my rpi4 so thanks for the infos, everybody... Now I at least know I shouldn't have. @rudihorn do I understand your post correctly that there's a workaround you built with that grabber of yours? I'm a bit lost as I don't understand the peculiars of the graphics system so I would appreciate some more guidance, if anybody had some time... Thanks!

Did I understand correctly, that the latest Libreelec nightly and Hyperion now working together? Did you used the Alpha-10 or did you compile by your own? Maybe you can share your compiled fine to make things easier for other people (me :D).

[zyrill]

I used the latest available releases. I don't see any commits after the alpha-10 that would change anything materially, so I don't think compiling a "nightly" from master helps. I also don't think that using a libreELEC nightly would help, as LE isn't broken. It's simply that hyperion-ng is lacking support for the current LE version. If somebody knows better please chime in. Thanks!

[Paulchen-Panther]

@zyrill @tefracky
We are still in the process of implementing the DRM grabber. Since the number of active devs (only 2) is limited, our time is also limited. You are all welcome to help. 😄

[rudihorn]

@zyrill the project can already be used for DRM capture on a raspi 2b+ and maybe a raspberry pi 3. I haven't been able to make it work on a raspberry pi 4 because I don't have access to one. Feel free to use that project as a starting point for getting it to work on a raspberry pi 4 though

[zyrill]

I'm well aware of how this usually works, which is why I formulated my posts a bit defensively. ;) I can't help developing presently, sadly. What I can do is sponsor an rpi4 for active devs, would that help, @rudihorn?

[tefracky]

For your information: Libreelec 10 and Alpha-9 is working, no update to Alpha-10 is necessary.

[MathijsG]

I have the same issue with a Raspberry Pi 3 with local non-DRM video's as well.

When I do a screen grab from the Hyperion webinterface I only get this:

No further interface of Kodi shows up.

On LibreElec 9.X it was all fine and dandy.

[Morphy99]

I can confirm that, after updating to LE 10.0.2, hyperion is working on a Pi Tv HAT via tvheadend, and it is working with BBC iPlayer and LE menus. Nothing during Netflix (black)

How are you finding SD DVB streams? The HD Channels appear to work OK but this is what the grabber see's with SD channels (mpeg2 704x576).

EDIT: Actually, I'm also getting a green band on HD channels across the very top:

[alexd321]

I can confirm that, after updating to LE 10.0.2, hyperion is working on a Pi Tv HAT via tvheadend, and it is working with BBC iPlayer and LE menus. Nothing during Netflix (black)

How are you finding SD DVB streams? The HD Channels appear to work OK but this is what the grabber see's with SD channels (mpeg2 704x576).

EDIT: Actually, I'm also getting a green band on HD channels across the very top:

Same here. Have had for a while on DVB-T. Have avoided too green a bar on top by skipping a few rows

[Morphy99]

@alexd321 I've been playing around with the transcoding settings in TVH and I've managed to find some settings which transcode the MPEG2 SD streams to a h264 resolution which hyperion likes. Means that all channels seem to play OK with hyperion at last!

[alexd321]

@alexd321 I've been playing around with the transcoding settings in TVH and I've managed to find some settings which transcode the MPEG2 SD streams to a h264 resolution which hyperion likes. Means that all channels seem to play OK with hyperion at last!

@Morphy99 I get no feed at all after specifying this stream in TVH client
I think expert mode might have made things more complicated:

Did I miss something?

[Morphy99]

Mines on expert too. I think you're on 4.2. I had to update TVH to the latest docker instead of le add-on. I think it's 4.3. Video codec needs to be set to h264 not mpeg2 as well. Mpeg2 is the only the source. I also had to set the height larger than 1080 for some reason. I doubled the existing 576.

[emc02]

Really no solution here... 🙁

[miloit]

Anyone working on this?

[dapuzz]

Have you tried the 2.0.13 beta here? #983 (comment)
I have again the DispmanX working in Kodi 19

[Salokyn]

Hello !
Any news about this issue. I've just installed Hyperion 2.0.15 and get only the "Framebuffer" grabber.

[louisnichols]

Hi all!

I am complete noob to the technicalities of all this and I may be talking complete rubbish here, but could it be that what is described at the link below might be helpful for the Hyperion use case, too?
It's from OBS, but seems to solve a problem somewhat similar, and to my untrained ear it sounds like the underlying technologies are the same.

https://obsproject.com/forum/threads/experimental-zero-copy-screen-capture-on-linux.101262/

[sachinss123]

Confirming that the file linked above works on LibreElec 11.0.3 with Kodi 20 Nexus. Need to add a 30 sec delay in the systemd service file to boot properly.

[top4ek]

Can confirm working beta DRM grabber on LE 11.0.3 and OSMC on RPi3 but with memory leak problem.
2.0.15 — doesn't work, only framebuffer option. As I see, no one works ATM on that problem.

[louisnichols]

@sachinss123 Is that on an RPi? I tried it and I only get capture of the GUI, not videos.

[sachinss123]

Yes it is on Rpi 4. Have you selected the DRM grabber in Hyperion config? Also try different kinds of video types. In an earlier Hyperion build it couldn't capture the correct colours for H265 videos. Maybe something similar is happening at your end?

…

On Sun, 24 Sept, 2023, 19:27 louisnichols, ***@***.***> wrote: @sachinss123 <https://github.com/sachinss123> Is that on an RPi? I tried it and I only get capture of the GUI, not videos. — Reply to this email directly, view it on GitHub <#983 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANHXPH55IFTIWHR2TIUPZ6DX4A33XANCNFSM4QPCWLUQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[rudihorn]

So I finally got a Raspberry Pi 4 and have found a fix to get my project to work based on https://github.com/w23/obs-kmsgrab. It seems that drm_prime_fd_to_handle is the way to open a framebuffer and that gets rid of some platform specific code I had. I'll try patching things up the next few days so that a binary is published. I also found a few other issues in my code that should fix other issues I had. That way it should be possible to use this with the latest hyperion-ng. For more info see rudihorn/drm-vc4-grabber#6.

[rudihorn]

Released as https://github.com/rudihorn/drm-vc4-grabber/releases/tag/v0.1.0, any feedback is welcome.

[sachinss123]

Thanks! Can you guide how to install this? I copied the file to /hyperion/bin, and restarted hyperiond but I don't think anything changed.

Edit: Got it working. You have to run the grabber in the background with Hyperion running.

Feedback: This works much better than the previous DRM grabber on Kodi20, RPI4. It even captures those videos where the older grabber just showed diagonal lines.
However, is there a setting to change the decimation of the image? I saw the CPU usage shoot up while using this vs. the older DRM grabber. CPU was ~30% compared to ~10% with the older grabber. The image in Hyperion's Live Video feed is a lot clearer which makes me assume that the decimation should be increased.

[BUBUsnet]

Released as https://github.com/rudihorn/drm-vc4-grabber/releases/tag/v0.1.0, any feedback is welcome.

Thanks, get this error on rpi4 (Raspbian 11) on self compiled and precompiled bin:
thread` 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Sys(EOPNOTSUPP)', src/main.rs:173:61

[top4ek]

RPi3 latest OSMC.

thread 'main' panicked at 'called Result::unwrap() on an Err value: Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }', src/main.rs:185:53

Flatbuffers MUST be enabled in Hyperion configuration.

App itself must be run as root.
Looks wonderfull, continue testing. Can grabber's resolution to be adjusted like with default screen grabber "Picture decimation" parameter?

[sheggy012]

Released as https://github.com/rudihorn/drm-vc4-grabber/releases/tag/v0.1.0, any feedback is welcome.

Works perfectly so far. Thank you.

[MPowed]

works with pi4 and 1080p media. 4k media has issues. If player PRIME render method is "direct to plane" then the flatbuffers server closes and hyperion does not work. if I change that to "EGL" then my experience is 50/50, some vidoes do not play and some do with hyperion working

[alexd321]

Thanks! Can you guide how to install this? I copied the file to /hyperion/bin, and restarted hyperiond but I don't think anything changed.

Edit: Got it working. You have to run the grabber in the background with Hyperion running.

Feedback: This works much better than the previous DRM grabber on Kodi20, RPI4. It even captures those videos where the older grabber just showed diagonal lines.
However, is there a setting to change the decimation of the image? I saw the CPU usage shoot up while using this vs. the older DRM grabber. CPU was ~30% compared to ~10% with the older grabber. The image in Hyperion's Live Video feed is a lot clearer which makes me assume that the decimation should be increased.

Instructions are here I believe
https://github.com/rudihorn/drm-vc4-grabber

[gnilebein]

Should drm-vc4-grabber also run on a Raspberry Pi 3 under Libreelec?

[Damien6neimad]

Hello, I use OSMC with hyperion ng on a pi 4 and I can follow the instructions up to
cargo build --release --target armv7-unknown-linux-gnueabihf
where I get the
error: failed to get 'rustc_error_codes' as a dependency of package 'error_index_generator v0.0.0 (...)'
I try to reinstall rustup and cargo again but no improvement.
May you tell me what to do?

[noelpferd]

Released as https://github.com/rudihorn/drm-vc4-grabber/releases/tag/v0.1.0, any feedback is welcome.

Thanks, get this error on rpi4 (Raspbian 11) on self compiled and precompiled bin: thread` 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Sys(EOPNOTSUPP)', src/main.rs:173:61

Got same problem, just try /dev/dri/card1 instead of default card0 device. "./drm-vc4-grabber -d /dev/dri/card1". I think it depends which hdmi output you are using (raspberry pi 4 has 2 hdmi outputs)

[Lord-Grey]

Suggest you check with the owner of the repository, as this is not part of the project here.