[CiNcH]

i deactivated only "mediacodec surface" and "de-interlacing" (during video playback in video options). You are right, the problem video could be played without the huge stuttering.

You have an MT5891. My MT5890 won't play your 720p25 smoothly at all in non-surface mode. Deinterlacing in video options is greyed out for me (I am currently on a master nightly though). I wouldn't have expected a difference for progressive content anyway though.

[CiNcH]

There is currently a pending pull request by @Koying. Kodi will afterwards call MediaCodec natively. Today this is done via JNI into Java code, which will eventually call back to some native code. This can be killer for real-time video decoding and rendering as there are several such calls per each frame. Will be interesting how Kodi performs afterwards.

[Martijn]

You can install the test build from our server of you want

[CiNcH]

Where would that be? It is not in the master nightly, is it?

[Martijn]

It will be here in an hour or so
http://mirrors.kodi.tv/test-builds/android/arm/
With amcL in the filename. Had only 64bit build so now triggered 32bit

[CiNcH]

Unfortunately no improvement . CPU load is still high on the MT5890 with dual core ARM Cortex A17, way higher than with other Android media players when playing video.

[Jinx1337]

CiNcH, all the bugs you have mentioned and the issues you keep track of on your google docs also apply to our Philips TV (God curse Mediatek).
And yes, I have had a horrible experience with KODI after upgrading to marshmallow with our recent QM163E: 6.188.12 update.

I posted several of your issues on philips support forums. Thanks for keeping track of them.

[mpiet]

@TeamKodi, is there any hope for the future that Kodi video playback can be improved for Android TVs?
I have not only problems with the movie i mentioned in this thread but with some more. On other movies the stuttering is nearly not visible but after 30 minutes watching the tone is not synchronously any more.
Here is a short sample of the most stuttering video: Link

[CiNcH]

In VLC it is possible to switch between IOMX, IOMX-DR, MediaCodec and MediaCodec-DR. I don't really know what DR means, but I suppose IOMX (OpenMax) is like stagefright? All 4 HW decoders suffer from the stuttering on the sample.

[Koying]

I bet DR = Direct Rendering = Surface

[CiNcH]

I bet DR = Direct Rendering = Surface

Googling it indeed reveals that DR uses Surface rendering.


I did another test with non-Surface MediaCodec in latest Kodi L18 nightly. Performance seems to have improved and the cutted-sample.mkv indeed runs smoothly on my Sony now too. But non-Surface just uses too much resources on the weak MediaTek SoC. So higher resolution video isn't smooth anymore. Also interlaced video somehow suffers from non-Surface.

So I did another comparison of the resource usage with cutted-sample.mkv (720p25 H.264).

Kodi 18L

MediaCodec - smooth

Code:

org.xbmc.kodi                     ~18%
/system/bin/surfaceflinger         ~6%

MediaCodec-Surface - jerky

Code:

org.xbmc.kodi                     ~12%
/system/bin/surfaceflinger         ~6%

VLC

MediaCodec - jerky

Code:

org.videolan.vlc                   ~8%
/system/bin/surfaceflinger         ~2%

MediaCodec-DR - jerky

Code:

org.videolan.vlc                   ~7%
/system/bin/surfaceflinger         ~2%

What additional things does Kodi have to do in non-Surface mode? Copy back to main memory? Deinterlacing? Scaling? Is this done in SW, GPU or via some HW-API?

With VLC, Surface vs. non-Surface does not seem to be too different from a resource point of view. IOMX decoders use slightly less resources. But all modes perform similarely on the cutted-sample.mkv, which is always jerky though.

[fritsch]

You should not compare with "jerky" versions as you want smooth video don't you?

We have a smooth version at 24% and everything, including complete VLC playback, from 9 over 10 to 18 % is jerky - so - the very moment VLC runs fluent with < 24% we might need to have a look, but for now I don't see an issue at all.

[CiNcH]

Problem is that most video is jerky without Surface. It is basically unusable most of the time because of the weak processor. You really want to use Surface on the slow MediaTek processors in Sonys. The particular sample above is not complex (only 720p25) but for some reason stutters with Surface. And because it is not complex it plays fine with non-Surface mode. So you will have to switch to non-Surface for this particular video (and others too).

Cumulated CPU usage is much higher than the above figures and can be around 80%. My comparison only includes the processes which use the most CPU. There is not a lot of air on the weak Sonys. Most other video players on Android use way less resources for playback. Kodi also implies more CPU usage on other parts. Kernel time for example increases quite substantially.

[fritsch]

The 720p25 movie does not sutter cause of surface, but cause of the way the render is implemented. There are some testbuilds around by @peak3d that currently heavily reworks this android decoder, give them a try.

[CiNcH]

Can you point me to those and the commits maybe?