Hi @santievil
I added ENABLE_AMLOGIC to cmake configuration and it should enable amlogic build & runtime. Could you check it?
BTW could you move variables that using malloc/free to the class body. And instead use malloc/free c++ wrapper MemoryBuffer (#include <image/MemoryBuffer.h>) for example MemoryBuffer<uint8_t> that includes 3 methods that you probably need: releaseMemory, resize (to allocate memory), size (to check if it's allocated and has correct size, 0 means it's empty)

EDIT:
... and data() to get the pointer to the MemoryBuffer internal data buffer.

Example of ENABLE_AMLOGIC activation in the plugin cmake configuration:

source: https://github.com/awawa-dev/CoreELEC/commit/d410ed974660f85dc003919c459ee66bc6464839

You have the changes.
I’ve left the Amlogic video constants and moved the rest, but if you want, I can move those as well.
I’ve used the memory functions you suggested and removed some memory releases that didn’t seem right to me.

If I compile it with only -DENABLE_AMLOGIC enabled, it doesn’t work.
If I compile it with only -DENABLE_FRAMEBUFFER enabled, only the framebuffers work.
If I compile with both enabled, it works. It works so well that I need to try adding some delay in smoothing (bad TV, and bad controller... that’s what it is, I’m poor haha). This was happening to me during my previous tests.

If you need any version to test, let me know and I’ll upload it. Cheers!

Thank you. I think I found and corrected the issue with ENABLE_FRAMEBUFFER: you can disable it now and enable only ENABLE_AMLOGIC.

Ok, now it works ok only with ENABLE_AMLOGIC ON but, since the framebuffer is not enabled:

• We don't have the option to change the resolution, frame rate, and other settings from Video Capture -> Software Screen Capture. It comes with default values 512,10,200,0,0...
• We also can't enable Video Capture -> Instance Screen Capture. Interestingly, the option to enable System Screen Capture does appear in Remote Control (which is why I was able to test it).

All this with a clean installation... previously, I had my configuration saved.

Thanks for the fast feedback. New commit should fix the issues with the web interface.

Great, much better now.
If I had to nitpick, I'm not sure if the other detected framebuffers should appear...

Wouldn't it be better if it simply showed "Amlogic" and didn't allow changing it?

I’m uploading the version ready for testing:
https://github.com/santievil/HyperHDR/releases/download/v.0.0.1.beta1/service.hyperhdr-21.2.1.AMB1.zip

It's up to you. The device discovery is done here and you can change it but keep in mind that the procedure is also used for device discovery when init: https://github.com/santievil/HyperHDR/blob/amlogic-grabber-refactor/sources%2Fgrabber%2Flinux%2Famlogic%2FAmlogicGrabber.cpp#L206

I current don't have amlogic device with installed CoreElec to test it so let me know if you are ready to merge your PR.

It's more of an aesthetic thing than anything else, but since I don't know how it will behave on other devices, I'd rather not touch it and let each user choose what works best for them.

I'm ready whenever you are. I've been testing it these past few days, and it works very well, but I feel uneasy about being the only one who has tested it.

That's ok: most of the new features are also tested only by me : 😉 Hopefully after submitting a plugin for CoreElec we will receive more feedback. New feature is separated from the main code of HyperHDR so there is very low risk it will break something in the mainline release even if there is a bug. So we are merging PR?

Yeeees, do it.

It's more of an aesthetic thing than anything else, but since I don't know how it will behave on other devices, I'd rather not touch it and let each user choose what works best for them.

I'm ready whenever you are. I've been testing it these past few days, and it works very well, but I feel uneasy about being the only one who has tested it.

I'm not sure how to build the solution myself, but if someone can share a CoreElec plugin build, I can test it as well. I'm running CoreElec on multiple amlogic devices.

@santievil Do you think you could prepare a PR for CoreELEC so that the HyperHDR add-on could be available to more users?

I'm not sure how to build the solution myself, but if someone can share a CoreElec plugin build, I can test it as well. I'm running CoreElec on multiple amlogic devices.

This has been compiled with PROJECT=Amlogic-ce DEVICE=Amlogic-ng ./scripts/create_addon hyperhd for arm devices. If any of your devices are compatible (mine is a Nokia 8010), you could try this one:
https://github.com/santievil/HyperHDR/releases/download/v.0.0.1.beta1/service.hyperhdr-21.2.1.AMB1.zip

@santievil Do you think you could prepare a PR for CoreELEC so that the HyperHDR add-on could be available to more users?

Sure, I can try it.
Let's see if I’ve learned something... I’ve created a new branch with the changes.
Please check the package.mk, as that’s the one I’m concerned about, and once everything is correct, I’ll make the PR. I think it’s only these 3 files...

https://github.com/santievil/CoreELEC/commit/8558594800eb9a93d33bfaca290bef980ea0265b

Sure, I can try it.
Let's see if I’ve learned something... I’ve created a new branch with the changes.
Please check the package.mk, as that’s the one I’m concerned about, and once everything is correct, I’ll make the PR. I think it’s only these 3 files...

Thanks again. I found only some minor issues (due to PR is already merged with the master) so added my comments to the commit. You can also include icon and screenshot from https://github.com/awawa-dev/CoreELEC/commit/d410ed974660f85dc003919c459ee66bc6464839#diff-a5c211aeddf62d07f08f8b5e1f062a58896e8868bf742a58076160767bf3bc84

It compiled fine, but the service wouldn’t start. It gave this error:

./hyperhdr: error while loading shared libraries: libzstd.so.1: cannot open shared object file: No such file or directory

I've taken these commands from some version I had (I'm not really sure where I got them from...).
I compiled it and it works correctly. Should I add them to the package.mk?

   patchelf --add-rpath '$ORIGIN/../lib.private' ${ADDON_BUILD}/${PKG_ADDON_ID}/bin/hyperhdr
   mkdir -p ${ADDON_BUILD}/${PKG_ADDON_ID}/lib.private
   cp -p $(get_install_dir zstd)/usr/lib/libzstd.so.1 ${ADDON_BUILD}/${PKG_ADDON_ID}/lib.private

Its in the LibreELEC HyperHDR addon. Since CoreELEC is a fork of LibreELEC it should work too. zstd (added recently thats why my addon doesnt care about the lib) can be also disable in the build without much loss, but patching rpath is a better idea. OK, please add this fix.

Ok, lets see:
CoreELEC/CoreELEC#357

@santievil thanks at least you tried. This fork of LibreELEC is Hyperion oriented and it ended with made-up arguments when Hyperion doesn't have these changes in Libreelec https://github.com/CoreELEC/CoreELEC/commits/coreelec-22/projects/Amlogic-ce/packages/addons/service/hyperion.ng/package.mk

Yes, a shame. For now, I'll leave this here:
https://github.com/santievil/HyperHDR/releases/tag/21.2.201
If I have time, I'll try to compile it for ARCH64.
If you think we can do anything else, let me know and we'll check it out.
Thanks a lot for everything, I've learned a ton!