I can confirm now that I reproduce a similar issue. It stays for few videos with everything at 0 and suddenly it is at pq1000/0.05 on every file. On reboot it goes back to pq0/0
Will do a build coded to the spec you saw, rather than trying to leverage other elements in AMLogic code, which may vary.
Will create the HDMI packet explicitly as per your msg (at least try to):
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.000000 y=0.000000, G: x=0.000000 y=0.000000, B: x=0.000000 y=0.000000, White point: x=0.000000 y=0.000000
Mastering display luminance : min: 0.0000 cd/m2, max: 0 cd/m2
Thanks for the feedback on the parameter, will permanently remove - in the case of always on DV we now actually need to change the graphics mode luminance max for the menus (when no video is playing). If I recall correctly it defaults max to 350 cd/m2 and I brought it down to 100 cd/m2.
1 Like
OK that is more worrying - not sure why it would switch after a while - as per reply to DMDreview one code change was missed on my tidy up will add back, and post a build later.
Could you go back to the prior working version and see if you can reproduce or always good?
Edit: Will try and code up a more direct HDMI Packet creation for the HDR PQ0 case - not leverage existing code which may vary sometimes.
1 Like
ah yeah - probably back to the old issue of kodi and AMLogic not playing well together on mode switch.
kodi should wait for the VSIF packet being set before it does itās mode switch so the logic know it is DV and does it correctly.
Portisch added a delay to the kodi switching by proxy of the content playing (and hence would have setup the VSIF already) and then doing the mode switch, though cannot do that here if moving from play back to menu, so would need another way.
I am also speculating at this point the resume from suspend is another issue, though could be the same problem.
Is is proving useful - less mode switching?
Mmm maybe it could work in ānot-8bit-tunneling-DVā TV-Led mode ? FEL is still applied before being transmitted in this mode, no ?
Anyway, what you want to do is interesting power-user experimentation but Itās a little bit worrying that DV metadata wonāt be processed (if Iām not mistaken) so you loose some of āintentā from the movie production and you replace it with an absolute DTM.
I guess HDR10 metadata is processed by MadVR DTM ? (I guess itās also processed by VS10 engine when converted to DV per my experimentation, but not 100% sure)
Please correct me if Iām wrong.
What is great with VS10 + VSVDB injection (in player-led mode) is that you get :
- HDR10 metadata processed (I guess ) and improved with DV proprietary tone-mapping algorithms
- You can still fine-tune tone-mapping through VSVDB injection per your screen specs (please watch your movies in dark room)
- You keep DV metadata being processed
- Improved SDR (itās a matter of taste, but with modern BT2020 SDR10 movies itās working really really well)
Yes composition of the BL and FEL layers for p7 is done on the device in all cases to form the 12bit video data.
For tv-led the RPU is transmitted to the display either encoded into the image to be extracted at the display and applied, or just sent as EMP side metadata (a capability of the latest DV implementation) - though for the later case not yet come across a device and display pair which actually does that.
One thing I want to get to the bottom of is the colour space used here, and also relevant to your post:
-
tv-led from what I read it is ICtCp (ITP) in the same structure as YCbCr (YUV) [then just labelled as RGB for transmission over HDMI]. Thus a DV display can just go from ITP ā RGB to drive the image (though what really happens in the display is another matter!)
- One conversion from ITP ā RGB (on display) [putting aside the storage format for now]
-
player-led though is already converted and just sent as YCbCr (YUV). The display then does YUV ā RGB to drive the image.
- Two conversions ITP ā YUV (on device) ā RGB (on display).
Thus not sure could use tv-led for @danbezās idea.
Maybe someone with a low level capable capture device can confirm the ITP case I am 95% sure but cannot capture myself. p5 is similar it is a newer version of ICtCp - hence a lot of players get the colours wrong.
Yes no more long waiting time when zap live tv . The Epson ls12000 is not fast with out lldv.
Much needed setting, thanks again.
1 Like
If the conversion from ITP/p5 to YUV is a standard color space conversion, this could be done by using the conversion in the hdmitx hardware - which we can set the conversion coefficients for.
As far as I can tell, this csc in the hdmitx module is the absolutely last processing that happens to a signal before transmission, so it would be converting the 12-bit signal that already has the BL and EL layer combined as you were after.
The captures from @DMDreview for tv-led all had data in the ICtCp /(ITP) color space. The captures I looked at were p5, p7 FEL, and p8. Unclear why for p8 though - it doesnāt seem needed to convert it to this format in the first place - maybe this could be disabled?.
1 Like
Thanks Phil. For my case, I only really care about the proper use of the FEL layer. All other DV goodness (such as dynamic tone mapping), wonāt be of any use to me as I prefer to rely on MadVR dynamic tone mapping capabilities. Note this is the same scenario for anyone who is using Lumagen/Envy as well.
Why do I prefer Envy/Lumagen/MadVR vs the standard DV tone mapping? Because with those Video Processors I have better control of how the tone mapping will be handled, resulting in a possibly better image:
- I can precisely define what is my max nits. I believe with DV we have a few ranges, and one is chosen based on my declared max luminosity.
- They also provide scene-based tone mapping, just like DV but with more control over the curves used, etc.
- I can define a custom gamut, so the tone mapping can be done with my exact gamut coverage. For example, on my JVC I get 97-98% of P3 space. With MadVR, I define the exact gamut coordinates and the tonemapping is then tailored according to it.
But all that is FYI, and I donāt want to create a diversion on the main topic. All I am seeking is a confirmation if I can use Player Led, with no VS10, and consume the proper image (with FEL included) but with zero tone mapping applied.
@cpm - as FYI - Lumagen/Envy/MadVR are not compatible with ICtCp, so I must use a Player led scenario.
Yes, the feature is not enabled by default. Itās an optional feature.
One approach you could look into is removing the RPU data or probably more realistically replacing the existing RPU data with some fixed unchanging alternative in the source mkv etc. I think that could be much easier to do and allow tests to check the result is the improvement you expect over DV RPU, if the results were good could theoretically do similar in code down the road.
From what I gather about DV it will interpolate from the ranges available to fit the displays luminance capabilities to get a final adjustment.
The version from the 25th works correctly, always PQ0. Checked again the āUse display luminanceā parameter in the version on the 25th, it definitely has no effect.
Yes, tv-led always output in ITP
Please try this one:
When looking please double check the matrix coefficients, not sure if being set bt.2020nc or bt.2020c - can do another build if wrong.
I think thatās the only solution, remove or ignore RPU to get BL+EL in player led mode. I think there is a command to disable RPU in Dovi unit.
I see. This could trigger brightness problems with titles where the FEL layer makes the image brighter, but perhaps I wouldnāt be affected by this issue if I leave all dynamic tone mapping to MadVR (including scene based peak brightness detection).
I got to a bit more testing on the new build today. It looks like the 12bit issue is only after first boot - if I play a video (or change resolution even), it switches to 8bit and seems to stay that way (and also fixes the wrong colours if they are showing). So this might actually just be a first boot/resume issue.
As far as mode switching time reduction with DV set to āOnā; I didnāt notice much difference when playing movies (maybe a small one), but it made quite a big difference to playing videos through the YouTube plugin - they seem to switch into VS10 much faster than before (was several seconds, now about a second). So Iād say itās a win 
What youtube plugin, how do you get youtube?