New version A3.1 with new Estuary skin for this build:
I have removed the HDFury from the chain and checked the HDR InfoFrame using the commands you proposed. Note that I also updated to the A3.1 version.
I played a Dolby Vision P8, P7 MEL and P7 FEl file with the following results:
It seems that /sys/module/amdolby_vision/parameters/dolby_vision_hdr_payload is set to the same value for each file.
For the P8 and P7 MEL file the primaries, white_point, luminance, max_content, and maxx_frame_average are set to the values I want.
For the P7 FEL file all the aforementioned values are set to 0. I also noticed the FEL playback being choppy sometimes. I am not sure if this is because the Nokia 8010 cannot handle the high bitrates or if there is something else going on.
Any ideas what is causing this?
Relevant log files:
p8-hdmi-pkt.log (4.8 KB)
p8-dv-params.log (2.9 KB)
p7-mel-hdmi-pkt.log (4.8 KB)
p7-mel-dv-params.log (2.9 KB)
p7-fel-hdmi-pkt.log (4.7 KB)
p7-fel-dv-params.log (2.9 KB)
Note that all the dv-params files are identical and the p8 and p7-mel log files are identical.
I think you p7 fel dv params log did not upload correctly, copy of dv8?
I can though see on your dv8 hdmi it is being set in the hdmi out:
metadata_id: static metadata
primaries:
8500, 39850,
6550, 2300,
35400, 14600,
white_point: 15635, 16450,
luminance: 1000, 0,
max_content: 1000
max_frame_average: 200
and not in the p7 FEL:
metadata_id: static metadata
primaries:
0, 0,
0, 0,
0, 0,
white_point: 0, 0,
luminance: 0, 0,
max_content: 0
max_frame_average: 0
which at the moment is a real head scratcher, just want to confirm it was set in the dv params if you donât mind having another go at uploading that for the p7 fel example.
Most of the work should be being done in hardware, though would think the S905X4 is capable enough though it is different - need others to chip in with experience with the SoC. One possible crumb was the DRAM clock was set lower frequency.
In this version A3.1 the local library update function under Kodi no longer works.
I went back to version A2
itâs easy just drop the A2 in update folder then will fallback to previous version.
@cpm with assumption that you made new âskin.cpm.estuaryâ, thank you very much for it, I like itâs âDialogPlayerProcessInfoâ layout and informativeness; nice touch with color for FEL
One thing that interests me is in line: Dolby Vision: Profile 7,6 FEL (----.07.06) , what do the 4 ---- stand for? If for nothing, can they be omitted?
The 4 ---- should actually be dvhe. I thinkâŚ
It would look like this when complete.
dvhe.07.06
Yes I created based of the ideas from others here plus it helps provide examples of using new properties away form the built in skin which I decided to leave alone (avoid future merging issues etc.). It is based mainly on work from @frodo19 with ideas from @jamal2367 like the MEL/FEL colour.
----.07.06 as jamal2367 points our should have a dv fourCC on the front just it seems we rarely have the codec tag to get it from so output the ---- placeholder for formatting consistency, interesting to see what we get over time, I have seen it filled in sometimes.
Not the 06 here is the level ID (e.g. pixel rate)
In contrast the The Profile 7.6 - the 6 in this case indicated the Base Layer (BL) compatibility i.e. 6 Blu-Ray.
Dolby Vision codec string
In different use cases, the profile strings and level IDs are presented in different formats for signaling
Dolby Vision specific information.
For example, the Dolby Vision codec string is composed in this pattern:
[Dolby_Vision_Profile_String].[Dolby_Vision_Level_ID]
For detailed information, refer to the Dolby Vision profile strings and Dolby Vision level ID sections.
Codec string examples:
⢠dvav.09.04
This string represents a single-layer SDR backward-compatible Dolby Vision stream encoded as 8-bit AVC video with a pixel rate that does not exceed 62,208,000 pixels/second (for example, 1920 Ă 1080 at 30 fps).
⢠dvhe.05.07
This string represents a single-layer noncompatible Dolby Vision stream encoded as 10-bit HEVC video with a pixel rate that does not exceed 248,832,000 pixels/second (for example, 3840 Ă 2160 at 30 fps).
⢠dvhe.07.06
This string represents a dual-layer Blu-ray HDR10 compatible Dolby Vision stream encoded as 10-bit HEVC video with a pixel rate that does not exceed 299,065,600 pixels/second (for example, 3840 Ă 2160 at 24 fps).
⢠dvhe.08.10
This string represents a single-layer backward-compatible Dolby Vision stream encoded as 10-bit HEVC video with a pixel rate that does not exceed 995,328,000 pixels/second (for example, 3840 Ă 2160 at 120fps).
⢠dvh1.20.10
This string represents a single-layer noncompatible Dolby Vision stream encoded as 10-bit HEVC or HEVC Multiview video with a pixel rate that does not exceed 995,328,000 pixels per second (for example, 3840 Ă 2160 at 120 fps). If the stream is intended for 3D-stereoscopic presentation, the ISO base media file format file will include an L-HEVC configuration box (lhvC), as documented in Dolby Vision Streams Within the ISO Base Media File Format, v2.5 or later.
I just re-checked and the output of grep "" /sys/module/amdolby_vision/parameters/*
is identical during the p8 and p7 (both MEL and FEL) playback.
To make sure the values were changed by the system I played some SDR/HDR10/HDR10+ files where they were different.
I have tried to look at your code and I have a hard time imagining what could be going wrong here. The only wild theory I have is based on the fact that the enhancement layer is a separate video stream. Perhaps you correctly set the HDR InfoFrame when the main video stream is openend but gets overwritten when the enhancement layer video stream is opened???
As for the choppy playback. I have tried several files and it only happens on DV P7 files. At first I thought it was a bandwidth issue since switching from the TrueHD atmos track to dolby digital made the choppiness less frequent. I have tried playback from a fast USB SSD instead of the network with no difference though.
Logs for P8, P7 MEL and P7, FEL playback: p8-dv-params.log (2.9 KB)
Logs for HDR10(+)/SDR playback: hdr10[plus]-sdr-dv-params.log (2.9 KB)
HDMI packet logs:
sdr-hdmi-pkt.log (4.7 KB)
hdr10-hdmi-pkt.log (4.7 KB)
hdr10plus-hdmi-pkt.log (5.3 KB)
p8-hdmi-pkt.log (4.8 KB)
p7-fel-hdmi-pkt.log (4.7 KB)
p8-hdmi-pkt.log (4.8 KB)
I Have another bit of information about the slow-downs. The DV P7 FEL movies only have choppy playback if I resumed the movie (not start it from 0:00) or skip within the movie, not sure if this is related to the CPM release or an issue with FEL on the 905x4 in general.
To elaborate on what I mean by choppy playback:
It looks like the video slows down and speeds up again, as if it tries to catch up. Sometimes the video completely freezes for a few frames, but never more than a fraction of a second. The audio always seems to be slightly out of sync, but the audio is not affected by the slowing down and speeding back up.
What happen, if you install and setup the unpause jumpback addon?
I donât see this issue on my Dune Homatics 4K which uses the same SoC as the Nokia 8010.
Did you try disabling the cache completely? Normally if you have a stable Gbit connection, a cache is not needed. In my experience it can even make things worse.
This is interesting, because I also (on stable 0.5 Gbit connection) have to disable cache completely for better internet streaming performance.
As I understand and see, Kodi keeps some default cache amount (donât know the size) when cache option is disabled, which is enough for my use.
Thanks , changing to âno bufferâ and looks like it fixed the out of sync on resume of P7 iso
As far as I know, the default buffer when no cache is configured is 8 seconds.
Iâve also understood that Team Kodi has been working on changing the cache algorithm recently, but I donât think they nailed it yet. On my Nvidia Shield everything also works better with the cache turned off.
Would be good if someone with a Ugoos can help confirm these findings maybe @OCEFDA can help?
I will also have a go when I get some time to confirm on my Ugoos, but maybe a while before I get to it.
If not missing something / not SoC related difference - and FEL is indeed outputting different HDR InfoFrame metadata then not liking the outlook - feel would not be a simple thing to make work.
Just double checking myself that I have your setup correct - you are using Player Led (HDR) and your device is switching to HDR for the FEL - i.e. indicating the header is set.
If anything it would be indirectly connected, there is separate HEVC decoding for the BL and EL layers, but then combining to a single 12bit stream of video to output over HDMI, would be indirect that it would wipe out the HDR InfoFrame metadata being set.
My devices are setup like this:
Nokia 8010 â Samsung HW-Q990B soundbar â Samsung S95b TV
Dolby Vision is set to âon-demandâ and the TV is switching to HDR when playing dolby in any profile. I have also verified the headers are set by adding an HD Fury Arcana between the Nokia 8010 and Samsung verifies that.
The reason I want to set an Info frame is that Samsung TVs from that era apply a static tone mapping curve on HDR content that have a MaxMDL of >1000 or a MaxMDL of 0. Adding this static tone mapping on top of the player led Dolby Vision tone mapping crushes blacks and dims the highlights.
I will post a screenshot of my Dolby Vision settings later today. (Is there an easy way to screenshot in CoreElec?)
(Is there an easy way to screenshot in CoreElec?)
SSH and **kodi**-send --action="**TakeScreenshot**"
For the proper screenshot, you can creating an autostart.sh file in .config that contains :
echo 3 > /sys/module/amvdec_h265/parameters/double_write_mode
echo 3 > /sys/module/amvdec_vp9/parameters/double_write_mode
/storage/.config
is same as Configfiles
. So place autostart.sh
there.
Youâll need to reboot to apply the changes.
Also you can map one of your remote controller button, in the keymap editor addon, to made a screenshot.
FYI this is function which parses and will output the HDR InfoFrame, from the command given earlier:
cat /sys/kernel/debug/amhdmitx/hdmi_pkt
Can also trace back from this, but not seeing where is sets the registers.
Edit: OK I think they are being set here in the DRM_DB:
So should be being set correctly from the fresh tx hdr packet call.
.fresh_tx_hdr_pkt = hdmitx_set_drm_pkt
So again all looks correct.
Edit:2
Did a test and can confirm see the same behaviour on the Ugoos unfortunately.