It needs your EDID as a base, the first tool is for both Mac and PC so should be good if you did not know , it is not hard - better to teach how to fish
Do you have the original spreadsheet that png was taken from? Would be useful to have.
Steps required:
Make sure the Ugoos is connected in your normal setup, projector, receiver etc. without your LLDV converter device.
ssh into the Ugoos
ssh needs to be enabled for CoreELEC via the settings
use terminal on mac to access the ugoos as the root user e.g.:
ssh root@192.168.86.236 (use the IP address of your Ugoos)
type in the password to login in.
Once logged in use this command to save your normal setup EDID.
echo save bin /storage/downloads/jonke-pj.bin > /sys/class/amhdmitx/amhdmitx0/edid
Enable samba for CoreELEC via the settings
Connect to the COREELEC network location and open the Downloads share
There you should find the jonke-pj.bin file.
Open the AW EDID Editor app
Drag the jonke-pj.bin file into the main window of the app
This should load the file and show its contents for manipulation.
Assuming you have no existing Dolby VSVDB you need to add one
On the left open the drop down Add new CEA Block
From the drop down list choose Vendor-Specific Video
On the right can then add the details
The IEEE OUI is in decimal in this app so for Dolby enter: 53318
For the Payload (Hex String) take from your picture e.g.: 490348A15855A2
File -> Save As... And save back to the Downloads folder as jonke-pj-lldv.bin
To double check the file we will open in the online parser.
Restart (not reboot) CoreELEC so it picks up the new EDID info.
Make sure Use Player Led is enabled
Enable the new Use HDR output for Player Led setting and check out the results (no need for your LLDV converter device, should not be used)
Can add the load command into the autostart.sh if all looking good and want to keep that setup.
One caveat - if you hot plug the HDMI for any reason either physically pulling the plug whilst on or a receiver does it, then need to re-load the EDID again (if in autostart.sh can just reboot to pick up again)
Thanks cpm , i will test this later today and let you know how it goes. Don`t really know exakt source for the exel file other then this post https://www.avsforum.com/posts/62179157/
Ok @cpm up n running . Pj switches to sdr and hdr in automode With the Ezcoo i had to force hdr.
Played som dv web-dl and iso , hdr/hdr10+ and finally som live tv from Tvheadend. Did not see any issues . Good thing was that i could view live tv in sdr without having to flip from hdr to sdr in PJ. But i must say i will change to vs10 for live tv when / if always lldv get fixed. VS10 for live tv looks so much better . But for now i cant stand the black screen delay on ch change.
Will continue to use this build and report any issues or possitive changes .
As always cpm, big thanks for all your work and help when needed.
Yeah this is really for playing DV content (as LLDV) and having it output as HDR for displays without the DV.
Will still need the VS10 to map other content up, and possible down if you want.
Mapping up it will be used in combination for example: SDR content β DV (LLDV) β 12bit HDR for display.
This is amazing work and will be gladly welcomed by the community. However, for this to work, it would require most of these steps to run in the background. I imagine things working something like this
At boot, before Kodi is loaded CoreELEC checks for a file called edid.conf.in .config and also on the root of the flash drive
If it finds the EDID file, it loads it otherwise proceed as normal.
In the CoreELEC settings, there will be a new setting called Enable LLDV which will be visible only if the connected display does not support LLDV or DV.
By default, the setting will be disabled.
When a user enables the setting, it will read the current EDID to a temp file and then modify it using edid-decode. Since edid-decode is written for linux, it should add it as a library. Then, the new EDID will be saved as edid.conf in .config and the user will be prompted to reboot CoreELEC.
If the setting is disabled, edid.conf will be deleted.
In the future, once this feature is done, then a display check can be added
When Kodi is loaded, it should check if the edid file exists and then check to make sure that the display is the same. If not, the user should be prompted to disable and then reenable the Enable EDID setting to update them to the new display, There should also be an option to Ignore Once and Ignore Forever in case the user prefers to use an EDID file that does not match their display.
No need for the restart of kodi if all done in the autostart.sh before kodi starts.
The kernel will just pick up because it is loaded there.
And Kodi will look at the settings from the kernel when it starts.
This really solves for two cases.
Non-DV Display giving them effective LLDV capability, similar to HD Fury / EZCOO
VS10 cannot map down to HDR correctly without this, and probably better quality to SDR10, SDR8 with it as well, obviously cannot map up to DV without it on a non-DV display (But all this needs quality testing to see what the real differences are) Not withstanding that VS10 mapping down from DV to HDR10 probably becomes moot anyway with the LLDV output as 12Bit HDR.
Regarding you comments on making it integrated - yes as previously mentioned two elements would make it better:
Inject just the Dolby VSVDB into the current edid (probably needs to check to make sure one is not already present or maybe replace that as an option for correcting issues with certain displays) - edid-decode would be one approach to investigate.
On hot-plug re-apply the Dolby VSVDB - kodi in that case I think would be fine (no restart needed) as already thinks itβs there and only really checks on start up.
Agreed there are lots of checks that could be put in place and arrangement of settings etc. I would say that is pretty trivial to implement, but first need to see if things work and working well - which is what my builds are all about exploring the possibilities.
The bigger issue for most will be matching Dolby VSVDB settings to their display as this is likely beyond most peoples knowledge.
Also my impression is the CE Team would not want to integrate this for the complexity reasons, but it is there and maybe they will take it on, source will be available and can let anyone who is interested know what I have changed.
Congratulations to you, itβs working. DV is converted to full HDR and output from PQ0 while tonemapping to match the TVβs edid capabilities, using both minPQ and MaxPQ from EDID. This helps to get around the CM2.9 problem where dark shades disappear.
But now I need to think how to automatically add only the DV part.
Because for example if we add the edid from a TV with DV, and the user has a receiver, when the receiver is turned on, it substitutes the TV edid by adding its own strings, so if the user sometimes only turns on the TV without the receiver, we need to use the TV edid, and when the receiver and TV are on, we need to load the receiver part as well. The receiver usually changes the data about supported frequencies and sound. So you need to automate the process somehow.
Anyway, this is a great result, if CM4.0 would work in this mode too Dreams-dreams.
Congratulations again, a little later Iβll check what happens with the color, because the color parameters of the white point should be loaded from your TV.
I would guess that the only way the receiver could alter the edid and have it recognised by the connected device would be a hot plug event, eg. It pulling the HDMI connection pin down and then up.
Left Ugoos on , shut down receiver and pj for a few hours and when i started them again .β Edid was lost β / wrong colors on dv file . Had to reboot Ugoos and enable playerled again to get all working so i guess @DMDreview is right .
Will look again if it was a one off or the same thing happens
@cpm is 12 bit YUV 444 correct output for this build ? I get that on all files
Had some issues after a lot of testing .
On 2 files i had a blackscreen / no hdmi signal and after that i lost dolby vision. Had to reboot CE , restart Kodi did not help .
This happened randomly . The 2 files played fine before and played fine again once ce was rebooted.
Almost certain that would be a hot plug event, when the device comes back on and negotiates the connection on the hdmi and gets a new edit wiping out the one we load.
If it is not a hot plug event then not sure if could automate and only option would be maybe for kodi to check and reload on resume or maybe always load on playing a dolby track.
There could also be other options to get the VSVDB data into the right parts of the logic. Currently using the edid as the easiest approach to test with.
Ultimately changing the edid may not be the best approach, I took it as the easiest way in to test getting the VSVDB metadata into the dv processing, but maybe another way is more robust, it is what it is currently for testing at this point.
Need to understand things like V0 vs V1 vs V2 VSVDB should we just use V2, is that always good?