Ah yeah sorry got muddled up colour and brightness.
Odd though that Display Led and Player Led (HDR) ne Player Led for VSVDB would have any big difference - all three modes on my display look extremely close.
As your TV already has a VSVDB no need to enter one, the Player Led (HDR) will just trigger CE into sending an HDR metadata signal rather the DV-LL.
For the mystery change in EDID cron sounds like a plan until can track down the root cause, FYI this load and save are just part of AMLogic and available in all versions of CE just needed to work out how to use it.
P.S. If really cannot get to the bottom of why the colours are off on Display Led then probably can think about how to add more permutations under the VS10 parameters like VS10 For SDR ā Dolby Vision / Dolby Vision (HDR) etc.
Just need a sensible way so people understand what it all means!
So as to not effect more DV content and using Display Led (DV-Std)
Ah just noticed I set it Display Led (DV-STD) all upper case - need to correct for next build.
Thanks again.
Its works awesome.
The last nightly has the GUI peak luminance in HDR PQ mode settings. For gui elements and for the subtitles.
Its working fine in HDR and DV sources. (The HLG untouched.)
The settings cannot apply, when Dolby Vision VS10 target mode for SDR content set to Dolby Vision mode?
It could be done to accommodate VS10 and looking at the PR possibly would need a change for Player Led (HDR) as well.
I think though to wait for how the CE team implement what they are cooking for the DV VS10, I would guess at this point they will do two settings an up mapping from SDR/HDR to DV and have an always on DV option.
Baked in the stability parameter change - as not seeing any issues and definitely very stable for me not had any problems so far.
iso DV should now work in Player Led (HDR) with a VSVDB - though donāt have an iso to test with, guess I will create one.
Had a go at adding HLG HDR and VS10 to the GUI luminance so not too bright in HDR / DV etc content, has some corner cases but covers most now.
Tidied up the code behind the scenes it should perform the same but as always be on the look out for bugs if testing.
Need to look into limiting some invalid option combinations on the kodi ui mainly for the spinner options like removing Player Led (DV-LL) and Display Led (DV-Std) when the Display cannot do - I see one way of doing which looks a little involved but just want to check anyone have experience in doing this type of thing and can point to some code?
Bravo ! this is wonderful ! thanks again.
Also interesting to point out that DV Player-LED HDR is a very versatile/smart solution for everyone having DV-incompatible hardware such as old AVRs, Samsung TVs, HDR-only projectorsā¦
With this last release I got darken gui and subtitles.
Canāt find where to change itā¦?
Any directions as its a bit too dark for me.
And white subtitles I choose looks gray as hell
FYI May want to hold off for now will have another build a bit later on - fixing some behind the scenes stuff mainly, not affecting the picture quality just performance enhancement.
Changed the Dolby VSVDB to only accept the payload element of only V1 and V2 Dolby VSVDB - allows for simpler code avoiding a couple of pitfalls I cannot test fully for.
Only the payload should be specified.
If you have a Dolby VSVDB in the UI already you will need to change it for this version.
Remove the first 10 characters (in bold below) from your existing entry - for example:
Existing: EB0146D000490348A15855A2
Replace with: 490348A15855A2
This should now always be exactly 14 characters long - that and other checks are in the logic but not checked at the UI level.
Limited the Dolby Vision type UI selection according to connected display (mostly)
Display Led (DV-Std) [Available when CE says the display is DV capable]
I think there is likely a corner-case with old Sony TV which only do Player Led - needs a better differentiator in CE.
Player Led (DV-LL) [Available when CE says the display is DV Low Latency capable]
Player Led (HDR) [Available regardless of the display capability - but should really check it is HDR capable]
Fixed defect - playing original content e.g. HLG HDR without using VS10 - i.e. want the original HLG, it played incorrect as SDR in that situation.
Fixed defect in Dolby VSVDB - memory allocation issue - was not causing a visible problem but filling log and would cause some additional CPU usage - side stepped by using a different technique.
Fixed defect in Player Led (HDR) - it was frequently re-creating the DV metadata parser (looks on each change of the RPU) - because that bit of code thought a HDR output signal meant it no longer needed it, this is now corrected - probably not even noticeable on CPU usage but better anyway. Edit: This may have just been because of a bad mkv need to check more later, if so can revert this element as would not be needed.
General code improvements to reuse more - to reduce footprint of change.
Whilst checking on some of the above it looks to me that even though the HLG HDR is āworkingā with VS10 and we get DV output etc. it looks internally to me that it takes the HLG HDR as SDR and then converts to DV, I tried to force it into going HLG HDR ā DV but got a green screen. It looks like this maybe a limitation on the SoC level I think some later TV SoC can handle more correctly likely on a later revision of DV.
Not done too much testing on this version yet, put it out as will be away for a time, please revert back to previous versions if you find a show-stopper.
great build @cpm cpm , no issues noted, no crash, no freezes. Auto hdr/sdr on PJ ok.
Just so i understand this build ( player led hdr) takes dv and maps to HDR and this is better then to use lldv with Ezcoo ?
Theorically it should be exactly the same. Ezcoo adapter allows LLDV by injecting a VSVDB block through HDMI EDID and sends HDR flag to the TV/Projector. Thatās quite exactly the same here although VSVDB is not exactly injected through EDID injection (if I understood correctly)
Thanks to cpm you can as well tweak your VSVDB string as itās comprised of colors primaries and luminance values supported by your TV/Projector. I donāt know if Ezcoo adapter allows that. Above in the thread there are sites to build the VSVDB string (I think)
I will test i a few days , should be easy now that i have 2 Ugoos (one i HT and one in living room)
Just switch hdmi input and play same file.
Iāll let you know guys
Mainly those tools are for building/managing a complete EDID.
The above repo has spreadsheets to build custom EDID for projectors (looks like mainly was done for EZCOO).
Anyway it has a nice breakdown of building up Dolby VSVDB (V2) and changing the parameters.
I have tried to pull that element out into a simpler excel spreadsheet, this was done on a mac with an older version of Excel - so needed to change XLOOKUP to VLOOKUP but I think it should be good:
Note needs VB Code (Macros) enabled to do some custom calcs, probably can hard code but leaving for now as no time to check.
Correct - not changing the EDID, but adding (injecting) the VSVDB information more directly into the video processing specifically the dv_info in vout which would have previously been populated from the VSVDB in the EDID at an earlier stage.
New DV UI settings layout, as quite a few options now and was having a go at breaking them into categories. As part of this I also changed some underlying identifiers for the setting which I had not appreciated at the time means the previous settings get wiped! - so apologies you will need to setup your DV settings again in the UI.
Rebased on latest CoreELEC 21.1
Faster return to UI from playing content - removed unnecessary work around code that is no longer needed after finding the better way for overall stability.
Reverted code for issue on Player Led (HDR) metadata parser - this was a red herring - from a problematic mkv used in my testing, and issue was happening and causing a variety of problems in all DV modes.
Changed the Dolby VSVDB to only accept the payload element of only V1 and V2 Dolby VSVDB - allows for simpler code avoiding a couple of pitfalls I cannot test fully for.
practicality may also be another consideration if no preference.