Video signal goes through my AVR, perhaps it affects dc_cap results. I'll try with direct connection to the TV when I get a chance.
Unfortunately, my AVR and TV are almost the same (old) age and they don't display any info beyond a simple resolution so I won't know whether I get 10bit output or not.
I ran the "echo '444,10bit'" command but I didn't see any noticeable difference in picture quality.
Okay, it's probably the AVR. I wouldn't worry about running either command then.
Display MoreI have a 8-years-old Panasonic plasma TV with the following display capabilities:
LibreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/dc_cap
444,10bit
444,8bit
422,10bit
422,8bit
rgb,10bit
rgb,8bitDo I need to issue any of the commands I quoted above?
I don't think dc_cap is reporting correctly for non-4:2:0 modes, but am not sure. If you'd like to try, you could run the first command and play a video to see if you get 10bit output. If you don't get output, reboot.
The rgb command is only needed if you previously had to enable output_rgb. I think the issue was a green tinted screen.
Can you explain that change to me? It should not be possible (or advisory) to somehow limit the bandwidth, should it?
It's actually not a bandwidth change, rather stops a hpll reset from occurring on timeout. I was surprised it worked, but it fixed the 4k nougat output issue for RedCat with a denon AVR.
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?
"testing1" is in a very good state, with no drawbacks that I'm aware of.
Display MoreI just want to say thank you for your work.
I can play the BT.2020 movies with testing1 version with normal contrast and black level now even on my non HDR capable tv.
(My dc_cap is
420,8bit
444,10bit
444,8bit
422,10bit
422,8bit
rgb,10bit
rgb,8bit
)
You're welcome! That dc_cap is interesting (no 10bit 4:2:0 support), what's your TV model?
Done some testing, and the only problem i can see is that the famous frame skip is back for some media.
Also tested setting dc_cap to 444,12bit , and my AVR reports YCbCr444 36Bit and all 8/10 bit looks OK. Haven't tested any 12bit yet, so don't know if it works
Interesting re: 12bit...I doubt it will be able to play 12bit media, but didn't consider 12bit output even working. What types of media are frame skips back on? AVC?
... And the audio is also off by 0.125s
What type of media is audio off on? Also, if you pause it and start it again, is the audio still off? I'll work on bringing in comparable changes to peak3d's I reverted which should fix this behavior.
Display MoreI 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"?
IR should work if you update the device tree (place dtb without rename into .update folder as well) 
. Also, I'm interested if 4k output works for you on the current cables after a hdmi related change (fixed some 4K AVR compatibility).
I see those artifacts as well ("8.0.2-testing1").
They seem to be mostly eliminated in 8.0.2-exp1 :). All future work is going into 8.0.2-exp1 as well.
hello, how can i roll back without tar file for the update folder, must i burn sdcard new and do fresh install?
Your work is great! Thx!
You can place the .img.gz in the update folder just like a tarball
Edit: exp1 removed due to build mistake (built off wrong branches). Sorry, I recommend using "testing1" instead.
Display MoreNexBoxTK:~ # cat /sys/class/amhdmitx/amhdmitx0/dc_cap
420,10bit
420,8bit
444,10bit
444,8bit
422,10bit
422,8bit
rgb,10bit
rgb,8bit
Thank you, it looks good. I've decided to hold off on future builds until I get the full nougat amports and 20170515 merges working correctly (nougat-exp kernel branch), which means there's a bit of work ahead. For now, testing1 seems to be in a very good state.
ps. Not sure if my TV supports 44410bit 50/60hz at 4K, but i know it supports 422 10 & 12 bits at 50/60hz.
To double check this isn't a different issue, could you run the following and post the output here? It doesn't matter which release you run the command on (so it's fine if you're back on testing1) cat /sys/class/amhdmitx/amhdmitx0/dc_cap
My AVR reports;
-YCbCr420 24bit for 4K >= 50hz. (8 bit)
-YCbCr444 30bit for anything else. (10 bit)
Thank you, I believe I found the issue from the merge again. I removed the build until I can fix it and verify. Unfortunately I didn't test >=50hz. For now I recommend testing1.
I just fixed standard audio again and reuploaded testing2. I messed up and only updated the tarball, then wiped the builds clean for a personal agile build. So there will only be a tar up for testing2, and if you need the image, you'll need to wait for testing3, or upgrade from a previous install to testing2.
I don't seem to be getting any audio on the new "8.0.2-testing2" build. I'm just using a regular old HDMI connection straight into my TV (no amp or anything). Testing1 was fine.
Thank you, I definitely broke it in the merge (only tested passthrough audio). Removing the build until I get a chance to fix it.
New build uploaded on github releases page with some changes from the amlogic 20170515 release merged in. A side effect of the updates show an improved HDR->SDR conversion, and I included a bit of info on how to customize the brightness grading for it. Removed build due to broken non-passthrough audio.
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'm not sure what this is from, and I get the same thing on Android also on 10bit output with dithering disabled if I focus on some areas in that video. However, some of my actual test videos don't show it very well.
That's probably it. My TV's internal player does not exhibit banding though. Is dithering supposed to be turned on?
With it on, we're cutting off two bits of color depth and adding noise (which helps with native banding). Your display could have processing that minimizes it, or we're running into a hardware limitation, or it's something else entirely. We should be able to add and customize a bit of noise through am_vecm, but it's not something I've spent much time looking
PS: I changed the default kernel branches. The branch these builds are based on is "amlogic-3.14.y-nougat." The "nougat-exp" branch is very experimental/wip, and full of bugs (currently plays video far too quickly due to PTS changes). WIP and testing stuff will start out in this branch, then move to the main branch.
It appears less severe, but I'm largely going from memory here. I'll do some more testing, when I have time.
Maybe someone else can chime in.
Edit: The gradation is definitely less bad than on the old kszaq builds.
After a bit more testing, I think you're comparing to a build that still had dithering enabled for 10bit output.
I tried it, with 8 bit is all ok, with 10 bit I have no 4k video out
Need more info such as tv and possibly avr, as well as a log (dmesg). If you have a spare hdmi cable laying around, it would be helpful if you could try that as well.
Display MoreThat's right, I created that file.
10bit attr:
Codehdmitx: set clk: VIC = 93 cd = 5 frac_rate = 18bit attr:
Codehdmitx: set clk: VIC = 93 cd = 4 frac_rate = 1Output is 10bit and 8bit respectively (confirmed by AVR), but both appear identical.
I write to the attr node in autostart.sh. The GUI output after boot is 10bit.
Edit: complete kernel log snippet
I believe you, but really can't recreate. Is the banding as extreme as your previous image from krypton (OZsfOvG.jpg)? Additionally on the 8bit output, you should see a bit of a "jitter" around where the banding would occur.
I can report that the frame skips seem to be gone.
I was previously on the 20170603182409 Frankenstein build and had a perfectly smooth gradient in my hdr_banding.mkv file. With the full Nougat build, the banding returned. There appears to be no difference between 8bit and 10 bit in attr.
Since I got a video of the same name from a post on this forum I've been using for testing, is that a smurfs intro? Could you upload the dmesg of playback with and without attr set to 10bit? I unfortunately can't recreate in 8bit with dithering, or 10bit without dithering.
Edit: there might still be issues if there's any playback before it's set.
kszaq Johngalt found the cause of the "balck screen - no signal" and he fix it in the nougat kernel. Maybe do you talked to him and embed this fix to the your next builds?
kszaq started linking to that thread in his OP, and once more testing is done I'd like to get these changes merged into kszaq's repos. I think we're nearing a "stable" point in terms of functionality
Uploaded a new build, and updated the download link in OP to point to github releases (no longer using an ad-ridden upload site). All changelogs between releases will also be posted there. If more users who had 4k output issues on nougat report this is working well for them, I think we could be close to making these "standard" builds
Changes:
From samba share I can't find /storage/.config folder
The "Configfiles" samba share maps to /storage/.config. Add the echo command in OP to an "autostart.sh" file in that folder.
Thank you kszaq. Again, none of this would be possible without the work you've done. Hopefully soon we'll have made enough progress this work can be merged back into your branches.
afl1 thank you for the device tree. I've updated the OP with it.
Regarding 60fps h264 playback, I'm first focusing on video that doesn't have frame skips on the MM kernel. The 60fps big buck video is also h264 L5.2, which was never supposed to be supported (only up to 5.1). As a side note, I have a high bitrate 60fps/h265/10bit/bt2020 movie that plays back in a watchable state (still frame skips, but not near as bad as just h264 4k).
I tested it with my marantz nr1606. It did not fix it for me. But then I have been having issues with the video switching in almost every build of libreelec for 905x. I have a mini m8s II box and a hisense 4k TV.
When libreelec starts it is just a black screen after boot logo. This also happens after switching back to libreelec interface after watching 4k(hdr) video.
I change the hdmi settings to standard and then back to enhanced in my TV setup menu. And I will get dislay. I have libreelec set to 3840x2160p at 60hz If I connect it directly to the TV it is ok without hdmi setting switching.
The only build that works fine without switching hdmi settings through my avr is 8.0.1g of kszaq. No issue at all with the startup of libreelec and video file hdr and 4k switching.
Hope this information can be useful.
This sounds different than the output issue some users were facing on 4k output alone. The null fix of kszaq's for mode switching may help (but probably not)
Do you have this issue if you set the GUI to another resolution such as 720 or 1080? 1080 for the GUI is recommended since LE supports resolution switching and has poor upscaling.
Edit: I introduced artifacts with those buffer changes on the last test build (not in OP). Still working on those.
Why not use github releases (About Releases - User Documentation)?
Seems to be the easiest way to me.
Thank you. I wasn't aware of the binary file support.
