Posts by johngalt

Quote from jd17

I am very sorry to hear that... Is there no way to set the RGB range to limited before you boot up the box?

So we finally have an explanation, but I still don't know why people kept claiming everything is darker in MM builds.
That makes no sense in any RGB range scenario.

The only logical explanation is that those users never made it past the initial menu screen, despite of all the warnings...

There's unfortunately no way, but seeing as I don't do HDR or 10 bit stuff on libreelec, I'm fine sticking with the nougat kernel. I'm glad we were able to get to the bottom of the issue.

I don't know why people have claimed that either. One guy (who I suspect is in the same boat I am) said something like, "as if a grey veil was lifted," which fits the washed out look of mismatched rgb range exactly.

Pelican

Each kernel has different quirks when it comes to HDR=>SDR and colorspace conversion (just as kodi on different platforms (eg before win10 creators update) might have quirks). I recommend sticking with SDR material on libreelec altogether.

Edit: if range_control stuff is reverted, the 10bit=>8bit banding is also "fixed" in nougat kernel. I'll do more testing, cleanup, and submit a PR. Is this the only bug that's been widely reported in the nougat kernel?

Quote from jd17

Please do that.

That theory might be true in some cases, but it is ultimately incorrect.

There is no change in RGB range between builds.

Both Marshmallow and Nougat Frankenstein Kernels output limited YCbCr in video playback.

My TV is always fixed for limited input and I made sure to test both builds again.

When the MM kernel boots up, it looks like the build outputs the full RGB range (0-255), so changing the TV to full range fixes the issue for a second.
However, as soon as you start the first video, the output is back to limited YCbCr, as it should be. So if the TV was changed to full range before, everything will look washed out.

Your theory still has some merit here, because TVs that have the range set to "auto" might read the signal as full range at boot up and stay at full range. The result would be washed out looking video.


So, users who complained about washed out colors with MM builds - please check your TV's RGB range setting and manually set it to limited (HDMI black level / black level = low in some devices).


To be honest, I always assumed this is a given and people have their devices set to limited by default...

Display More

Because it boots into full, I can't set the range to limited on my newer samsung set (stuck on auto due to broken firmware on entire samsung lineup). I was able to test on my sony and can confirm.

Quote from jd17

Could you describe these black level changes in detail and take comparison pictures?

I do have a HDR capable display from 2016 and while there is the obvious "dark after boot" phenomenon, I see no difference whatsoever in any video, at least not in regular AVC 1080p / 8-Bit / BT.709 stuff.

You do mention test images, not videos - are you maybe judging the Kodi image viewer, not the video player?

When you look at the "black clipping" pattern from the AVS HD 709 collection, do you see any difference?
AVS HD 709 - Blu-ray & MP4 Calibration - AVS Forum | Home Theater Discussions And Reviews

Display More

I used test videos (actually same as off avs forum).

I'll grab some photos, but I found out the behavior of full or limited black levels changed between nougat and marshmallow kernels which is where the difference lies: not whether the display is hdr capable. Mix in that many current displays have broken "auto" black level (like Samsung's entire lineup), this is why some of us have seen the black changes, and others haven't.

I decided to play a bit and have two branches: one amlogic-3.14.y-new branch that has only nougat ucode PQ changes and banding issue fix (the "range_control" related commits gone), and another with pure nougat kernel (without media_build) I'm working on.

Quote from Ziiky

Problem is in CEC support. When I turn off TV (Sony), rec (Denon) and Nexbox a95x turns off too.

But when I turn On TV and rec ... box do not turn on (its not problem because most boxes do not support this), but problem is when

I turnOn box with remote ... red led turns into blue ... but there is no picture, only black screen. Also, there is no access to box via home network.

Box is dead. Only what I can do is to unplug/plugIn 5v jack. After that box runs normal boot procedure

Is there any way to turn off CEC support in libreelec?

I noticed that in new roms we have again dark picture "old" problem witch persist till first video play ...

Display More

Settings => System => Input => Peripherals, customize CEC. I'm not sure if a reboot is required after or not. I have the power off/on and send inactive stuff disabled so it stays on, but the tv remote still works (use it for everything).

As a workaround for dark picture, you can set a boot video in some skins or possibly by a config (unsure but could google). I used an intro video I found off a kodi forum. Android requires a 4k video if you want to use the same intro video on android, so you'd need to find a 4k video or use ffmpeg to resize. There's an amcodec patch floating around that fixes the dark screen issue on MM android, but I'm not sure if it's applicable to LE (probably not since it wasn't implemented).

Is there a patch floating around to support resolution switching downward as well as upward? I prefer the GUI at 1080, but still will occasionally watch tv at 720 before the 1080 downloads. My TV has great upscaling which I'd also like to use on the 720 sources.

Edit: Given the update in OP regarding HDR handling, here's a small summary of the real world impacts between the marshmallow and nougat kernels:

- Note: You won't get real HDR in either, you need to use android + SPMC for that (either another box or dual boot).

- 10 bit output doesn't work in either, but the 8 bit conversion works much better in the marshmallow kernel (which eliminates tons of banding compared to the nougat kernel). I have a suspicion the cpu checks added into the nougat kernel aren't working properly, but haven't tested (and am not motivated enough to due to using android for HDR material).

- Colorspace won't be passed on, and despite my earlier comments, forcing the colorspace to bt2020 on TV or AVR won't be correct because there's a colorspace conversion to bt.709 first. After proper HDR playback, this is most noticeable on skin tones to me even when forcing. I also had color clipping from forcing to bt2020 on bt2020 source in vibrant HDR jungle scenes (so it went source bt2020 10bit => libreelec bt709 8bit => TV bt2020 8bit)

- Where the marshmallow kernel excels is on bt.709 10 bit x265 sources that would get severe banding on the nougat kernel.

- There are black level changes between the kernels depending on display capabilities. On some displays, there are no black level changes on test images. On both my newer hdr capable displays, there are major changes in black levels that make me prefer the nougat kernel. It's worth noting I get the same test images for black level on the nougat kernel as on the marshmallow android build.

I have a large 4k library and don't have those issues. However, no amlogic libreelec device supports HDR output (you'll need to run android for this).

Even though you don't see conversion banding, it's still not "functional HDR" as said earlier. For true HDR output, you need to use Android. This could be done with a separate device or by dual booting.

If you have 10 bit media and don't care about HDR or 10 bit output, the MM kernel is a great solution.

I ended up giving up on LibreELEC and going to an Android TV build for proper HDR support.

Pros: HDR/10 bit output/colorspace switching actually works with an Android TV port and spmc. It looks indistinguishable from my internal player.
Can use some Android TV apps as spmc launcher shortcuts.

Cons: No resolution switching, so dealing with poor upscaling on anything that isn't 4k.
Brightness bug is back on boot.
Needed to root and use PassthroughFix.apk to fix passthrough clipping.
SPMC is currently only available as a Jarvis build.

I'm very tempted to use separate boxes with LibreELEC and Android on different inputs so I can have proper HDR/10bit output/colorspace switching, and also resolution switching for decent upscaling.

Quote from kubrickdave

Take a look at this clip:
hdr_banding.mkv

This is cut from an untouched 4K HDR BD (for educational purposes) and highlights the banding issue very well.
I took photos of both the LibreELEC output and my TV's internal player output (same manual exposure). It also shows my AVR's info menu, confirming 8bit. One can clearly see the banding in the top part. This is Krypton by the way.
http://imgur.com/a/VV5HH

I have to add that this is an extreme case and it's not nearly as noticeable in real film material, hence people saying that they don't see the difference.

Thank you, this clip is an excellent example. I also get the banding you outlined on Jarvis, though there are small clips where on jarvis it isn't as noticeable as on krypton. I was mistaken about jarvis doing 10 bit output. When I get a chance this weekend, I'm going to flash a box to android (marshmallow first, then nougat) to test this clip with the "deep color" and "hdr" android options enabled/set to auto.

Seconding an earlier post: I don't have a way to check for 10 bit output any longer, but the way the conversion occurs (if it does) in jarvis is much better than krypton for banding which is why I thought it was still outputting 10 bit in jarvis.

Quote from wrxtasy

I had a PM from wesk05 who has specialised video test equiptment - and he sent this regarding AML HDR using LE on S905x's:

I'm curious where the limitations lie, because in Android there is a "Deep Color" option in settings. Do you know if this works on Android in something like spmc?

Quote from frequenzy

For those running latest le8, do you also get massive frame skips with this test file. tried via nfs and usb. box is S905x. i know 4k is experimental but just wondering.

big buck bunny 4k
bbb_sunflower_2160p_60fps_normal.mp4

Yes, le8 gets occasional frame skips with some 4k videos, le7 doesn't. I know we're not supposed to compare krypton to jarvis, but if you use 4k, hdr, and/or 10 bit output, you should be using le7 anyway.

Quote from EagleEyeX

I tested a 4k full bluray HDR 10bit with DTS-HD 60gb. On a t95x s905x the device has trouble to stay in sync with audio and sometimes it eve loses audio output. It only restore by reopening the file... i play the file via ethernet 100mbit from NAS

File info? I have a few 10 bit 2160p hdr10 files around that size that work well, all 23.976fps, and I do audio passthrough with hdmi. For 60fps I haven't played longer than test files, so can't comment (I know there's one "high framerate" 60fps movie out).

BTW: if you're 10bit/hdr capable, you shouldn't be using krypton which is incapable of full 10 bit video output (can do 10 bit output, but video is cut down to 8 bit first resulting in banding).

Edit: because of guy below me, I also use network, but don't use samba. If you're okay on external drive, maybe try a different network protocol with less overhead?

Quote from Reflexion

My Beelink MX mini with LibreELEC (micro-SD) ensures with cec that the remaining devices like; Av-receiver and the Nvidia Shield TV are disturbed, and I have to reset "cec" there, I can disable cec disable in LibreELEC?

Yes, in settings => system => input => peripherals, then reboot.

Quote from BeToven

Does anyone know what is missing to fix" the some Live TV channel can experience frame jumps " and if is already solved in LE8?

Thanks

I can't test, but you could try the build above yours to see if it fixes the issue without doing a full LE8 upgrade. In the LE8 thread, many users have complained about slow channel switching being a krypton bug, so if the frame jumps have been fixed by kszaq on device side of things, this could end up being a decent compromise.

As a non-live tv user, the only reason I'm still staying on Jarvis and doing those hybrid builds is because of the overall 2160p picture quality and 10 bit output support of Jarvis that's lacking in Krypton, Leia, and kodi-agile currently.

Quote from yatoya

Does it make any difference?
I've been using it as well but didn't see any difference.
What exactly are fractional refresh rates?
[hr]

LibreELEC-S905.arm-7.0-devel-20170424235814-r23789-gc49f56a

I get a lot of skipped frames on my TX5 Pro. CodecInfo doesn't show anything but they are noticable visually.

Making a guess here without looking at the code: if your TV supports a fractional refresh (For instance ~23.976hz), but you're manually overriding it as 24hz, this might cause stutters. The new automated framerate implementation of kszaq supports fractional refresh rates properly unlike before.

yatoya instead of modifying the refresh parameters, you can run a simpler advancedsettings.xml with min/max (to catch fractional refresh rates) like so: hAaT

Not sure re: vp9 hdr metadata (never tested), but you should really downgrade to one of the nougat kernel jarvis builds with the 4:4:4 patch if you care about 10 bit output and 2160 picture quality.

Slightly OT: I started building LE master + kodi-agile builds with kszaq's changes merged in because I was curious about the state of development, but the krypton PQ regressions aren't fixed.