And definitely no change if you first change the tone mapping, then re-start the video? I don’t know anything about the code/how it works in Kodi - just an idle though it might set the mapping values only on video start? Probably not but worth a check if you’ve got a test system set up anyway.
(My guess is that something about the current CE tone-mapping implementation (i.e. what the CE setting controls) - causes this to be skipped over somehow…)
Same behaviour on C4 as on N2.
Cycling within the tonemapping occurs with ALT-F11, but no visible change of picture quality.
And in CoreELEC settings the switch HDRtoSDR has no effect.
Pressing ‘o’ the info is always ‘EOTF & Gamut: SDR BT.709’
In kodi.log there is only this regarding GLES:
CoreELEC20:~/.kodi/temp # grep -i gles kodi.log
2021-11-04 21:57:59.638 T:4967 INFO <general>: RetroPlayer[RENDER]: Registering renderer factory for OpenGLES
2021-11-04 21:58:00.119 T:4967 INFO <general>: GLES: Maximum texture width: 8192
2021-11-04 21:58:01.132 T:4967 INFO <general>: GLES: Enabling VSYNC
CoreELEC20:~/.kodi/temp #
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) ------
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. 
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.
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
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.
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.
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.
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.
About | FAQ | Terms of Service | Privacy Policy | Legal Notice