I definitely see vertical lines artifacts in 2160p / 10bit videos in the testing1 build.
Also, there is some weird macroblocking and flickering, for instance in the Samsung Wonderland demo in some of the skies - look for the top middle of the screen. Those artifacts are gone when I use the TV internal media player.
I think 1080p content is fine.
My AVR does not like 4:2:2...
Well, it would have been for testing only. In the end I need to think about another solution to get HD audio to the AVR.
OK.
Just a quick update:
Cables are here - critical files play perfectly.
No signal losses anymore. 
I can still retest the old cable if you wish, probably tomorrow.
BTW, would "echo '420,10bit' > /sys/class/amhdmitx/amhdmitx0/attr" or "echo '420,8bit' > /sys/class/amhdmitx/amhdmitx0/attr" work on the testing1 build?
I want to see if I can fool my AVR and passthrough at least a 2160p / 8bit / BT.709 / 23.976fps file...
johngalt you said that exp builds would not have the "vertical lines" artifacts?
Unfortunately I missed downloading the build while it was still up...
Is this version on the server right for testing?:
8.0.2-exp2.tar.gz
The file seems quite small...
I don't see any flicker with "testing1" build (8 or 10bit output). Where am I supposed to look for it?
I am sorry for the confusion.
I just checked and I have the same subtle flicker on the RPi2 as well.
It is different (and more subtle) from what I saw in Krypton MM builds...
Apparently this is triggered by my TV settings on a very low luminance.
On my night setting, the 21 is affected the most, while it is the 18 on the day setting.
Again, sorry for that!
Unfortunately the "testing1" build still has some lower grayscale flicker.
You can use this pattern:
attachment.php?attachmentid=1661825&d=1473909205
...to reproduce it.
IR should work if you update the device tree (place dtb without rename into .update folder as well)
Well, this is embarrassing - I completely missed that there is a new DT...
Also, I'm interested if 4k output works for you on the current cables after a hdmi related change (fixed some 4K AVR compatibility).
Can you explain that change to me? It should not be possible (or advisory) to somehow limit the bandwidth, should it?
They seem to be mostly eliminated in 8.0.2-exp1 :). All future work is going into 8.0.2-exp1 as well.
That sounds good - so we should focus on the new build?
I can start testing right away.
However, I am currently considering if I can use "testing1" as permanent replacement in the meantime, since I'm very annoyed be that flicker...
Is there any drawback compared to the old MM builds?
I don't see banding, but I do see some form of slim vertical stripes which I think are dithering artefacts. I had to walk up to the TV to see those, though
I see those artifacts as well ("8.0.2-testing1").
I am back and ready to continue testing...
I don't have the good cables yet, but I'll get them from the post room tomorrow.
So, I started to look for what I can in "8.0.2-testing1" first.
Observations:
- IR is not working, I thought it should? Or was that another build?
- 8bit is proper 8bit (regular start).
- Switch command to 10bit switches to 10bit.
- Frame skips:
--- Regular boot without command (8bit output mode): no skipped frames within 33 minutes, very promising! (Only two initial skips at video start.)
--- 10bit output mode: 29 minutes played, not a single skip so far - very promising! I will continue testing for a longer time later.
- I have not seen the "lower grayscale flicker" from the MM Krypton builds yet.
- 10bit videos look good in 8bit output mode, no hard banding lines.
Apart from IR not working and UHD testing pending, this seems to be a very good build.
Thank you very much johngalt.
Would you like me to continue testing this build or rather focus on "8.0.2-exp1"?
BTW, I was getting 4-6 frame skips/min on marshmallow with 10bit output and SPMC 16.7.0. I'm also still getting the frame skips here, but closer to 1-2/min. On the 8bit display I got frame skips, but only 2 after ~11min of playback (which from glancing at afl1's thread looks similar to what's current on those builds).
8.0.1l and 8.0.1k-l from afl1, both Nougat Frankenstein builds, were definitely free from frame skips.
I tested those thoroughly, which is why I then changed that thread title to RESOLVED.
Unfortunately they had the 10bit banding...
Since I can't specifically test if this fixed the 10bit only output issue (since the kernel lied), it would be much appreciated if someone with video through an AVR could test.
I just did.
It's still 10bit only...
Triggering 8bit manually does not work either (echo '444,8bit' > /sys/class/amhdmitx/amhdmitx0/attr)...
Just on a side note - the frame skips are still there too. 
As previously announced, I won't be able to continue testing in the next 5 days...
That gives you 5 days to build the holy grail of builds with flawless UHD playback, no frame skips and perfect a/v sync for all audio at all frame rates. 
Kidding of course... But thanks again for your amazing work and I already look forward to continue testing with the new cables next Sunday.
I'm not yet sure, but I didn't intentionally hardcode 10bit output if so. You can run echo '444,8bit' > /sys/class/amhdmitx/amhdmitx0/attr from GUI to get back to stock behavior.
I had actually already tried that as well (via SSH).
It does not work, output is still 10bit (according to AVR).
I also booted into 8.0.2a MM again to make sure there is no other issue, but the AVR shows YCbCr 24bit in that build, as it should.
This is weird.
I just wanted to test if I see the skips on regular 8bit output too...
So I deleted the line (echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr) from autostart.sh and rebooted - AVR still shows YCbCr 30bit!
I checked autostart again and turned the box off completely (removed cable too)...
After booting, it is still 10bit, both with 60fps and 24fps!
Did you hardcode 10bit output in this build?
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.
Sure, I understand!
Build in OP updated. Changelog:
- afl1's late frame patch updated (haven't tested thoroughly at all).
Thank you for including the patch anyways! 
I am testing this build right now.
First observations:
- PlayerDebug looks different, the font changed.
- The refresh rate switch did not work at first boot after the update (video was being output at 60fps). I rebooted and now it's displayed at 23.976fps, as it should.
- The frame skips are not gone. I have seen 6 unprovoked skips within 9 minutes
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
What 4k flicker are you referring to?
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
I am testing now. What is behind this? What does it do?
After just ssh-ing the command, I still have frame skips.
Trying with autostart now...
No... still seeing frame skips. 3 within the first few minutes.
I tested again to make sure, this time with the 10bit command in autostart.sh.
Result: 9 unprovoked frame skips within 7 minutes of playing.
Uploaded a new build in OP.
I started testing the high bitrate Rogue One Blu-ray remux (39mbit/s average video + audio) with the new build this morning (10bit output).
Unfortunately, out of the 11 frame skips within 10 minutes of playing, at least 6 were "unprovoked", i.e. not triggered by me opening the overlay.
dmesg:
gLYN
kodi.log:
Those frame skips were fixed in the original 8.0.1l (last Nougat Frankenstein from kszaq).
You based these builds on that, correct?
Does that mean the skips are triggered by the 10bit output?
Bug report thread for reference:
[RESOLVED] S905X Krypton: Frame skips on high bitrate videos
It looks like a Kodi TS issue because when you put in MKV container, the clip plays fine in Kodi.
Is it possible that Kodi generally "dislikes" the .ts container?
When I tested those high bitrate birds videos, the ones in an .mkv container always ran better - at the same bitrate.
My first (HD only) test results are promising.
- IR is working well.
- 10bit output is working well at 1080p. AVR confirms 30bit.
- The H.264 videos that looked like slow-motion before played perfectly fine with 10bit output.
- Audio seems in sync at 23.976fps (with my usual 175ms adjustment).
- The "lower grayscale flicker" from MM Krypton seems to be gone in this build as well.
- I did not see any skipped frames, but I will do some high bitrate testing lateron to be sure.
