[DEV ONLY][S905/X] 8.0 with "full Nougat" kernel preview builds

x264 and x265 are names of encoder libraries, the corresponding standards are called h.264 and h.265.

Quote from jd17

I can confirm that weirdly, H.264 is extremely buggy, it looks like slow motion.
However, both x264 and x265 seem fine.

Also, a/v is severely out of sync, at least for DTS, DTS-HD and Dolby TrueHD.
All tested videos were 23.976fps, but the async goes far beyond the usual 175ms...

Weird that x264 bitstreams are fine, but other encoders are not. Are you sure that's the only difference?

I don't have sync issues at all (never had them on any build).

Edit: Have you tried disabling HDMI lip sync on your AVR?

Quote from mmpp

My usb MCE remote works fine, btw.

Thanks for the tip!

Quote from mmpp

x264 and x265 are names of encoder libraries, the corresponding standards are called h.264 and h.265.

I know that of course - which is why I said "weirdly".
It does not make sense, but my own x264 encodes play absolutely fine, while untouched H.264 stuff does not.

Normally H.264 = AVC = x264, I have never seen any software being selective about it either, but I am just reporting what I see.
I know that too many reference frames can make a big difference, but the tested H.264 files were "harmless" in that regard: 2 and 4 reference frames are well within the norm.

I don't see anything else being special about these files...
Wait - they have jpg attachments. I'll see if those are the root cause.

Quote from kubrickdave

I don't have sync issues at all (never had them on any build).

Normally I have 175ms on 23.976fps videos which is quite common in Kodi.

Quote

Edit: Have you tried disabling HDMI lip sync on your AVR?

I never had it enabled.
However, it might be possible that the AVR causes the delay due to the 10bit signal?
It is an older model that is not capable of HDMI 2...
I'll see if 8bit vs. 10bit output makes a difference.

10bit output is the rootcause for the weird behavior of those H.264 files.
They play fine on regular 8bit output, but go slow-motion on 10bit output.
Again, my x264 (8bit) encodes are fine with 10bit output.

The attachments do not have an impact.

Maybe I misjudged the delay before and it is only those 175ms... I'll have to do more testing.

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.

AMLogic SOC's do not support Hardware decoding of any 10bit H264 - no matter what Kernel you are using.

So forget about 10bit Anime aka Hi10P aka 10bit H264.

This is not about 10bit AVC!

The files in question are regular 720p and 1080p 8bit AVC stuff, BT.709.

The output is the issue. Those files play perfectly with 8bit output, but look like slowmotion with 10bit output.
The weirdest thing though is, that not all AVC videos are affected.
My own x264 stuff is perfectly fine.

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.

It is intriguing why there is this difference in playback performance. I checked the clips that jd17 has listed and all of them played fine except for the LG OLED Wonders one. I think Kodi has issues with that file. It doesn't play in Kodi on any plaftform.

I tried the echo 444 10bit command at both 2160p and 1080p. It was fine for both resolutions. I also tried some Blu-ray 1:1 rips. I did find 2-3 movies that had issues with DTS-HD audio, but the video playback was OK. I didn't have any issue with the clips koenkooi has provided.

YCbCr 4:2:0 mode is supported under HDMI 2.0 specs for only 4K 50/59.94/60Hz. It seems that Amlogic has issues switching to YCbCr 4:4:4 mode from 4:2:0 mode. I get a blank screen on Android Nougat firmware (M8S Pro) also.

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)

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.

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

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.

Quote from johngalt

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

The clip that I have was downloaded from demo-uhd3d. I don't think that is the original one. It looks like a recode (at least it was processed in a x265 application). The clip does play fine in the Android 4K MoviePlayer app on Amlogic devices and also in Photos & Videos app on the Shield. It looks like a Kodi TS issue because when you put in MKV container, the clip plays fine in Kodi.

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.

Quote from wesk05

It is intriguing why there is this difference in playback performance. I checked the clips that jd17 has listed and all of them played fine...

I am sorry that I caused so much confusion over nothing.
My issues seem to be cable related so everything should be fine once I get the proper cables.

Quote

...except for the LG OLED Wonders one. I think Kodi has issues with that file. It doesn't play in Kodi on any plaftform.

Yes, I can see that this file is an exception.

I will exclude it in future testing.

Unfortunately I will be on a business trip next week and on a stag weekend after that so it'll be a while before I can continue tests with the new cables.

I'm still open to any tests needed until Monday (bank holiday in Germany).


johngalt 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...

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.

Well, MM kernel probably only works good for you because the bandwidth is much lower.
No BT.2020 and only 8bit.

Are you sure the cable you bought is the real deal?
Can you check with another device?

Quote from johngalt

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

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