I think that it’s probably best to try and do a clean room re-implementation of dovi.ko. The lack of FEL support in -NO has really been detrimental to this community and I think most users would gladly switch over to -NO once it gains FEL support.
Personally, I don’t think that Dolby Labs is going to come after CoreELEC because they’re not much financial benefit. OSMC has obviously circumvented the Dolby license and they’re not being sued. Of course, to be extra cautious, CoreELEC can create a dovi.ko only for -J/K processors and whatever the opensource community does next will not be the responsibility of CoreELEC.
Didn’t think that was the case anymore, might have been previously.
Do it by modifying the gui layer then. Works, but has limitations with skins modifying the top pixels and flickering problems when a >30hz 4k gui is running.
To be honest, with a modified skin the only remaining issue here would be 4k output at >30Hz output - probably can be ignored as only a issue for literally a few titles.
Actually, a far nicer approach may be what I tried to do previously, but couldn’t get working.
Figure out how to enable the second OSD layer above both the video and existing giu/OSD layer. Have this layer only cover the top portion of the screen (top 4 pixels for 4k output, top 8 pixels for 1080p output), and then write the metadata to that. I didn’t work out how to enable the second OSD layer at all.
In my mind, this approach would avoid issues with skins, requiring 4k a gui at >30Hz that flickers, and entirely avoids the need to deal with any DV hardware within the soc.
To be honest, having you (or someone else) that actually knows the soc and the code well do something like this (enabling the second OSD layer) to “polish up” my (what was only originally) a proof-of-concept was where I thought you could provide the most value for this work.
Maybe, now that you seem to have some interest (and maybe time that wasn’t there previously), something like that could happen now that all uncertainty about “what” needs to be done has been resolved and it is just the “how”.
Right now the status is to reproduce your canvas way.
I tried to read the canvas on S5, S928X, but the addresses are all NULL.
Not sure, what SoC you used and what owner do I need to look for in the canvas pool?
Also I miss the link to the pixeldata you create and shift in the buffer.
Is there any document for this? Or how to check the result?
I did see you moved the data behind the 1080p or 4k memory of the canvas.
What I do see in the vdin module it get back the ready md data. But you do feed “raw” data directly into the buffer.
I looked in to this and they seem to pass through DV metadata now, tone mapping only happens if the TV doesn’t support DV.
With Profile 5/7/8.1 streams, the Vero V “passes through display management metadata to DV displays”. So the TV recognizes and plays (display-led/TV-led) Dolby Vision.
Obviously it doesn’t play FEL and plays the HDR layer plus RPU and Player-led/LLDV isn’t possible as No DV license.
No, it can’t. The TV reports the DV vsif packet received.
This is only about the HDR mode, it’s not about the meta data.
The meta data is mapped like their P5 method.
Just look at their hidden sources…
Conclusion: invest less money and get real DV support.
Yes, i can capture DV RGB in ARGB32 or R210 format. I don’t remember which one is the right one when I was making captures for @doppingkoala. But I can do it in both formats.
Can you also share some capture of a P5 file played in DV? So I can see original data how it should look like. I don’t know if you have a DV capable system.
Also please share the sample P5 so I can replicate it local here.
Hi, I’ve installed latest build on my vontar x4 unsupported box. The dolby vision is hit or miss where on some files it loads up but the colors are greenish/bluish and other files are just black screen with dv activated on tv. I do not have any settings for dv in corelec settings. Any help?
Hmm, unsure. Not sure if any others have tested on a S905X4, has anyone else tried on a box with a S905X4?
Few questions:
Does it work on any file at all? Can you pick any sort of pattern to when it works / when it doesn’t?
For any given file, are the results consistent for that file, i.e. it either works or it doesn’t? In particular try a profile 8.1 file and a profile 5 file.
“but the colors are greenish/bluish”, Strongly suspect these are p5 files (currently the reshaping is unsupported ). Despite that, does the tv activate DV mode? Have a suspicion this will lead to an answer to the problem.
Used a S905X3. No idea what the owner was, (from memory) look for the canvas that has dimensions that match a vertical height of twice the vertical resolution of the gui and four times the horizontal resolution of the gui. This canvas has two copies of the gui (framebuffers?) stacked vertically in ARGB, can either work out the correct/current copy that is output and write metadata to that, or (less nicely) just write to both of them.
For NO, I remember two of the canvas matched that, both seemed to point to the same thing though and both worked.
This canvas method is obsolete anyway. It’s not used anymore since T7.
And the OSD canvas index is different for each SoC, when it does exist at all. This is why I was asking for the owner name to be sure.
For P5: isn’t it enough to transfer the meta and trigger DV mode on TV? So the TV is doing all the job?
.