Android: Properly overwrite ProcessInfo and use Deinterlace Half

[fritsch]

YADIF Full is too much for most devices. Use a less CPU hungry default.

This is only used when SW Decoding is active, e.g. für DVD stills and so on.

[peak3d]

Where is the call that registers the ProcessInfoAndroid?
Usually registering of components is done in WinSystemAndroid

Edit: Example OSX: https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/osx/WinSystemOSX.mm#L824

Android Registration block:
https://github.com/xbmc/xbmc/blob/master/xbmc/windowing/android/WinSystemAndroid.cpp#L77-L86

[fritsch]

Thanks. Found it and added it.

[fritsch]

jenkins build this please

[CiNcH83]

This won't fix a lot IMHO. I also tried a progressive DVD which plays at 25fps and also jerks like crazy on Android. It does not seem to be YADIF that is causing the jerkyness.

[fritsch]

Why would yadif be used on a progressive DVD?

[CiNcH83]

Exactly. It is not. And that is why YADIF is not the problem as the progressive DVD also jerks...

[fritsch]

And why do you thhink your device is representative for all Android devices?

[CiNcH83]

Gut feeling.

[fritsch]

And why do you think reducing the default load is not a good idea? Anything technical that speaks against this change?

[fritsch]

Example: http://solidrun.maltegrosse.de/~fritsch/576i50_mpeg2_samples.ts <- you should easily see the difference between yadif full and yadif half. One makes it work without issues on Wetek-Play, the other for sure not.

[CiNcH83]

You can of course do whatever you want. You Kodi guys are always against dubious workarounds which do not tackle the root cause of a problem. And YADIF isn't the root cause for the jerkyness on Android IMHO. Progressive MPEG-2 and MPEG-4 SD videos also jerk like crazy when SW decoding them.

Plus there is a good reason for double frame rate deinterlacing which is preserving full motion resolution.

[fritsch]

This is not a workaround. It sets a sane default for in general slow ARM chips to increase the chance to not kill them right away when post processing needs to be done on the CPU.

[CiNcH83]

I currently can't software decode any MPEG-2 or MPEG-4 in SW without massive jerkyness, not even 24p and 25p at SD resolution. So trying your sample does not mean a lot until the root cause for the jerkyness is fixed. Jarvis and Krypton seem to be fine in that regard.

But you might be right that a frame doubler might probably be too much burden for those slow ARMs.

[fritsch]

I used the last 10 minutes, installed kodi 18rc on my Huawei P10 Lite. And watched some 576i50 LiveTV with SW decoding and YADIF half.

That worked remarkably good. Is your TV really that slow? Odd.

[CiNcH83]

Most Android TV devices are either based on Amlogic S905X in case of settop boxes or MediaTek MT5890/MT5891 in case of TVs with pretty slow quad ARM Cortex A53. That's a reality.

[da-anda]

I can check on my Philips AndroidTV which also has a MediaTek chip. I hadn't noticed any issues watching liveTV so far, but I barely watch liveTV these days, especially not SD channels. Just let me know if I should do some testing

[CiNcH83]

I hadn't noticed any issues watching liveTV so far

Suppose you are using HW decoding. The problem is with SW decoding...

[peak3d]

@CiNcH83 what is the reason you prefer s/w decoding?

[CiNcH83]

I don't. I actually never use it. I just know that SW decoding is in dire straights due to MPEG-4 ASP and DVD which have been decoded in SW until recently. I am fine with the recent changes to accelerate those formats.

Something is wrong with SW decoding nonetheless. A log can be found here.

[peak3d]

Is there any sample around which shows the issue? Reading the log without knowing how it looks like is impossible (at least for me)

[CiNcH83]

Here is another log taken while playing @fritsch's TS sample posted above. This sample is interlaced though.

The log from the forums has been taken from a progressive DVD which also eliminates the impact of YADIF...

[CiNcH83]

I can actually reproduce the issue with anything I play through SW. So it does not require a specific sample. SW decoding is just not feasible anymore for me. Jarvis and Krypton used to be just fine for stuff that a weak Cortex A53 is supposed to handle in realtime.

[CiNcH83]

I uploaded a video to YouTube, demonstrating the judder (CLICK). The iPhone captured it quite well...

[fritsch]

The PTS are totally nuts again here.

[fritsch]

Could you please post another log with Deinterlace force OFF?

[CiNcH83]

Afraid I can‘t provide it before Monday. Currently on vacation..

[CiNcH83]

Here is a log captured while playing the TS sample with deinterlacing forced off.

[fritsch]

Thx much @peak3d do you have an idea why those PTS are so wrong?

[fritsch]

Btw. what he prints here is without video decoding actually running. That means on this device we barely can render kodi's UI ...

[CiNcH83]

Yeah. It is kind of laggy...

[fritsch]

After what I see here I think @FernetMenta is right! This especially makes sense when looking at the SW decoded rendering path. Cause here we are solely on the GUI layer.

Means the stats you showed can directly be linked to the normal GUI rendering with even adding a bit more load as the video frames need to be uploaded.

[CiNcH83]

I don‘t know whether this means a lot, but the sample plays fine with MediaCodec+EGL (i.e. Surface disabled).

[fritsch]

@CiNcH83 do you use the setting: "Use Limited Range"?

Could you disable that?

[fritsch]

Mediacodec-EGL uses another path to get the decoded frames to display.

[CiNcH83]

Can't see this 'Use limited range' setting on my BRAVIA Android TV...

[CiNcH83]

@fritsch

Is ffmpeg for ARM Android now built with NEON? What makes you believe that it is not?

[peak3d]

@CiNcH83 I'll provide a PR today for the rendering bottleneck.
Still not optimal, but much better. An optimal solution will come with GLES3 implementation.

FFMpeg is compiled with NEON flag for Android.

[CiNcH83]

Sounds great.

So my BRAVIA might benefit from GLES3 at some point :) . As a sidenote I want to add that all current Amlogic S905 based devices (like Mi Box and quite some Fire TVs) won't benefit from it as the built-in Mali-450 GPU only supports up to GLES2.

[CiNcH83]

Suppose we will further discuss the rendering bottleneck on the other PR...

Getting back on topic, I compared CPU usage (quad-core ARM Cortex A53@1.1GHz) of several Kodi versions and deinterlacing algorithms using @fritsch's TS sample posted above...

Jarvis (Deint: Off): 17%
Jarvis (Deint: Blend): 20%
Krypton/Leia (Deint: Off): 33%
Krypton/Leia (Deint: YADIF): 65%
Krypton/Leia (Deint: YADIF Half): 55%

While Krypton/Leia increased the basic CPU load quite a bit (compare 'Deint: Off'), it is mainly YADIF that stresses CPU on later Kodi versions due to its complex nature. YADIF Half doesn't change that considerably.

YADIF seems to be manageable on my BRAVIA, at least for SD (I will do more thorough testing once @peak3d releases the rendering bottleneck patch). Since you can't SW decode anything at higher resolutions (like some 1080i) on such hardware, that's probably all we need to care about anyway.

So if you want to go ultra low-profile, you might want to consider another deinterlacer altogether.

[peak3d]

Interesting fact is that Jarvis used NEON YUV -> RGBA conversation where we use GPU shader now (this is at least my assumption, if you provide a J log I can verify)

The solution which works for GLES3 does not work for other devices like Wetek HUB, so we're still searching for a more proper solution. Nevertheless I'll push a PR if you want to test.

Looking forward to J log

[wrxtasy]

@peak3d,
I'm running an updated GLES3 on the MINIX U9 - any chance to spit out a test version with your PR ?

[peak3d]

@wrxtasy sure, give me some minutes

[CiNcH83]

Sorry, no clue what a J log is.

[mo123]

Sorry, no clue what a J log is.

A log from Kodi Jarvis 16.

[fritsch]

Just little intermediate news:

• The SubTexImage2D for copying the texture by doing it linewise cause of the stride not matching is one part of the issue -> slow as hell. (1)
• Copying the buffer on the CPU before, so that stride matches width and one glSubTexImage2D per texture is enough -> full 50 fps for playing this video is achievable. (2)
• And removing the yuv2rgb shader to not do 3widthheight texture lookup also worked with (1). (3)

So: Lessons learned: Take care for Shaders on slow 3D GPUs (most embedded socs) and try to not transfer the CPU Image data via linewise SubTexImage2D.

There is no problem at all using SubTexImage2D if you can do it for a buffer at once. (Obviously PBOs are better, but it's not the key issue here).

Btw. In Jarvis we even did the yuv2rgb on the CPU with neon ... so this fixed (3) while compensating (1)

[fritsch]

Testbuild is upcoming here: https://jenkins.kodi.tv/job/Android-ARM/12623/ has stridegles in name - as it's quite early here chances are good that you will hit an off by one error.

Code is here: fritsch@492680b

Edit: Obviously the malloc / free per frame can be removed.

[fritsch]

Here we go: http://mirrors.kodi.tv/test-builds/android/arm/kodi-20190119-492680ba-stridegles-armeabi-v7a.apk ( wait a bit until mirrors are synced)

Btw. One can missuse the debug overlay to see the fps that are rendererd. This is by far not exact, but it's very good to see the difference between those versions easily.

[fritsch]

Real solution for the "performance issue" on GLES, here: #15286
ProcessInfo change is still valid :-)