Migrate DRM Grabber to HyperHDR?

[Johnny1982fd]

Hi,

much people asking for DRM Grabber.

Here is a solution.

https://github.com/rudihorn/drm-vc4-grabber

Can we migrate this to HyperHDR?

[awawa-dev]

Hi
Have you tested it? Are there any major restrictions such as:

• only one tiling is supported, how does this affect video capture capabilities if for some video codec the video player decides to use a different format/acceleration layer.
• does it have any impact on video playback experience? e.g. locking DRM resource may lead to freezing/skipping frames
• how high is the CPU load and can it cause playback problems?
• what happens if the HDR stream is turned on in the player? does it work at all or does it require color LUT correction?

If you have the answer to these questions, you can submit a new PR as new feature request in the issues section to implement this.

[NashJames]

Hey @awawa-dev!

I'm making plans to potentially implement this project in a few months. I similarly just stumbled upon the original issue created on hyperion where the dev behind the DRM grabber advertised it (there's some interesting discussion on there if you haven't had a read). I found this discussion by searching to see if it had been mentioned.

If I'm understanding this right, this could completely remove the need for a HDMI grabber and save a lot of additional money on buying a streaming device (e.g. Apple TV, FireTV, Nvidia Shield Pro, etc.)? Personally, this sounds like an amazing opportunity as the only two existing external devices I'm aware of to support Dolby Atmos are a Nvidia Shield Pro (£190) and a RaspberryPi. It would also likely simplify the project with fewer devices, fewer cables and lower power consumption?

I'd love to help this become a reality but don't think I've got the required knowledge to get the answers you need. I also haven't setup HyperHDR/hyperion before and am not yet in a position to. Though, it does seem the developer is eager to help:

I don't think this will get merged directly into hyperion-ng, however I'm happy for anyone from their team to take or redistribute parts of this project as they like. Given it currently works standalone, I think it would probably be easiest to just bundle the compiled version of this into their project, and maybe allow it to be selected as a grabber. For the moment though, you can just copy the compiled binary to your device and start it.
Originally posted in rudihorn/drm-vc4-grabber#6 (comment)

I wonder if it is worth reaching out and forwarding your questions on to the developer? He may be able to resolve any concerns you mention and possibly add some tailored integration for HyperHDR?

Please let me know if I've misunderstood any of the above; as there's plenty about this project I'm yet to learn.

Thanks for the incredible work on the project so far.

[awawa-dev]

Hi
Personally, unfortunately, I do not have enough currently free time to deal with reverse engineering of closed drivers, especially in the case of Broadcom, which has a lot on its conscience when it comes to open source. Of course, I am not saying that it is not impossible, although past experience teaches us that we should be careful because capturing the image is only half the success: it should not be done at the expense of problems with video playback (e.g. stuttering) and there remains the issue of tone mapping. In the case of Libreelec, there is some hope because it can be compiled to use Pipewire and it has long been supported in HyperHDR. I haven't tested it, some modifications will probably be necessary because the Portal probably doesn't work, but it's cosmetic if Pipewire actually works. You just need to consider whether RPi is currently suitable for the Media Center platform or just a host for HyperHDR and USB grabber. Broadcom has been so busy squeezing profits from producing components for the RPi that essentially the RPi5 stands almost exactly where the RPi4 stood many years ago, without much in the way of multimedia support.

[NashJames]

So you basically reckon that even if a software grabber was possible, it's not worth the effort because the chances are relavtively high that either HyperHDR or video playback will suffer in some way; if not both. The reasoning makes perfect sense. A slight shame we aren't there yet but hopefully one day in the future support will be better.

I also completely understand not having the time. Cheers for the explanation.

[awawa-dev]

As I wrote, I think Pipewire (not DRM) will be the best solution because it also offers hardware acceleration and "civilized" access to the render buffer without any hacks. Unless something new comes along, but there is no such sign yet. However, it must be implemented by the operating system or desktop environment. If I have time, I will check the current status of LibreELEC with Pipewire (must be compiled with enabled support), but I'm afraid it won't happen soon. Unless someone else can test this solution to see if it is currently usable, although you certainly have to take into account the introduction of minor corrections to use Pipewire directly without initializing the Portal/DBus (this step of authorization/selecting a monitor will probably simply be omitted)

[NashJames]

Ah that makes more sense. Thanks!

That sounds awesome if it works.

If you don't find yourself with time, could it be worth putting into an issue with a 'help wanted' tag on? Someone with more knowledge than me may be able to do a bit of investigation for you.

If you describe what this means for the project (no more streaming device, video grabber, extra cables, etc.), I'm sure people will be interested in helping!