Does the latest build work on S928?
I believe VS10 was updated in newest SOC as marketing materials refer to it as VS12.
Curious if the existing build can trigger the newer engine to check if SDR → DV has improved.
s928x can’t boot CE-NG. A motivated person(s) would need to port all the cpm changes to CE-NE chunk by chunk.
Anyone able to comment on what the benefits are of running SDR → SDR via the VS10 engine are?
Unknown, potentially SDR8 is played as SDR10, but need an HDFury (?) device to test. Not sure if that info is available in Kodi.
Subtitle language row is missing from playerprocessinfo in cpm.Estuary
I wanted to thank you for solving the HDR InfoFrame issue with P7 FEL in your latest release! It has been working great.
I managed to solve the choppy playback and audio stream going out of sync issues after skipping in FEL playback on the S905x4 (Nokia 8010) by changing some settings. When the issues occured the queues starting having big drops like you described.
The settings were taken from liquidion: [Guide] S922X-J (Ugoos AM6b+) CoreELEC installation and FAQs - #155 by liquidion
I changed the settings->Services->Caching:
- Buffer mode - cache settings to all methods: smb, local, remote, etc (default ignores local playback).
- Read factor - Set 'Adaptive’ readfactor (default is 4x).
- Memory size - Set 64mb cache size.
For network playback I also increased the SMB chunk size to 1Mb in Settings->Services->SMB Client.
1 Like
I tested the LLDV on the Apple TV 4K Gen 2 and the Homatics 4K CoreELEC cpm A4.1 version.
The DV brightness test pattern from this link was played on both players using the LLDV DV Max settings of 4000.
On the left(1st) is the scope image of the ATV4K’s LLDV 4000 output when the input was a DV file mastered at a maximum of 1000 nit (CMv2.9). On the right(2nd) is the scope image with the input being a DV file mastered at a maximum of 4000 nit (CMv4.0). The waveforms look the same, unlike those from Oppo and other Android players. This indicates that increasing the LLDV Max Luminance does not boost the overall image brightness with ATV4K. I also checked the Max 10K and other settings; they all looked the same, with black clipping until 70 in all cases. The CM version (2.9 or 4.0) did not affect the outcome; they appeared the same.
The next images are from the Homatics Box 4K using the cpm’s latest A4.1 CoreELEC build.
As you can see from the above waveform images, the left(1st) image (LLDV Max 4000, 1000 nit mastered DV file in CMv2.9) shows a boosted overall image compared to the right one (LLDV Max 4000, 4000 nit mastered DV file in CMv4.0). Compared to the ATV 4K, the brightness test pattern on the left side appears brighter when viewed with the naked eye, and the black level seems raised, even though the black is not actually raised. (It’s clipped.)
The black level on the right(2nd) image is clipped significantly more than on the ATV4K, which is evident from the bottom center of the Homatics waveform, where the small boxes visible in the Apple TV waveform are missing. The right(2nd) image of the Homatics shows black clipping around 83.
And I wonder if it can be fixed. (Black level clipping and boosted brightness when DV Max Luminace in LLDV’s EDID is higher than MDL.)
I know my Ugoos looks to be CM2.9, do not know about that Homantics though guess you are running the same / similar era dovi.ko.
Would you not expect this with CM2.9 device? You can do TV-Led and the Ugoos at least will then allow the CM4.0 metadata over to the TV and would get the correct results?
For LLDV I think you may need to wait for a 5.15 kernel (possibly 5.4 is ok) and the appropriate dovi.ko and hope it is CM4.0, and run that on more modern SoC to get CM4.0 LLDV output. Then fingers crossed it can also do FEL for the complete package.
In any case not specific to the build I do.
1 Like
You’re adjusting 2 variables at once here: CMv2.9 vs CMv4.0, and a MaxMDL of 1000 nit vs 4000nit.
I would suspect the difference is due to the CMv2.9 vs 4.0 since the Apple TV 4k can correctly process CMv4.0 and the Homatics 4k can only process CMv2.9 (as far as I could tell from online sources).
Also what MinDL (minimum display luminance) was set in the EDID? I have heard of some DV implementations raise black levels when it is set to 0. If it was you can try rerunning the test with the MinDL set to 0.001.
I haven’t had time to test this on the S905x4 (SoC in the Homatics) yet.
Edit . Fixed by reset settings and started over again
Hi
Is hdr10 to lldv option gone? I noticed that my hdr10 iso/mkv always outputs as hdr and not lldv with settings lldv always on, vs10 only and same dolby vsvdb as before.
Hdr10+ is ok as lldv but not hdr10
My priority is LLDV since I use the TV box with a projector and screen.
In the case of LLDV, I think black clipping is inevitable. I’ve observed the same clipping on most players, like the Oppo 203, Panasonic UB820, Shield TV, and Apple TV, so I can accept it (maybe due to a poor Dolby Vision CMv2.9 algorithm?). However, I wish the boosted brightness could be fixed when the TV’s max brightness is higher than the MDL of the video.
The video below explains the issues I saw.
I’ve omitted comments about additional tests regarding CMv2.9 and v4.0, so it does not mean I adjusted two variables at once.
When playing CMv2.9 brightness test patterns on Apple TV, you don’t see a difference compared to CMv4.0. I disagree with R3S3T_9999’s opinion that CMv4.0 can fix the black clipping issues when it comes to LLDV. However, I noticed that TV-led DV performs better with CMv4.0 than CMv2.9.
No, MinDL 0.001 does not fix it. You can try it too. As I mentioned, I’m more interested in fixing the boosted brightness in a 4000+ nits environment for PQ1000-based videos rather than the black clipping.
The content too has to be cmv4.0… If you play cmv2.9 content on cmv4.0 hardware the SM pattern will still be clipped. I don’t have lldv cmv4.0 devices to test this anymore but this is 100% true in TV-LED and I replicated this issue on 2 different display(Lg and hisense) and 2 players (ugoos and shield)
PQ 20 (0.001 nits) for LLDV MinDL does improve the black clipping on my Ugoos AM6B+ to around 70 which is much better than using the 0 nits option. It does not goes down all the way to 64 since that is currently a limitation on LLDV but then again much better than using 0 nits. So I am interested if this is a problem with the Homatics/SoC.
just to confirm, to improve the black clipping one doesn’t have to override MinDL in VSVDB if TV already reports such value via EDID (Target Min PQ v2: 20 (0.00064354 cd/m^2)), right?
Correct, if the TV reports PQ 20 then no need to override. For example I think the LG C2 already reports PQ 20 so no need to change for that TV.
2 Likes
thanks, my oldish Sony X950G with the latest update also reports PQ20 (don’t know if it always so, only recently moved to CE and took interest in the DV topics).
Yes. That’s true. With TV-Led, CMv4.0 works (black level 70) good but not with LLDV. (My point here is boosted brightness in case of LLDV since I gave up on the black clipping.)
The LLDV MinDL PQ 20 (0.001 nits) improvement for black clipping over 0 nits works in a good number of player devices for improving black clipping. Some devices have corrected this problem through firmware upgrades and now have the 0 nit working at the same level as the 0.001 nits option (not better just the same) which is for the majority of the devices around 70. With 0 nits some devices have black clipping as high as 94.
1 Like
If I remember I correctly(it was a long time ago) I tested this on the Shield LLDV and it was the same behavior. I just remembered that I still have a Firestick somewhere in my house. I’ll check it out tonight when I get home. Anyway, this black crush issue is a very minor issue with real content (1000nits). It looks very bad on the SM 10 000nits pattern but not a single movie has a 10k RPU, dolby official generator doesn’t even allow it. I wouldn’t never use anything but 0 for the min_pq value regardless of the black crush.