Amlogic grabber?

[santievil]

Hi!

This Christmas, I got a Nokia 8010, and after reading some recommendations, I decided to install CoreELEC.

Although Hyperion.ng works correctly, I set out to try installing HyperHDR.

After a few attempts (I think), I managed to compile the v21 beta1 for CoreELEC.

I haven't been able to test if everything works correctly (I don't have a capture card), but I did see that it works with Instance Screen Capture.

I would be interested in having the Amlogic grabber available, but although I have some programming knowledge, I have no idea how to implement it.

I would need some guidance if anyone knows how to approach this, at least a general overview that helps me understand it without going crazy.

Thanks for the help, cheers!

[awawa-dev]

Hi
Amlogic was present when I fork the project but it was removed at some point as I could not maintain it then: https://github.com/awawa-dev/HyperHDR/tree/51547f31347d7279c32e59177bed359245eef01b/libsrc/grabber/amlogic Maybe it's possible to restore it?

[santievil]

Let me take a look and see what I can figure out. I'll let you know if I make any progress or not.

[awawa-dev]

OK, let me know if you need anything because this is quite old code. But you can refer to the simplest framebuffer to update it: https://github.com/awawa-dev/HyperHDR/tree/master/sources/grabber/linux/framebuffer
You definitely need to add the directory to https://github.com/awawa-dev/HyperHDR/blob/master/sources/grabber/CMakeLists.txt to activate the build. And an attempt to activate the grabber itself during runtime is in this section

HyperHDR/sources/hyperhdr/HyperHdrDaemon.cpp

Line 524 in c8a5147

#endif

[santievil]

Hi! I haven't forgotten about this...

I've been learning git and trying to understand how this all works. After several attempts trying to make the grabber (without much success, issues with Qt, different libraries, repeated classes,...), I decided to change the framebuffer implementation a bit so that if it detects an Amlogic device, it adds it to the list. This is basically what I think is done in HyperionNG.

The problem is that it is returning this error:

2025-02-15T09:45:33.459Z [FRAMEBUFFER_SYSTEM:/DEV/FB3] Could not get the framebuffer dimension for '/dev/amvideocap0' device. Reason: Operation not permitted (1)

In the code, I saw that it tries to gather the information with:

ioctl(_handle, FBIOGET_VSCREENINFO, &scr)

But it is set to read-only:

_handle = open(QSTRING_CSTR(foundDevice), O_RDONLY);

So I changed it to O_RDWR, but it still gives the same error.

If the device is supposed to be amvideocap0, I don’t understand the permission error. Both programs run as root:

CoreELEC:~ # ps aux | grep Hyperion
 6359 root      0:00 grep Hyperion

CoreELEC:~ # ps aux | grep HyperHDR
 6517 root      0:00 grep HyperHDR

CoreELEC:~ # ls -l /dev/amvideocap0
crw-------    1 root     root      508,   0 Feb 27  2024 /dev/amvideocap0

CoreELEC:~ # ls -l /dev/amvideo
crw-------    1 root     root      264,   0 Feb 27  2024 /dev/amvideo

If I change the device to /dev/amvideo:

2025-02-15T10:22:07.983Z [FRAMEBUFFER_SYSTEM:/DEV/FB2] *************************************************************************************************
2025-02-15T10:22:07.983Z [FRAMEBUFFER_SYSTEM:/DEV/FB2] Starting FrameBuffer grabber. Selected: '/dev/amvideo' (3) max width: 512 (512) @ 10 fps
2025-02-15T10:22:07.983Z [FRAMEBUFFER_SYSTEM:/DEV/FB2] *************************************************************************************************
2025-02-15T10:22:07.983Z [FRAMEBUFFER_SYSTEM:/DEV/FB2] Could not get the framebuffer dimension for '/dev/amvideo' device. Reason: Invalid argument (22)

And here I ran out of ideas...

Any hint on where to continue? I think this is the right way.

If it has to be amvideo, I can’t figure out the reason for the error.

I know that amvideocap0 is the capture device and amvideo is the display, but I'm not clear on how to use them with the framebuffer.

This is fun and you learn a lot, but it's a pain to test.
Thank you very much for your help and your time!

Im testing from here: https://github.com/santievil/HyperHDR

Best regards

[awawa-dev]

Hi
Im not sure if amlogic hanldes at /dev/amvideocap0 & /dev/amvideo are always active or only if the video starts to play and CoreELEC starts to using video acceleration. Tell me, if you used a framegrabber in HyperHDR, did you get an image from the CoreElec GUI and when the movie started playing, only a black screen? If so, when grabbing a frame, you should start with the amlogic handle and if it doesn't work (GUI mode), try the frame grabber handle.

[awawa-dev]

also it seems to me that we can't open one handle permanently because it can change - only for a moment when we capture a frame. Autodetection of grabbers/handles may also be unnecessary because the amlogic grabber will simply forced by some definition passed to the compiler, e.g. ENABLE_AMLOGIC so we assume that the user who uses it compiles it for these devices.

[awawa-dev]

I still have https://www.hyperhdr.eu/2022/05/tv-box-mania-iv-part-a95x-f3-air.html so if you want I can put CoreElec back on it and help you out.

[santievil]

Im not sure if amlogic hanldes at /dev/amvideocap0 & /dev/amvideo are always active or only if the video starts to play and CoreELEC starts to using video acceleration. Tell me, if you used a framegrabber in HyperHDR, did you get an image from the CoreElec GUI and when the movie started playing, only a black screen? If so, when grabbing a frame, you should start with the amlogic handle and if it doesn't work (GUI mode), try the frame grabber handle.

You nailed it. If I try to capture a frame from the GUI:

CoreELEC:~ # dd if=/dev/amvideocap0 of=/storage/capture.raw bs=1M count=4
dd: /dev/amvideocap0: Resource temporarily unavailable

But if I do it with an active video:

CoreELEC:~ # dd if=/dev/amvideocap0 of=/storage/capture.raw bs=1M count=4
4+0 records in
4+0 records out
4194304 bytes (4.0MB) copied, 0.091591 seconds, 43.7MB/s

/dev/fb0 works as long as you're in the GUI and for videos if hardware acceleration is disabled, otherwise only get a black screen.

also it seems to me that we can't open one handle permanently because it can change - only for a moment when we capture a frame. Autodetection of grabbers/handles may also be unnecessary because the amlogic grabber will simply forced by some definition passed to the compiler, e.g. ENABLE_AMLOGIC so we assume that the user who uses it compiles it for these devices.

From what I've seen in their code, they check if "/dev/amvideo" is active. If it is, they call grabFrame_amvideocap, which captures the frame through "/dev/amvideocap0". If not, they continue capturing via the framebuffer.

I still have https://www.hyperhdr.eu/2022/05/tv-box-mania-iv-part-a95x-f3-air.html so if you want I can put CoreElec back on it and help you out.

I wouldn't want to take more of your time (I don’t know how complicated all this is), but it seems like something feasible to do.
Unfortunately for me, I don't know how to implement their code the way you have it implemented, other than trying to pass "/dev/amvideocap0" and seeing the permission error.

On my side, I will keep trying. I've gotten this far and I don’t mind continuing to test. If I can help with anything, let me know.

Regards and thanks again!

[santievil]

Hello again!

I've been doing a few more tests and I can now capture the image, but it comes out tripled and not very well aligned...

The video I've been using for testing is this one

Any clue about what might be happening? I'm dumping some frames and they seem to be captured correctly:

Data to test files is converted later with ffmpeg:
ffmpeg -s 512x512 -pix_fmt rgb24 -i capture_250224205732.rgb capture_250224205732.jpg

I don't understand why this is happening.

I've uploaded the version in case you want to test it:
https://github.com/santievil/HyperHDR/releases/download/v0.0.1-alpha/service.hyperhdr-21.2.205T5.zip

Code in:
https://github.com/santievil/HyperHDR/blob/amlogic-grabber2/sources/grabber/linux/framebuffer/FrameBufGrabber.cpp
using processSystemFrameBGR as you recommended.

Thanks and regards!

[awawa-dev]

Hi
Unfortunately Im currently out of coding for at least next few weeks. processSystemFrameBGR depends on getTargetSystemFrameDimension, and getTargetSystemFrameDimension depends on correct _actualWidth and _actualHeight values. They are set for the frame buffer capturing but not for the amlogic processing. I guess that might cause this image misalignment.

[santievil]

Thanks for the hint. I'll keep investigating to see if I can get it to work.

[santievil]

Well, a couple of changes and it more or less works:

https://github.com/santievil/HyperHDR/releases/download/v0.0.2-alpha/service.hyperhdr-21.2.205T10.zip

It doesn't work for videos encoded with AV1 (image appears distorted in "Live video.").
I'm not able to capture the image correctly either from the code or by trying a dump with commands. I don't know what makes this codec special, but the others I've tested have worked fine.

[santievil]

Hello!

This weekend I finished some tests with beta2.
I have a version that works on:

https://github.com/santievil/HyperHDR/releases/download/v0.0.3-alpha/service.hyperhdr-21.2.205.T9.zip

I had to add a platform.sh to enable the codecs, just like I did in the previous beta... and add the activation of AV1. Now it should work all the time.
I also enabled the framebuffers since they were disabled in the default package.mk.

HyperHDR appears as an addon in the CoreELEC repository (I didn't do it), it comes with the framebuffers disabled, and two capture devices via USB appear (video10 and video23).
As far as I know (which is not much), these devices are used by the internal grabber, but the decoded output should be amvideocap0.
In my tests, I haven't managed to get it to work, and if I keep working on it, I might lose my mind completely.

I noticed that version 21 has been released, so everyone, go ahead and test it!

[santievil]

New version from 21 final release.

https://github.com/santievil/HyperHDR/releases/download/v0.0.4-alpha/service.hyperhdr-21.2.1.T7.zip