[BUG] S905X Krypton: Bad chroma upsampling

You are right, both commands render my VC-1 media unplayable. It is very smooth by default, but becomes out-of-sync and slow with the commands.

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 jd17

It was my information that 1080p is always output as YCbCr 444 while 2160p is output as YCbCr 420.

I have the box set to 1080p60 (+ refresh rate switching) so the majority of upscaling is done by the TV.

The title and my initial post might be confusing, but we must not mix upscaling of a low resolution to a high resolution and chroma upsampling. Those are very different things.

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...

I edited title and initial post to avoid confusion.

Display More

If you can really output 4:2:0 at 1080p you could circumvent the chroma upsampling, provided it doesn't do 4:2:0 -> 4:4:4 -> 4:2:0 internally. But I think the 4:2:0 modes were only scpecified in HDMI 2.0 to save bandwidth at 4K resolutions, so your TV might not accept it at 1080p.

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?

Quote from kszaq

A better solution: echo 1 > /sys/module/di/parameters/bypass_prog

This flag was set in Jarvis but I set it back to 0 because for some reason this was needed to make VC-1 playback work properly...

so this flag is identified as the culprit and now we need to identify why it interferes with VC-1 playback in Krypton hw acceleration. that's progress, right?

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

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

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 meijjaa

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

Is this just a misconfiguration in kszaq's build or the default config coming from Amlogic's kernel source? This and all the other issues make you really think, just how bad one can screw up video processing. Can't they get anything together without hobbyists having to fix their work afterwards.

Quote from jd17

As was pointed out in the beginning of this thread - many things have changed when going from the old Kodi video player in Jarvis to the new Krypton video player.
This is a Krypton-specific issue, so I think AMLogic is not to blame...

I know about the changes in the video player, but these are parameters for one of Amlogic's kernel modules. They are not directly related.

Krypton builds are now using default kernel settings for deinterlacing and all other video processing. This doesn't mean that Amlogic is fully to blame because they play with these parameters in their Android "native" video player app.

Quote from kszaq

Krypton builds are now using default kernel settings for deinterlacing and all other video processing. This doesn't mean that Amlogic is fully to blame because they play with these parameters in their Android "native" video player app.

Would it be possible to compile a list of known hardware decoder bugs? I have heard of slight overscan (missing a column of pixels left and right), as well as the stuff mentioned in the OP of the main thread. Are these unfixable?

BTW is there some public documentation available as to what the available parameters do or just generally for the SOC?