Posts by johngalt

Quote from [email protected]

Hello,

First of all congrats on your awsome job

I've been testing your dev release with various 4k 10 bits HDR mkv files. BT2020 is sent, and the TV switches to HDR mode.

Without running the "echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr" command, everything works fine except a stuttering on 24p movies (unsure if it's related to this release, will have to check)

With the command, I get nothing, a black screen. My TV a Panasonic 50DX750 is 10 bits compliants and I've got a HDMI 2.0a Amazon cable.

Don't have an AVR which can tell me more precisely what's been send to the TV.

I have a beelink Mini MX3 2 2/16

Display More

Please wait for the output compatibility tests. Thank you for testing. Same to astep

Quote from wrxtasy

LibreELEC.tv/platform_init at nougat-wip · amillogical/LibreELEC.tv · GitHub

Try setting this parameter to 0 and then saving in autostart.sh

echo 0 > /sys/module/amvdec_h264/parameters/dec_control

Thank you, this is a great idea. According to commit history, it was set to fix "BBC H.264 DVB-T." There's a good chance this issue was fixed in the backports, unfortunately I can't test it.

wrxtasy I'm glad to hear it's working out well for you

jd17 I can recreate the frame skips, but haven't compared on 8bit output yet. I won't have a chance to test thoroughly until mid week. The late frame patch update may help, not sure. The next priority for me is 4k output compatibility for users having issues, then I can work on everything else.

koenkooi Thank you for your testing, noted your results. As mentioning below, I should have a hpll test build specifically targeting output issues shortly. Everything other than 444 or rgb has issues with being set through attr. I'm avoiding this for now since it shouldn't be needed when output is solved.

Worth noting I'm also on the fence about the contrast changes backported in a recent build. Like many things amlogic, it's a "double-edged sword" in test videos depending on colorspace (ugh).

Build in OP updated. Changelog:

• Many amports nougat backports (excluding new multi-instance decoding version). Also backported a possible minor bug of video taking 1/4 of the screen for a flash at start of playback.
• afl1's late frame patch updated (haven't tested thoroughly at all).
• Have barely tested, and won't have time until mid-week -- beware, as I hope you are on these builds.

Quote from astep

Used gxbb_p200_2G_minix_neo_u1.dtb from link in OP. Made a fresh install to SD.

BTW: Running 8.0.2a from NAND with no problem.

Did you ever run an 8.0.1x nougat build? Are you at 4k output? You might be one of the affected users of the nougat 4k output compatibility bug (see in OP). I'll have a hpll test build targeted at users with this bug shortly. If you have a spare HDMI cable, I also recommend you try a different cable until we come up with a solution.

Dev note: I found that restoring some hpll registers (frac frame rate support takes some adapting) can bring back marshmallow 4k flicker. If so, you can change the register set sequence to avoid it for the affected clock to avoid it .

I suspect the 4k output compatibility issue is with hpll registers. I'm working on compromising on them without bringing back the 4k flickering, then will have a test build.

Quote from wesk05

I don't think S905X supports Dolby Vision. In the kernel source you will see this:

Code

if (is_meson_gxm_cpu() && is_dolby_vision_on())

S905X/905D is GXL and S912 is GXM.

You're right, it is stuck at 5 (SDR8 output) on anything other than GXM. I got HDR10 with a test file but didn't see it had HDR10 metadata. Thank you, my mistake.

koenkooi It's built with the latter. I forgot to push the LE kernel bump.

Uploaded a new build in OP. Changes:

• Removed "output_rgb" interface completely since it's redundant (see OP).
• h264 dolby vision support (nougat backport)
• Fixed too high of contrast (nougat backport)
• New white balance module (nougat backport)
• A few HDR fixes (nougat backports)
• Added section in OP on dolby vision.

Quote from mmpp

Changed my autostart to this, only 720p50 dvb-s2 stayed problematic. All other files that I tested worked fine.

That's good to hear. The force rgb commits shouldn't be necessary on this kernel with that attr sysfs interface.

Quote from jd17

why do you want to go back to Nougat Frankenstein now? I'm not sure I understand that...
I thought we were on a good path to making full Nougat viable...

I don't want to stop anyone from developing on this full nougat kernel, however my focus is 10 bit output and hdr functionality. Anyway, I already rebased and made the thread.

Reasoning:

• I spent longer debugging at one point because I thought I created an issue that was actually in the dev build as well.

• With fewer issues and more functionality (playback stutters on some files gone and ir remote for instance), we should be able to get more testing done on the topics of 10 bit output, hdr, and dithering support.
• Any improvements in one branch of development can easily be moved to the other.
• It will be easier to see where posted issues are coming from (also true for why a separate thread was created).

I made a new thread specifically for 10 bit/hdr/dithering testing and rebased the work on top of kszaq's partial nougat kernel (8.0.1x nougat releases): [TESTING][S905(X)] 10bit/HDR/Dithering Test Builds & Discussion . The h264 playback issues on 10 bit output are fixed for me there, and it should be an easier base to develop the 10bit/hdr topic on, and we won't create more noise for issues that are specific to the full nougat kernel. If you have output issues here, you'll have them there too.

Quote from RedCat

johngalt I tired ur new build, but no change. Maybe it was worse. 20 times start 4k video, but 16x no signal, 4x film start. I tired rouge one 4k, and planet earth II 4k films. Afternoon I bought a new HDMI 2.0a cable too, but no change.

But with MM kernel (8.0.2a, 8.0.1l-mm) everything is good.

Thank you for your help, I hope we (or u) find the bug.

That's a shame, but I appreciate the testing. I'll look into it a bit further off the build above (that shouldn't fix your issue yet though). I also still need to do a 4:2:0 default build for output testing.

This thread is specifically targeting 10bit output, HDR, and 10-8bit dithering support (fixes the "color banding" issue posted around on nougat krypton builds). This testing started in kszaq 's "full Nougat" kernel preview thread, however developing on top of a kernel with unknown preexisting issues was getting difficult. This work was then rebased on top of kszaq's existing nougat-experiment, but has since moved back to the nougat-wip branch ("full nougat" kernel).

These builds are only possible because of kszaq.

A summary of what was discovered in the "full nougat" thread:

• Output issues may be related to hdmi cable quality, or these devices really aren't made equal. If you have issues, I first recommend trying a higher quality 2.0a cable. If you go through an AVR, also try replacing the cable from your AVR to your TV. We're making progress, so this issue won't be around forever. However, these issues have yet to be fixed, so if you had output issues in the previous 8.0.1x nougat releases, you'll have issues here too.
• We must set display mode to properly pass colorspace changes. As such, kodi is now patched to reset matching display modes: for instance if GUI is at 2160@50, and a bt2020 video is 2160@25, the display will still reset 2160@50 so colorspace is passed.

Issues fixed + changes from earlier krypton nougat 8.0.1x releases (full changelogs posted on download link):

• Colorspace is passed

• Color banding at the default 8 bit output is fixed (dithering enabled).
• Small stuff with 10 bit output fixed (e.g. setting color depth early enough for the 10-8 dithering and rounding checks after LE resolution switching).
• Fixed some 4k output issues some users had with the nougat kernel (improved compatibility).
• Based on kszaq's "full nougat" test kernel.

Known issues:

• Needs more testing

10bit output on capable hardware:

• On a new boot before any other playback has been performed, run the following: echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr
• This only needs to be set once each boot, so it can be put in /storage/.config/autostart.sh
• This shouldn't affect any 8 bit output either and can be set unconditionally (as above).
• Testing has been very limited thus far.

Force RGB:
If you have an older display and needed output_rgb, please use the following instead of the old interface:

echo 'rgb,8bit' > /sys/class/amhdmitx/amhdmitx0/attr

Device Trees (must be updated due to "full nougat" kernel)

^Missing from above: gxl_p230_KI_Pro.dtb provided by @afl1

Download

Kernel Source

LibreELEC Source

Quote from mmpp

johngalt I noticed that the h.264 playback issues that I experienced may well have been caused by the forceRGB switch that I am using. I do not own a 4k or HDR capable display and only tested the playback on SDR FullHD. The only remaining reproducible playback issues are the 720p50 dvb-s2 streams, which was already present in kszaqs dev build.

I had playback issues on the affected files (a few webdl as someone mentioned earlier) on the straight dev build as well, but it's good to know the forceRGB switch may be causing issues. Instead of using the forceRGB switch, could you try the following and see if you still have the reported issues?

On boot before any other playback:

echo 'rgb,8bit' > /sys/class/amhdmitx/amhdmitx0/attr

RedCat, jd17, and others with 4k output issues:

Please test LibreELEC-S905.arm-8.0-devel-20170603103543-r26034-g255d7f24c.img.gz | openload at 8bit (no echo command) if your output issues occur at 8bit as well. Even though it seems to be cable related, I'd like to get a good base for everyone. This isn't targeted at fixing any of the other playback issues, so if you don't have the output problems, there's no need to test this build.

wesk05 there are also issues with detecting display capabilities on older non 2.0 displays on their android nougat firmware that we now share.

Edit: finished the rebase, and the playback stutters I could replicate are fixed on my end. I'll make a thread for 10bit/HDR development and testing shortly with the end goal of PR'ing into kszaq's work.

Edit2: That LG Wonders file is their early HDR spec that will only work on LG displays (and probably never kodi)

After some testing, I've found the original dev build also had some stuttering on the affected files at the "normal" 8bit output. The additional stuttering at 10bit output was due to disabling rounding at 10bit output, which we need for many h264 videos.

I'm going to use this kernel as a base for getting some other issues fixed (such as output on possibly subpar cables), but backport the 10 bit output and dithering changes to the "nougat-experiment" kernel that had been used in multiple releases by kszaq. I'll also create a new thread specifically targeting 10bit output development and testing.

This is getting difficult since not all playback bugs are known on this kernel, and at this point we're probably adding noise to the preexisting bugs with this kernel.

kszaq there are no new bugs (compared to your dev build) that I'm aware of in the nougat-wip branch on GitHub - amillogical/linux-amlogic: the Linux kernel for Amlogic SoC devices for "standard" output. Because I reset the branch back for audio and cec changes, this won't cleanly apply in a PR. If you were to force push over your current nougat-wip branch, this would fix cec, audio, and 10-8bit dithering on 10bit h265.

Thank you everyone for testing. re: 25fps, it's also set at 50hz so not surprising. I'm also glad to hear about the hdmi cable issue.

Regarding h.264 8 bit at 10 bit output, I believe this is due to disabling rounding on 10 bit output. It probably lowers bandwidth significantly with h.264 (that's needed for decoding), but isn't needed with h.265. I'll test with it enabled again, and if playback is smooth again, I'll enable it until we come up with a better solution to check video info.

Before I upload a 4:2:0 test build, I'm going to upload a 2.97Gbps output version that won't switch to 5.94Gbps as often as the current nougat kernel. This should help people with potentially subpar hdmi cables.

Quote from jd17

Interesting.
23.976fps seems to be stable with 4:2:2.
However, 25/50fps still loses the signal right away and 30fps won't play.

Just to make sure, I also tested 4:4:4 again but same result, signal is dropped quickly in the 23.976fps Samsung demo.

I'm thinking this is a bandwidth issue -- either cable, or these boxes really aren't made equal. Within the next day I'll push support for manually specifying 4:2:0 and we can see how it goes.

RedCat could you try running the following on boot and then seeing if you have video at 4k?

echo '422,8bit' > /sys/class/amhdmitx/amhdmitx0/attr

Quote from jd17

It sometimes starts out like the black screens / signal losses we have had for a while now in Krypton.
Video plays, than black screen, then it plays again for a while - but at some point, the signal is completely lost.
Sometimes, it is lost completely right away.

Unfortunately I can't recreate, and I've played that demo clip three times now (looks awesome). I did run into one consistent dropped playback issue on a much higher bitrate 2160p/10bit/bt2020 file that reverting drivers/amlogic/amports/vh265: bump dynamic_buf_margin to 12 · amillogical/linux-amlogic@0022c20 · GitHub fixed however.

When you first boot, could you try echo '422,10bit' > /sys/class/amhdmitx/amhdmitx0/attrinstead of the 444 command and see if you still get the dropped signal?

Btw, I found why we can't do manually set 4:2:0 on this kernel and will reenable support. It shouldn't matter for us, but gives us more options for testing). I'm quite confident I can take this 10 bit support to the MM kernel as well if needed.

Quote from jd17

dmesg:
aiQM

log:
cXJi

I enabled debug logging on the second attempt because of that message:
"cat: can't open '/storage/temp/kodi.log': No such file or directory"
However, it still appeared... But I got a link anyhow, hope that's ok?

I used this one:

EDIT:
Hmm, log link seems empty... What do I do?

Display More

I'm sorry, I had a typo. It's meant to be

cat /storage/.kodi/temp/kodi.log | curl -F 'sprunge=<-' http://sprunge.us

Edit: dmesg is actually good in this case, thank you.

Quote from jd17

Sure, what is the process, do I play a critical video and type those commands in putty while it is playing? Or after?

BTW:
AVR confirms 10bit at least for 1080p.
It says YCbCr 30bit.

After please. Thank you.

jd17

Thank you. I'm getting those demo videos to test, but I'm already concerned I won't be able to recreate (have tested 23.976fps 2160p/bt2020/10bit videos). Could you upload dmesg and kodi.log? After each of the following commands you'll get a link to post here:

dmesg | curl -F 'sprunge=<-' http://sprunge.us

cat /storage/temp/kodi.log | curl -F 'sprunge=<-' http://sprunge.us

Quote from RedCat

johngalt I tired ur build, but no changes Do you have any idea?

I had time today and I tired kszaq dev build (and ur too) 10 times start 4k video: 7x black screen, but 3x start the video normal, there was picture and sound. But later the screen went black and some sec. came back again...

I have some ideas, but saved your logs and haven't had a chance to look into it very far. Sorry, I didn't expect that build to fix your issue.

Edit: updated download link above for dithering issue with 10 bit output