I’ve updated to latest as normal update without fresh install, works no problems.
Yes you can update to cpm’s T6 version from T4A. I did that and it worked fine. No problems. I will try to test the example you are having a problem to see if I get the same problem.
Does the problem occurs at a certain point or as soon as you start the play?
Soon as play starts
@liquidion I clicked on the link but is not a download link. I do not have this video file so unfortunately will not be able to test it.
Updated and confirmed this bug triggers on T6 version
You should ping cpm with the issues you are experiencing to see if he has the time to take a look.
You are onto something. Seems like exactly what I’m experiencing but you’ve explained it much better.
I did a different test to make sure it is not the 60Hz. So I played Gemini Man which is DV 60Hz and it played without any issues. So it seems that the problem is not the 60Hz but the combination of HDR 60Hz converted to DV thru VS10 engine.
Getting a copy of Train Night View to have a look.
Not holding out much hope though as not doing anything different with refresh rate or resolution, but I will check if anything obvious I can see.
On a wider note I have finished all the enhancements I want to test and have a system I am happy with, it will be up to others to take this forward now if the community want to develop the areas I worked on.
7 Likes
Hi @cpm I already tried with a copy (Remux) of “Train Night View” and it worked. Dolby Vision mode got enable and the image and audio play perfectly. Maybe the problems that other users are experiencing could be with their devices or cables. I had handshake problems with 25 FPS. I fixed by changing to a better cable (Zeskit Maya) and connecting my Ugoos AM6+ directly to my LG C9. I haven´t had any problems with your latest build (T6) I tried HDR10, HDR10+ and SDR content to DV. The only “issue” is that the Ugoos AM6+ changes the framerate to 50Hz when 25 FPS content is played.
Thanks to the CoreELEC team and you for all your work.
The bug report is not caused by cables, please reread my post.
It is when GUI refresh rate and resolution matches content, in this case 59.94 and 4K.
1 Like
Thanks, I´ll try it again later. But as far as I remember my GUI was set to the resolution and framerate of the content. I mentioned the cable as a possible cause because I was having the exact same issue you describe and just with changing the cable worked for me, but there´s other reports of the same, this with 25 FPS content.
does your TV support 25fps mode natively? A lot of TVs don’t have it (my Sony X950G doesn’t), but have 50 so the frame-doubling method is used in such cases. Afair there shouldn’t be any motion quality loss for using doubling with 25 or 30 fps.
1 Like
Must be the case on my TV too. For me it´s been perfect as you said, no artifacts or motion problems. But as I mentioned I needed a new cable and the Ugoos AM6+ connected directly to my TV.
With all my other cables and the Ugoos AM6+ connected to my HT-A9 I had black screen and DV mode enable and disable loop with audio cutouts.
With the new cable connected to the HT-A9 I had image but with audio cutouts with the TrueHD track, the DD+ track played fine.
With the new cable connected directly to my TV, 25 FPS HDR10 content converted to DV played perfectly. With the TrueHD track playing without cutouts.
Did some quick tests with Train Night View.
Setup AM6B+ direct to LG E8, with known good HDMI cable.
Set the GUI resolution: 3840x2160 refresh rate: 59.94
Empty Whitelist
DV Mode: On Demand
VS10 For HDR10 → Dolby Vision
Type: Display Led (DV-Std), then get sound and DV logo on TV but not image (note no flicker of DV Logo just on once at start)
Type: Display Led (DV-LL), then get sound and DV logo on TV but not image (note no flicker of DV Logo just on once at start)
Type: Display Led (HDR), looks ok, no issues.
VS10 For HDR10 → SDR
Type: (Any option), looks ok, no issues.
Also tested Type: Display Led (DV-Std) with other GUI resolutions and refresh rates e.g. 3840x2160 refresh rate: 60, then also looks ok, no issues.
Gemini Man with GUI resolution: 3840x2160 refresh rate: 59.94, looks ok, no issues.
Gemini Man is an FEL title - so thinking an additional test with that converted down to P8.1, to further narrow in on the pattern of the issue.
Other useful tests would be using HDR10 at below spec and run through the above testing permutations:
3840x2160 @ 60 fps
1920x1080 @ 59.94 fps
1920x1080 @ 60 fps
From the above can see if the resolution and refresh rate is not changed and using VS10 → Dolby Vision for resolution: 3840x2160 refresh rate: 59.94 then has the issue.
- Any change in GUI then ok
- VS10 HDR10 → SDR then ok
- Player Led (HDR) then ok
- DV FEL content then ok
Player Led (HDR) and Player Led (DV-LL) are almost the same thing only hdmi packet change, hdmi data (video) I think should be identical.
From that and the fact VS10 → SDR is ok, one inference is is the DV logic at the TV does not like going from an SDR signal to a DV signal whilst not changing resolution or refresh rate for the resolution: 3840x2160 refresh rate: 59.94 combo.
But Gemini Man kind puts a rather large hole in that theory as works ok.
I checked the logs everything looked nominal in all tests, no errors or issues being reported and saw nothing out of the ordinary.
There is one difference in the code for DV Content vs VS10, the setting on line 2015 above - maybe this is the diff (I think about 20% chance) if someone wants to take on the challenge and change, compile and test.
Hope that gives some guidance on the issue and helps people going forward for any fix - it now needs to be taken up by the larger community if these features are to continue into the future.
2 Likes
I noticed that bitrate is set incorrectly when playing Train Night View in the incorrect case.
Set GUI to 4K and refresh rate to 59.94. Play train night view to trigger bug
cat /sys/devices/virtual/amhdmitx/amhdmitx0/config
cur_VIC: 353
cur_video_param->VIC=353
VIC: 353 3840x2160p60hz
Colour depth: 12-bit
Colourspace: RGB
Colour range: full
EOTF: DV-Std
YCC colour range: limited
Colourimetry: default
PLL clock: 0xdb1004b9, Vid clock div 0x000a66cc
audio config: on
audio on/off: on
audio source: SPDIF
audio type: L-PCM
audio channel num: 2 channels
audio sample rate: 48kHz
audio sample size: 16bit
3D config: off
With VS10 off it correctly sets:
cur_VIC: 353
cur_video_param->VIC=353
VIC: 353 3840x2160p60hz
Colour depth: 12-bit
Colourspace: YUV420
Colour range: default
EOTF: HDR10
YCC colour range: limited
Colourimetry: BT.2020nc
PLL clock: 0xdb1004b9, Vid clock div 0x000a66cc
audio config: on
audio on/off: on
audio source: SPDIF
audio type: L-PCM
audio channel num: 2 channels
audio sample rate: 48kHz
audio sample size: 16bit
3D config: off
I remember @Portisch fixed the incorrect 12-bit RGB issue when VideoPlayer open is being invoked different ways. Maybe the VS10 conversion on 59.94 content creates an edge case and creates a timing issue where it is setting to 12-bit instead of 8-bit. Will have to dig up that old post.
Interesting observation, the code should trigger a refresh on the Kodi side which ultimately triggers the HDMI mode switch in the kernel - which should correct the the bit depth as now knows it is DV-Std and should not be 12bit.
Maybe something wrong here - if res and refresh rate not changing then maybe not triggering.
Mind you also getting no image with Player Led (DV-LL) which does not do this, so maybe a couple of things going on together.
Yeah The one Portisch had done was on initial refresh being called from VideoPlayer wait for up to 1 sec to get a signal form the kernel side that video was playing (and hence the VSIF Packet was being sent) then let the refresh do it’s thing and trigger the kernel and do the HDMI mode switch and set the bit correctly to 8 bit.
I am doing the same thing but sending out the VSIF packet up front via a kernel side DV Toggle Frame and then call a refresh, so meant to be all set in the correct mode before any video frames are sent, and remove the danger of slow processing / networking etc. and player not playing within the 1 sec. and not missing out any frames from display.
I did some more testing and you´re right. But I found something else, I think maybe is has to do with that specific Hz mode.
Becasue my LG TV on the diagnostic HDMI doagnostics screen shows the TV going to 59.89Hz or 59.84Hz instead of 59.94Hz. I´m not sure if is because of the content, because I disable the “Frame match” feature just to test the 59.94Hz on the UI, and all DV content showed black screen with sound, but the TV reported that was at 59.89Hz or 59.84Hz.
When there´s other framerate selected on the GUI, in the case of the “Train Night View” the TV reports 59.92Hz (when converting to DV). And 59.88Hz when not converting and using HDR10. This info is taken from the HDMI diagnostic screen from the LG OLED C9.
Also, regardless of the mode (HDR10 or DV) when the TV Hz are 59.89 or 59.84 it reports lots of errors on the HDMI diagnostics.
Btw, thanks for the ionfo about the Train Night View, turned to be really good looking content.
If you like that also check out “Eizan Electric Railway in Autumn…”
“Miyako Healing Beach”
“Okinawa - Healing Drone Sightseeing”
and “8K Aerial Night View Tokyo/Yokohama”
All are high-frame rate, HDR and look stunning when upscaled into Dolby Vision. I have not tested the native 8K, HDR10+ content yet, but that will be a good use case to test the P8 conversion.
EDIT: Just tested the HDR10+ to P8 DV conversion on 8k Night View which is HFR as well. Jaw dropping, looks so smooth.
3 Likes