White artifacts with S905X4 video decoder


Booted the 20.2-Nexus-Generic and this is what I’m seeing when using Kodi with PVR IPTV Simple Client. I have noticed that this only happens when the scene is moving, static images are being displayed correctly.

The issue disappears when I disable the amlogic decoder but that makes the video play at like 10 FPS so it’s not a viable workaround. Disabling noise reduction and rebooting made no difference and for whatever the reason I do not have the option to disable deinterlacing in my CoreELEC settings.

I did not make any extensive testing but what I can say is that simply using the tivimate app on Android 11 did not give me any problems. The box is the TOX3 and as far as I can tell it has an actual S905X4 rather than some fake, at least AIDA64 says so.

Any help is welcome as I’m not even sure what piece of hardware/software I should blame since there’s so many layers.

Limit colour display depth in display expert settings to 10bit or lower and try again after reboot.

I have exactly the same problem with CoreElec-20.2 on my Dune HD HBR4K+.
Strangely, this is not the case for all content, but especially for content with a 50/60Hz refresh rate.

On the other hand, if I boot on the same Dune HD with CoreElec-21.0, then these problems do not exist. All content is perfectly displayed with 10bit YUV444.
So it’s the same hardware, same settings, same HDMI cable, etc. just once:
CoreELEC-Amlogic-ne.arm-20.2-Nexus_nightly_20230705-Generic.img
and then just
CoreELEC-Amlogic-ne.aarch64-21.0-Omega_nightly_20230705-Generic.img

I reduced the color depth to 8bit, no change, still the same problem.
If I set the color space to YUV420, I have no picture at all, just a black screen.
I then have to change /flash/resolution.ini by hand so that I get an image at all after booting and then immediately set the color space back to “Automatic” in the setup, otherwise it will be overwritten again.

420 is only for 4k 50/60hz. It will be dark on 1080 GUI or 24hz.

No log… No error…
https://wiki.coreelec.org/coreelec:ce_support

Here is the log of a *.mkv video playback at 1080i 59.94Hz where the error is clearly visible.

I had to apply “dmesg | paste” it didn’t work via Settings → system → Upload latest… :
http://ix.io/4Alw

I’m now almost assuming that it’s because of the deinterlacing or because it’s not activated and it can’t be activated in the video settings either!
When I pause the video, the still image is displayed correctly, without the picture glitches.

In the video settings is “Deinterleacing Method = Inactive” and can not be changed.
However, when I open the “CodecInfo” window in KODI, it says: “Deinterleacing-Method = hardware”

The videos that are displayed correctly are all in 1080p.

And share a short sample where this happen to please.

I created a test file. It is about 40MB in size.
Unfortunately I don’t have my own location on the web.
Where can/should I upload it?

Here is the codec info from the test file:

  1. CoreElec-ne-20.2 with the image error

  1. CoreElec-ne-21.0 with the correct image

I played my test video with the picture problems with the VLC player and looked at the codec.
It says a framerate of 29,970628, so the 59,940fps in KODI is a doubling of the framerate.

In another video where I have no problems, the VLC player indicates a refresh rate of 23.976215.
When I play this video in KODI then the frame rate doesn’t double, it stays at the 23.976fps.
And here I have no problems. See here the CodecInfo from KODI:

Set colour depth to 8 bits and subsampling to RGB just in case. No effect.

Followed coreelec:debuglogs [CoreELEC Wiki] and got the log from dmesg (cause the submit log option would throw an error for some reason lol).
http://ix.io/4AmZ

I also download a test file (Downloads Page - Demolandia) and confirmed that it is being displayed in Kodi without issues. That being said the file uses h265 rather than h264 so maybe that could be the difference.

Not sure how to record my own sample from a live TV.

Find a free upload storage. Without a sample we can’t test it.

Hello @Portisch,
Here is the download link to the test file:
Test-sample-001

I don’t know when I get time for it…

It’s on the plan to backport the 5.4.210 kernel from CE-21 to CE-20 soon. CE-20 is currently on kernel 5.4.125. so when this happen your issue get solved anyway.

But we are really busy in background about setup the environment. When this is done the backport can start. We have no time schedule for it but it should be in next days/weeks.

I just tested on 20.2 with 5.4.125 kernel and 21.0 with 5.15.78 kernel.
No issues on both setups. So you might try another HDMI cable!?

Anyway, when we backport the kernel 5.4.210 from current CE-21 to CE-20 it maybe solve by itself anyway.

@Portisch
Strange that you don’t have any problems. :thinking:
For me it’s really the case that I only have this error with CE-20.2, if I then boot into the same Dune HD Homatics box with CE-21, the error is gone.

I have already tested 2 HDMI cables, once a normal Cu cable and then an HDMI 2.1 certified fiber optic cable. No change. Also, the cable is only 1m long, so very short.

But as I already wrote above, I once tested KODI 20.2 and then KODI 21.0 on the same Dune HD Homatics box. The only change was that I swapped the USB stick (whereby the USB sticks Sandisk Ultra Fit USB 3.1) are even the same models.

So I will wait until CE-20 uses kernel 5.4.210 from CE-21 as well. Maybe then my problem will be solved.

Many thanks for your quick help, even if it has not yet led to success.
But you can’t say it often enough: You and the entire CE development team are doing a really good job! Perfect! :+1:

Hi,

Just a quick me to post

I got a generic 905X4 device yesterday, I don’t suppose the model number matters much (X96 max + Ultra)

I get the same artefacts using TVHeadend client and server, using either ng or ne releases and SD (MPEG2) & HD (h264) content. The issue is ONLY present in PVR streams and recordings, all other content appears to be OK.

My previous 905X device had no issues at all, I’ve also swapped HDMI cables with another device, and still get the issue.

Edit:

Just tried 21 ne and the issue is not there, so looks like the later kernel does fix things

@Portisch
Today I updated to the latest CE-20.3 with kernel 5.4.210.
However, I had to download the corresponding image “CoreELEC-Amlogic-ne.aarch64-20.3-Nexus_nightly_20230728-Generic.img.gz” and copy it to the update folder, since the update did not take place automatically.

The update went smoothly, I only had to update the PVR addon “vdr-vnsi-client-addon” manually, everything else went through without errors.

A first test with the critical media that had the image errors went very well: the image errors are no longer there. Everything works perfectly!

Good job! :+1: :+1: :+1:
My thanks to everyone from the CoreElec development team!

2 Likes

I can corroborate what other people have found: that CoreELEC-Amlogic-ne.arm-20.2-Nexus-Generic running on an S905X4 (in my case an X96 Max Ultra) cannot use hardware decoding with some video formats.
Like these others I tried different HDMI cables, different screens and different color depths with no result, and finally discovered that turning hardware acceleration off would fix the video (though at the expense of maxing out the CPU).

As part of all this I ran some standard sample files. These are the results, in case anybody finds them useful:

https://kodi.wiki/view/Samples
1080i-25-H264.mkv		MP2		am-h264 (HW)		FAIL	
VC-1_23.976_sample.mkv	VC1		am-vc1 (HW)		FAIL		

https://testfile.org/videos/hevc/
sample_1920x1080.mpeg	?		am-h265 (HW)		no problem
sample_1920x1080.webm	VP9		am-vp9 (HW)		no problem			

Like @paul69 I now have success withCoreELEC-Amlogic-ne.aarch64-20.3-Nexus_nightly_20230728-Generic.img.
Again, thanks to the CoreElec development team.

Got same visual effect on tox3 s905x4 with CoreELEC-Amlogic-ne.aarch64-20.3. On 1080p wmv3 file.
Reinstall Amlogic-ne.aarch64-21.0 night build
New artifacts on same video:


Torrent file from here: deleted

Don’t post links to full files. Upload a sample.of the file, please.