hyperion.ng
hyperion.ng copied to clipboard
hyperion-project
Raspberry Pi 4 with Libreelec v19 / Kodi Matrix, no grabber is working
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
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.
Hey, is there anything new on it? I tested it and it is still not working.
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.
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)
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.
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.
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.
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.
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
@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
@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?
Yeah just compile and run it. Hyperion starts a TCP socket that the image grabbers connect to, so no further configuration is necessary.
@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?
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?
Alpha 10 is coming, but Kodi 19 / LE 10 will not work. PR#1119 wont fix this.
So, just hope for the next release.
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!
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).
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!
@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. 😄
@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
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?
For your information: Libreelec 10 and Alpha-9 is working, no update to Alpha-10 is necessary.
You are right, I used the USB platform as grabber, which of course worked.
I also tried the Alpha-10 now, but it seems it doesn't work with the Framegrabber. @zyrill. Which version are you using and what is your configuration? Maybe you can share it to help us.
you are mistaken @tefracky . I do NOT have a working setup - it's simply not supported yet and I don't have the time to do it myself. I'm waiting until somebody has (or I have, but that might be a few years).
Sorry for the late response @zyrill. I think at the moment it looks like I will be quite busy for the next few months, as I'm busy writing up my PhD thesis, so I doubt I will have time. This is also a bit of a risky venture, as what I have gathered so far the Pi 4 hardware graphics chip does some things slightly differently. Because of this gaining memory access to the buffer may be more difficult. I will have access to a Pi 4 at the end of this month though, and can see if I can at least diagnose the issue.