New build with all of kszaq's changes from LE8 merged in up to 8.0.1i (current), except the spdif mute commit in kernel is reverted (built before kszaq reset the tree).
This also still has the 2160p 4:4:4 support patch.
LibreELEC-S905.arm-7.0-devel-20170430185848-r23797-g7772046.tar | openload
Here's a new build I did based on kszaq's source after downgrading from LE8 due to 10 bit color (krypton cuts 10 bit color down to 8 bit initially resulting in some noticeable banding with 10 bit sources and other issues).
This is using the current kernel and LE8 changes (up to 8.0.1h + 1 commit) of kszaq's merged into his LE7 branch, including the "always render gui," drain, and audio patches.
This also includes the patch for 2160p 4:4:4 support, so if you've run LE8 prior to 8.0.1h and had 2160p issues with the patch in place, it isn't for you. I can't replicate the reported issues and need this patch for some of my uses, so kept it in.
This is the best picture quality my box has ever had (Krypton definitely has some downfalls for these amlogic devices). Thank you kszaq!
After some testing, I can confirm the earlier report that 10bit output is first cut down to 8 bit on these LE 8 builds, but not on the LE 7 builds. I've unfortunately downgraded to a LE7 build with some of the patch commits from 8 cherry picked.
Could this issue be added to the known issues in OP so others know they can get rid of banding on 10 bit videos by downgrading?
Thanks for responding regarding the flickering issues. I can't reproduce so will continue building for myself with the patch.
I totally understand the revert since given the reported issue it makes sense. Worth noting that with the patch some users could confirm that 4:4:4 was being used from AVR or TV info.
Thank you for the build and support as usual.
What was wrong with 2160p output with the patch to support 4:4:4 output? I haven't had any issues with it on multiple s905x boxes and displays, but also am not sure if I should be looking for something in particular. In topic changelog it says, "...let's see if this fixes 4K for you"
Trying to figure out if I need to wipe the box and start fresh since there's a good chance it's something I did: Is the devel build missing the seek bar while pressing left or right buttons and playing a movie for any of you? I'm able to get the rest of the osd if I press select, but not seek bar.
I have some anime with fractional framerates (720p x265, not sure if 10-bit - but I don't think so) that still won't play right/at all with 8.0.1e (worked fine with 8.0.1a, and IIRC it hasn't worked with any newer version since then).
It's a shame since the menus seem smoother with the newest versions, but they're unusable for me if they cannot play fractional framerate videos correctly (not sure if this is only for x265 videos). My player is a Nexbox A95X (S905X, 2/16GB).
I hope you can find a fix once you get back from wherever
I can't recreate, and actually have improved playback of both fractional and integer framerates on my 1G s905x system. I've tested a variety of x265 and x264 videos (including some 4k stuff).
Can you post a sample and log? Even though kszaq's not here, some of us might be able to help you with more info.
The display calibration "issue" you are seeing is from fractional and integer frame rates switching to the correct refresh rate (so 60.0hz and 59.97hz function correctly now for example). Up until very recently, this wasn't working correctly (ty kszaq!).
However each refresh rate has separate calibration profiles, so calibration must be done for each potential refresh rate. I'm not sure if in the GUI you have the ability to switch between 59.97hz and 60hz for instance, so if not there is a bug there. If so, I wouldn't consider this a bug.
I recommend you leave adjust display refresh rate enabled, and calibrate for each refresh rate in display settings. If you can't select between 59.97 and 60 for instance, you can play one of the fractional 59.97 clips that is "resetting" as you put it, and then while playing hit the back button and calibrate in settings. Do this each time your calibration "resets," and eventually you should have saved calibration for each mode.
I'm sorry I don't have a box in front of me to check the options, but this should work for you.
Edit: NVM, my mistake.
Here's a super simple patch for 4:4:4 support (now boots in 2160p60hz instead of 2160p60hz420, and stays after playing a video): GEBW
Just wget or curl the address, and patch -p1 < GEBW before your build. I'll upload a build with that patch shortly for interested parties.
With refresh rate switching, the colorspace metadata might still be an issue depending on your TV. I have a Samsung KS8000 that allows me to manually set colorspace in HDR mode, and it doesn't affect the SDR mode.
Edit: also, here's my /storage/.config/autostart.sh for s905x (also bumps up gpu clock in first line, delete if you don't want it): HGcQ
I've also set executable bit on the autostart.sh, but not sure if that's required (chmod +x /storage/.config/autostart.sh).
Another edit: here's a build with that patch File not found ;(
Possibly. S905/S905X framebuffer is limited to 1080p for now due to low performance. This doesn't matter for video playback though.
I just now figured that out, thank you :). With patched kodi and initially setting 2160p60hz from platform_init, kodi sets it as the initial max 3840x2160 resolution...and it sticks 4:4:4 when stopping a video.
Follow-up to my previous post
The HDR color space issue seems to be related to this:
If I start an HDR video my TV goes into HDR mode (full brightness, 2084 EOTF), but does not switch to the BT.2020 gamut. I can then back out into the main menu, with the video still running and restart the video by selecting it again. Now the TV does not go into HDR mode, but this time it selects the correct color gamut.
My theory is:
This appears to be a timing bug. The HDMI InfoFrame containing the colorimetry information is emitted before the refresh rate change happens. My TV apparently needs this reversed (as was the case on Marshmallow kernel). If I disable refresh rate switching in the settings, everything works as expected.
kszaq, anything you can do about this?
The 2160p60hz (4:4:4) mode works, when I manually select it using /sys/class/display/mode, but not from Kodi menu, where it chooses 2160p60hz420 (4:2:0). So everytime I exit playback, Kodi automatically switches back to 4:2:0.
On my TV, I'm able to force colorspace and can't tell a difference between them (so I don't believe it's doing a colorspace conversion). I'm working on a fix for the 4:4:4 issue now as a starting place.
Ignore my name, made it before I got the s905x boxes
s905x 1G with a 4k hdr tv, the nougat backport test is overall a big improvement in picture quality: black levels look better (didn't even notice before this), and bitrate starved scenes with crushed blacks aren't as noticeable.
Additionally, my HDR10 material looks better.
I have two (poorly encoded) x265 4k 8bit tv episodes that don't play video at all with 8.0.1b, but that worked on 8.0.1a: black screen if I start from the beginning, or frozen if I attempt to resume from a paused time (also won't seek but audio will keep playing).
Here's ffprobe info for the troublesome episodes: Stream #0:0: Video: hevc (Main), yuv420p(tv), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
I've already replaced the videos with different releases and they playback fine. Additionally, all my other 8bit x265 and 10bit x265 stuff plays back perfectly, so I'm not sure of what the issue is exactly. I can get other logs if requested, or upload and pm one of the videos. Needless to say, I'm going to be sticking with 8.0.1b for a bit
PS: those samples posted earlier playback fine, and I have a large sample folder with 60fps 2160p HDR samples from various vendors that also playback fine (and look awesome). Perhaps that earlier issue is s905x vs s905? Or TV hardware (hdmi caps)?
I have bluetooth headphones that are out of sync by just over half a second. Is there a way to change the audio sync only for the pulseaudio bluetooth device, so I will only need to change audio output in the future?
Disabling it indeed disables HDR but it also causes GUI and subtitles corruption at 1080p24hz.
Understood, I didn't test 1080p24. A lot of hdr material will still suffer bad color conversion with vemc disabled (half the screen will be blocky blacks converted to grey (only if vemc disabled, and not just hdr->sdr mode), which is why I'm trying to go the vemc hdr->sdr/csc route for better conversion using a new matrix.