Well that’s fun! Dug out my old N2 which I abandoned after needing Dolby Vision playback. Put your build on and… it works and looks good!
Plus maybe it’s just my imagination, but the S922X feels way faster than the S905X I’ve been using.
S922X is much more powerful than the S905X4 versions, Cortex A73 cores compared to A55.
Yeah, I need a new box for my main system and will probably be going for the S922X-J… but this is great use of the N2s, since I’ve been using a combination of an old Chromebox for 1080p and the Kodi built-in to my Android-based TV for 4K/DV (not enough storage for my entire library and I haven’t cared to try to expand).
Sorry I have to ask, but what do I currently need to do to get DV working on CoreELEC on the N2? I read somewhere the needed changes where put in the regular nightlies quite some time ago. A stable was released after that as far as I can see. I guess the changes didn‘t make it there? Will the nightlies work or do I need to use the mega uploaded version from this thread? Sorry, it‘s much to read and a bit hard to follow…
A post was merged into an existing topic: Homatics Box R 4K Plus
Will need to use the mega version. This work is “unsupported” so will not become part of any released version of CE.
Hi there,
I just read that there is an “unsupported” CE version that can play DV.
I read a lot of posts but didn’t get how to install it, no link to the release file, no how to.
I have a LG TV G4, a Odroid N2+ and was searching a new box but can’t find one good at this time.
I’d be glad to try this release to wait better time.
What are the limitations about the DV profiles and layers?
Could you please give me all info to get it and install it.
Many thanks
Yes, there is an unsupported version, but this is not CE.
If You want to get more information, feel free to ask the developer.
Hint:
This developer is not team CE and he is not in this forum
He is here in the forum.
1 Like
He said "No Support"and there is no active development
We can’t promise anything but we may look into this in the next few weeks. We never know where this may take us.
6 Likes
@doppingkoala I try to read your commit on common_drivers 5.15 but I would have some questions. So please you might get in contact with us so we can check if a implementation is possible or not.
Unless I am totally missing something, pretty sure this has been very well proven.
This is contact, ask the questions.
Happy to help out, but I won’t really have much time for the next few weeks.
It’s functional, but the stuff on github is a bit outdated. Might get around to updating the 4.9 code before that - including the working proof-of-concept for profile 5. The code for 5.15 would be very close, just differences in setting the hdmi modes and accessing the screen buffer.
Wouldn’t recommend using the approach of modifying the screen buffer though. OSMC have shown the hardware that can inject metadata works without a license, just need to set the hardware registers. CPM has worked out which ones the metadata gets written to in solving the clipped bug. Would be a much better approach - would also solve the flickering issues that result on >30Hz content that result from needing to run a native resolution gui in the modifying screen buffer approach I have used.
In the modified libdovi.
No FEL. Profile 5 (currently) doesn’t work - I have a working proof-of-concept to solve this though.
Keep scrolling up this thread until you find the link to the latest version on mega.
1 Like
Are the sources of the “new approach” available?
Osmc do keek hide all sources like closed source media centre.
Are the libdovi changes are still need? Because I have written with quitevoid about a implementation.
CE only focus on CE-NO, so 5.15. There is no real reason to implement such feature in old EOL 4.9 kernel.
About the hardware register: I found some stuff about the dm_meta data in the vdin part of the sources. They use hardware access, but it’s almost the reverse way you did do your implementation.
So I guess it’s about this source section:
Far as I can tell, they have made there own version of dovi.ko, and just like the original, it doesn’t appear directly set any hardware stuff and rather just outputs the data that is then written to hardware in the open source linux code in amdolby_vision.c. Go through the cpm discussion on fixing the clipping bug to see the registers / parts of code that write this metadata - I’d post a link but…
Based on what OSMC have done, I guess that only FEL and (maybe) the P5 decoder are what are looked behind the soc license. The P5 part can seemingly be worked around using the generic lut based transfer functions that are normally used for hdr /sdr conversions etc and that P5 only has a nonlinear mapping for the luma channel
At some point the metadata format needs to change from what is in the original SEI data as stored in the video file, to the form suitable to be written to the screen buffer / hardware register.
I did it in libdovi because it seemed simplest, asked quietvoid to add it as a option to libdovi but it was declined. Fairly straightforward to do though Add feature to write display management metadata suited for tv-led DV. · Issue #303 · quietvoid/dovi_tool · GitHub. This conversion step happens in dovi.ko normally and is similarly hidden away in the OSMC version.
Haven’t seen that before, maybe that is for reading a dolby vision HDMI input? Don’t think it is relevant.
Pretty sure just need to look at the parts of the code the write to the hardware registers after calling dovi.ko in amdolby_vision.c.
Yes, it’s about HDMI input. We also never got in touch before in this area. I just was reading the same procedure you used, only reverse way.
So the way to inject the pixel data into the OSD canvas isn’t anymore the best approach?
Also I find no reason why you have chosen 0xe1 as canvas index.
And is it still need to have 4k resolution for the injection? Or can it also be used with 1080p?
I talked to quitevoid and he showed me the closed issues. Now some time got past by and he might want to add a new function call in libdovi, maybe…
So if you are able to share latest status on GH I can take a look what did change about current implementation.
Doesn’t matter if for 4.9 as I am able to port it to latest 5.15 by myself. I would just need a build to be able to compare if all works correct.
As CE do support DV with official licence we are still not sure if and how such implementation will looks like on the end. Especially I am in concern about vendors, paying for a DV licence what on end will not neiat all. Also I am not sure what Dolby Laboratories will say about it…
So please keep us updated with last working implementation so we can check it out.
Is there a osmc image for download including this feature?
Or someone can dump the dovi.ko from Vero V?
Thx
1 Like
I don’t think so.
Because it seems to be the gui canvas index, so let me write over the video layer.
Admittedly, had little idea with what I was doing on the amlogic side of it when I did that. Any input/changes from you who knows better would probably be an improvement.
To embed the metadata you needs exact (bit-level) control of the top pixels, so the gui needs to be not scaled. So giu resolution needs to match the output resolution. So I needed to disable the giu scaling option, so for 4k output → 4k gui, 1080p output → 1080p gui.
To be clear, the DV injection works for both 1080p and 4k output, just need the gui resolution to match.
These issues would all be avoided if the hardware-based method to embed the metadata can be made to work. Why I suggest that would be the preferred method, and the one that OSMC has seemed to take.
Will get around to updating github. Changes are really just minor cleanup / hdr10+ conversion stuff. No change to how the metadata is being embedded or anything else ‘fundamental’ to getting tv-led DV working.
The use of a own dovi.ko sounds really the best solution.
And as I thought OSMC: OPEN source media centra is now CSMC: CLOSED source media center.
They have now a dovi.ko_enc, encrypted module.
As it’s their own module they will never make it public - thank you to open source world. And as it’s own source it’s nothing about “secure” or NDA, it’s only paranoia. Even Amlogic itself do not encrypt the module, only CSMC. Take everything from open source, add other stuff, encrypt it and sell it.
This is the way.
Supporting such platform is a punch into the open source users!
I am not sure how about Dolby Vision Laboratories do think about such violation…
10 Likes
Let’s see how long it takes before CSMC steal the VP9 HDR10+ open source again and include it in their product to pull even more money out of users’ pockets…
6 Likes