ACES Filmic tonemapping has been ported to GLES

no, there is no change after ALT-F11 and restarting the video.
In the debug log appears the following when pressing and releasing ALT-F11:

CoreELEC20:~/.kodi/temp # tail -f kodi.log |grep -v 'DEBUG <general>: CVideoPlayer::ProcessVideoData '
2021-11-04 22:32:49.842 T:4964    DEBUG <general>: Keyboard: scancode: 0x38, sym: 0x134, unicode: 0x00, modifier: 0x300
2021-11-04 22:32:49.842 T:4964    DEBUG <general>: HandleKey: alt-leftalt (0x4f0d4) pressed, window 12005, action is
2021-11-04 22:32:50.789 T:4991    DEBUG <general>: CLibInputKeyboard::ProcessKey - using delay: 250ms repeat: 33ms
2021-11-04 22:32:50.789 T:6520    DEBUG <general>: Thread Timer start, auto delete: false
2021-11-04 22:32:50.793 T:4964    DEBUG <general>: Keyboard: scancode: 0x57, sym: 0x124, unicode: 0x00, modifier: 0x300
2021-11-04 22:32:50.794 T:4964    DEBUG <general>: HandleKey: alt-f11 (0x4f09a) pressed, window 12005, action is CycleToneMapMethod
2021-11-04 22:32:50.810 T:4964    DEBUG <general>: ------ Window Init (DialogNotification.xml) ------
2021-11-04 22:32:50.885 T:6520    DEBUG <general>: Thread Timer 3757036160 terminating
2021-11-04 22:32:50.893 T:4964    DEBUG <general>: Keyboard: scancode: 0x57, sym: 0x124, unicode: 0x00, modifier: 0x300
2021-11-04 22:32:51.460 T:4964    DEBUG <general>: Keyboard: scancode: 0x38, sym: 0x134, unicode: 0x00, modifier: 0x0
2021-11-04 22:32:52.734 T:4964    DEBUG <general>: ------ Window Deinit (DialogNotification.xml) ------

see logfiles here:
http://ix.io/3E2E

Try to turn off hardware acceleration, and see what happens.

yes, this does the trick! When amcodec is disabled, then cycling ALT-F11 shows the 3 different tone mappings instantly when playing a video, no video restart is required.
I have different HDR videos, ALT-F11 shows an effect only, if the video contains the metadata

Mastering display color primaries        : XXX
Mastering display luminance              : XXX

Without this there is no change in picture quality.

BUT:
on my N2 CPU usage goes to 550% (all 6 cores are 90-100%), video is very choppy and not viewable…
This was with a 4K-24fps video, with 60fps it is even worse…

So with SW-decoding only it is not usable. :disappointed: :worried:

I assume that these are filters, and cannot be applied to video that is being decoded in hardware, as the video pipeline is amlogic specific, and Kodi doesn’t really have access to it.
I’d recommend checking how it works on Android and/or Windows, just out of curiosity.

From Kodi dev: “Ah right, I’d forgot that Coreelec haven’t made the move to modern methods yet and are still supporting the legacy amcodec only.”

Yes, and CE is the only platform support all codecs in hardware…

When you want to use software decoding to only you can use mainline as it will never be supported.

1 Like

Yeah, they need perfect HDR->SDR conversion because their HDR sucks. They have it for what? 2 all weeks now? But in the end you shouldn’t use any of this crap. SDR is SDR and HDR is HDR. The rest is messing with the raw video.

So the addition of OpenGLES support of this tonemapping still doesn’t mean it can be supportedwith hardware acceleration in Coreelec?

Best choice:
Buy a TV that supports HDR

1 Like

No idea, feel free to invest hours of research and make a PR, please.

@Portisch shouldn’t it be possible to use the FB mode we use for hyperion? It may allow Kodi to apply the changes to the image that way? Or am I totally off on this?

Completely fine if you don’t want to work on it, or support it or whatever, that’s 100% your choice, (always!).

But there are, I think, genuinely reasonable use cases here - e.g. I have an 4K HDR TV (Panasonic OLED) + up to date receiver, but I also have an older 2K/SDR projector. But sometimes the kids call out for a proper ‘movie night’ and we only have an HDR copy of a movie…and sure, it would be better to have an SDR version right at that moment. But it would be nice if that could be sent to the projector with significantly improved tone mapping…the N2/+ tone mapping is well known to be pretty awful (I thought the C4 was supposed to be a noticeably better job though?).

Or of course folks with multiple Kodi installs, and perhaps not every TV in the house yet supports HDR. People understandably don’t want to maintain two libraries or two source files for one thing, as a rule.

In any case, these methods (ACES etc) on other platforms, are reported to offer good or at least more usable results. Hence people are naturally interested, even if, in a perfect world, it’s far from the ideal solution of HDR on HDR. Kodi is after all the swiss army knife of media players, so not too surprising people want to explore this…

Anyway, I’m sure you know all this. So it seems nothing has really changed since this HDR to SDR tonemapping - #31 by cdu13a … unless there is some way to pass the filters in to the amlogic bit, or modify the image on the way back out.

1 Like

As far as I know Kodi get each single frame from hw decoder by GetPicture function. Then it goes through the Kodi RenderManager and back to the hardware by ReleaseFrame. So the RenderManager would be the place to modify the frames, but I am not sure.

This was what Kodi developer Fritsch had said when these algorithms were originally implemented in Kodi for D3D and OpenGL:

Those named arm devices rely on mediacodec surface to be able to decode and especially output 4k content.

They are far too slow for doing proper tone mapping on the 3D GPU. While on windows and OpenGL world most of the time the GPU and the ipu are the same, this is exactly not the case on arm and getting decoded data back into the 3D GPU needs a full dma copy import.

…I had thought the addition of OpenGLES (which unlike D3D and OpenGL is supported here) versions of the algorithms would change things, but perhaps what he said still applies? I don’t know enough about any of this to have a clue.

1 Like

I think this is not possible. And also no priority at all. If you have none HDR TVs in your household buy cheap Amazon 4K Firesticks for them. Then you have official Kodi support and can get another excuse why it doesn’t work there from Team Kodi. This has nothing to do with old methods.

CoreELEC on Amlogic is still the best media experience. But it’s not 100% perfect and it never will be. We could have just done what LibreELEC did and wait for mainline. They are waiting now for 4yrs and it’s not even close or usable.

I wouldn’t be optimistic about the tonemapping. It’s like the 3D support. It will never happen.

1 Like

As a follow-up, same situation in Nexus nightlies for Android Kodi (on Fire 4k) and Libreelec (on Rpi). Tonemapping can only be applied with all hardware acceleration turned off, and none of these devices are powerful enough to play 4k without acceleration. So I’m not really sure why the GLES support was added if no device can take advantage of it?

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.