@cpm, welcome back and great updates. Thank you! Hope you enjoyed your time off.
Just checking/confirming with you that the HDR InfoFrame field starting on version T2 (and now with version T3) takes a Little Endian string per CTA standard (as HDFury)? After you confirm I will update the spreadsheet to remove the temporary Big Endian tab since it is no longer needed and only used for the T1 version and it can create some confusion in the future.
As a suggestion - If the HDR InfoFrame is disabled (or with incorrect number of characters as you outlined) I would recommend the HDR InfoFrame string to have values in sync (the same as) with the VSVDB string - such as values for ColorSpace and Min and Max Display Luminance. For the values that are not in the VSVDB string you can leave as all zeroes (by CTA standard defined as āunknownā) - such as the values for White Point and MaxCLL and MaxFALL which then the display will use its default values.
Thatās what I understand, I have just implemented a byte order swap (change of endian) for each 16 bit value. i.e. ABCD becomes CDAB (each hex value represents 4 bits so two hex values together represent a byte [8 bits])
The easiest/simplest (read one which may get done :)) approach would likely be, if both Dolby VSVDB and HDR InfroFrame are enabled then changes to the colour space, and min and max luminance override the string for both - probably requires a little UI reshuffling as settings are then applicable to both.
If either was not enabled then the string would only change for the one enabled, neither enabled then donāt show the settings.
In that case would need the equivalent HDR InfoFrame hex values for each of the values of the colour space, and steps in the min and max luminance.
So only the case when the user is making changes in the UI would they be in sync - i.e. not going to reverse an existing string and covert to the other, not least because technically can still put in a Dolby VSVDB V1 format it you want.
Just to set expectations, my focus is elsewhere - currently on projects outside CE, and any remaining CE focus will be working on HDR10+ > DV P8, will come back to this when time permits.
Toggle the other options on and off.Not sure which one but there seems to be an issue where one of the flags is set wrong unless the option is refreshed manually causing that.I faced the issue of no DV as well till that.
Is there a known issue with screen tearing on gui?I was playing a dv tv show yesterday and was scrolling through the gui for the next episode when I noticed that.Donāt think Iāve noticed it on the main build
edit:tearing in gui only seems visible when content is playing at higher framerate such as 60hz.So could have been part of the main build as well.
thatās right when toggled all off the dv back. so, what is useful if turn off all the options? we thought these options would give us more DV advance.
You can set your conversion priorities as you like.The recommended setting by @Astrotrain ensures native matching of HDR formats without any conversion.
Appreciate the enthusiasm and thinking how to make it better, also need to factor in this is just a test / personal build and things will probably change over time not least when any gets integrated with the CE main-line, and could be very different.
I have not investigated but I am guessing you probably can edit the string values directory on the device so can make changes and try yourself what it looks like and share will others for a consensus for integration to main-line, i.e. no need to do a build.
That said - below is more details to help clarify some points and choices on the UI.
First off there is a bug in Kodi with sections dividers and visibility(enable/disable), so I would have preferred to split out into more sections but the bug makes that not possible hence all under the one Dolby Vision heading - it does though use indentation (parenting) to help give more visual context.
The output is a combination of the Mode and Type - better all under an output heading but not possible currently
I preferred Off because DV is not possible on some devices and disabled more implied it could be enabled than off does to me.
Always On is slightly incorrect as can switch off via VS10 for content playing - difficult to come up with good wording for that so just used On, i.e. On expect when itās not lol.
More verbose explain is good - what is currently there is just what I added when I created it :).
Technically the setting is not explicitly setting BT.709 but probably that is always the outcome as a fall back in amlogic code- so maybe can just change to this is proven no other outcome is possible.
For standard I have little preference, but some may view others like BT.2020 as āStandardā (Dolby specify to use BT.2020 in their SoC documentation recommendations! for example) and some devices do this, so stayed away from such labels and just labeled what they functionally do.
This does two things either inject a VSVDB if one is not present or override if one is already present from the EDID.
For the override case it is not just applicable to Player Led (HDR) but all modes, hence not limited to that type.
Cannot remember my take on this, may have thought this also could be applicable in some scenario for all modes, but I think I already did limit it to only visible when in Player Led (HDR)? - maybe I did not or it is not working?
Need to also consider this string is now built by the UI CS, Max and Max lum, but can still set your own value, again not just for Player Led (HDR).
As above it is also applicable to other modes, though most likely use case is for Player Led (HDR).
Closing thoughts, my view on settings is they should be open as possible and allow the combinations if they are advanced / expert - as there is an expectation that you know what you are doing for pro-consumers and up, should be a separate set of dumbed down settings for those who are just consumers.
Obviously if setting combinations are just not applicable then effort should be made to not allow that combination.
The abilities of the Kodi UI though make this hard to achieve and manage and as this is really for the enthusiast if you do not understand then the burden is on the user to learn in this case - you get out what you put in, not withstanding that longer explanations will though be helpful to anyone.
