Posts by meijjaa

Quote from marduk

Hello, I have KIII PRO with last LE 8.2.1.1 and it works well. But I have problem with LiveTV (DVB-S/S2). On some channels after some time (randomly - from 10 to 30 mins) video is corrupted (attachments), OSD is OK. When I stop (finish, not timeshift) and play (or switch to other channel), everything works well, but again temporarily. After some time the stream is corrupted again. Thanks for your help.

I see this as well on my KM8 PRO, also a lot of micro stutters but everything else is working perfectly. My S905X device doesn't have these playback issues.

Hi Kszak,

I tested your latest builds (d & e) with LIRC support, I think it's very nice because potentially could remove my MCE USB receiver (RC6 eHome IR transceiver). But sadly with these builds the device no longer boots with the USB receiver attached (LIRC dtb and normal dtb file). It won't get past the LE splash screen.

Also I can't get LIRC to recognize the buttons, using irrecord:

Now hold down button "KEY_1".

Something went wrong: Cannot decode data

Please try again. (28 retries left)

Any ideas? Thanks!

Quote from kszaq

You may have found a solution to some else's issue... Thanks! I'll revert it for the next build and we'll see.

Nice, happy to help. One more though, this one prevents channel switching (at least for the hts pvr plugin):

kodi/amlogic: fix drain loop, sometimes timesize won't go down to 0

Quote from Drjogalog

HDMI Sparkles?

Yes you are right, apparently my cheap HDMI cables won't accommodate the full 4:4:4 chroma signal at 2160p > 24hz . The stock WII U HDMI cable is a well built cable by the way: no more sparkles

625baba kodi/amlogic: fix parsing extended 4K formats, e.g. 2160p60hz42010bit

Is causing white pixels to pop up all over the screen at 2160p50hz, almost like the device is dying .

Quote from kszaq

Sorry, I'm not familiar with every box on the market. I'm telling you to try other device trees.

Sent from my Nexus 4 using Tapatalk

Hi, Kszaq,

Seems like you already fixed the blackout with the one commit that seems to not have made it into 8.0.1e (accidentally?):

06d73ed projects/S905: Kodi: update Nougat-style fractional frame rate patch

8.0.1f seems to work alright as well but with 8.0.1g I can't switch channels anymore (using tvheadend client).

Thanks Kszaq, I upgraded to LE 8 and almost everything is running perfect.

Only thing I could find (after upgrading 8.0.1d to 8.0.1e) is that skipping backwards a couple of minutes the video stops playing. Reverting to 8.0.1d fixes it.

Great work! I got my KM8 PRO 2/16 back from storage to test and all the basics are working by not providing a dtb file from SD:

Accelerated video playback
Audio pass-through
Bluetooth
Remote
Gbit ethernet
WiFi
HDR (no Dolby Vision though)
Smooth GUI most of the time

Quote from kszaq

I have only 1080p TV, can't test this.

If you want to test 2160p, please try setting it in Android and then reboot to LE.

This also works , or by setting mode manually or using /sys/class/display/mode but in some situations the output will glitch out and only the top half of the screen is filled.

Only thing left are the stability issues you mentioned, some graphic glitches and some performance drops.

It might just be my TV but what I see is this. I got the best result with my lg TV at pc mode.

Bad chroma up sampling and color banding:
1080p 24hz + 50hz (4:4:4 and RGB)

All ok:
1080p 60hz
2160p 24hz + 50hz + 60hz (4:2:0 and 4:4:4)

Quote from jd17

That sounds to me like you figured out the root cause.

The conclusions I would draw from that:

a) Stop forcing Deinterlace on (all) P content.
b) Improve Deinterlacing (quality) for I content.
c) Find reason for VC-1 issues with deactivated Deinterlace.

Did I get this right?

Nice summary, sounds like the right conclusions to me, also these issues are more visible on SD content like you already mentioned

Quote from jd17

Maybe I am misreading this, but are you saying that a forced deinterlace is responsible for the bad PQ, if the bypass command is not used?
Or does this just apply to 1080p30?

I found some samples: Zippyshare.com - the 1080p30 sample gives flickering boxes and comparable to VLC with deinterlacing forced. The 1080i60 sample shows bad Chroma upsampling again because deinterlacing is active again. Bypass all at 1080i resolution makes the tv deinterlace and it looks a lot better.

linux-amlogic-le/deinterlace.c at amlogic-3.14.y · kszaq/linux-amlogic-le · GitHub here you can find how the choice is made. It does look a bit strange that progressive content is processed by default.

Quote

I find the LG's upscaling from 1080p to 2160p considerably better than the box's...

Probably but in my opinion the overall look is better when using the tv for upsampling , the color banding in skin tones is more visible using 1080p.

Quote from jd17

It's best to just compare and see for yourself.

Look at the Spears&Munsil pattern, especially the top circles and diagonals.

Then run one of either commands...

...and look again.

I see the effect everywhere, but especially in upscaled (SD or 720p) content.

I only wanted to point out the possibility but thanks for the suggestion and now you triggered me...

I just got the full S&M Blu-ray and bypass_prog really needs to be turned on indeed. But it doesn't fix 1080p30, deinterlacing is forced on anyway causing flickers and Chroma error is visible. Also 1080i content shows the Chroma error + deinterlace error probably (but no flicker), bypass_all enabled and output to 1080i (making the tv deinterlace) works around it. But 2160p 4:2:0 gives a slightly smoother color ramp, what to choose... Everything else is looking very good though

Quote from jd17

I would like to give it a shot.
The Spears&Munsil test pattern is in 23.976p.
I assume a refresh rate switch overwrites those kinds of commands?

Can I fix the GUI to 23.976Hz and run the command...

Code

echo 1080p23.976hz420 > /sys/class/display/mode

Or is the command for this refresh rate different? Maybe 23.98Hz or 23.9Hz...?
[hr]
I just disabled refresh rate switching and tested the following:

Conclusion:
Nothing to gain here. The standard modes are already ideal.

Display More

Ah yes I see so 1080p only yCbCr 4:4:4 (echo 1080p50hz > /sys/class/display/mode)
or RGB (echo 1 > /sys/devices/virtual/amhdmitx/amhdmitx0/output_rgb).

I can do 2160p @ 24p and 25i content at yCbCr 4:4:4 by the way, after that the bandwidth is just to low or because it's not supported.

For 24p content can't set fractions, the driver should compensate for it:

echo 2160p24hz420 > /sys/class/display/mode
echo 2160p24hz444 > /sys/class/display/mode
[hr]

Quote from jd17

That rule hardly applies here.
A reference Blu-ray remux suffers just as much from bad chroma upsampling as a low bitrate encode.

There is nothing the TV can do about it, but I believe you are talking about resolution upscaling again...

My goal was to deinterlace and upscale 1080i25 content by the box (s905x) and upsample by the TV.

But what do you actually mean by bad quality? Do you have a lot of color banding?

Chroma format seems to be chosen very randomly, I guess you could change it at runtime to see what looks best?

e.g.
echo 2160p50hz420 > /sys/class/display/mode
echo 2160p50hz422 > /sys/class/display/mode
echo 1080p50hz444 > /sys/class/display/mode (yCbCr 4:4:4 unsupported at 2160p 50hz)

For me letting the TV do the up sampling looks good for 1080i 25fps content (2160p50hz420). But as always, shit in = shit out

Quote from panterck

OK I tried fresh install of 12h. It's 0.425ms delay for me with two different device trees:gxbb_p200_2G_1Gbit.dtb 24-Jan-2017 16:40 38576
gxbb_p200_2G_1Gbit_OTG_Port.dtb Anyway...the same (OTG) when used in Krypton means only 0.175ms delay on my device (Minix U1) with Yamaha YSP-2500 soundbar.

Hmm yes it seems to fluctuate a bit depending on content, pcm VS passthrough, with / without matching refresh rate and the TV and receiver used.

Quote from jd17

Thank you for that piece of information! I did not know that!

kszaq:
Would you be open to implement that in your upcoming builds?
If the 175ms delay is already implemented in regular LE for 24p, there does not seem to be any harm in it?
[hr]

I cannot confirm your 500ms for 12h.
I have exactly 175ms in 7.0.3.012h (fresh install from scratch).

Maybe you changed something else?

I think the vq patchwork at some point added a lot of delay but with the 012h build fixed it, for me it's only 175ms delay on 24p content as well now :).

Quote from kszaq

Nothing is impossible when you have time, skills and documentation. Unfortunately when developing for Amlogic a lot of guesses, trials and errors have to be made. I don't think that Amlogic kernel supports any kind of PLL adjustment. You are free to look at kernel source code and try to implement it but I have to warn you that it's a bit messy.

24p passthrough has always been out of sync with xbmc/Kodi, not just for amlogic hardware for me. LE defaults to a 175ms delay but not for these builds, I would suggest to include it :).

LibreELEC.tv/advancedsettings.xml at master · LibreELEC/LibreELEC.tv · GitHub

I tried to debug some more but I wasn't able to reproduce it anymore (tried about 30 cold / warm reboots)... normally 1 in 5.

MXQ Pro 4k (S905) LE 7.0.3.012g
LibreELEC-S905.arm-7.0.3.012g.img.gz
gxbb_p201.dtb
From internal, USB boot disabled.