Login at Kodi Home

CiNcH · (This post was last modified: 2016-12-10, 00:16 by CiNcH.)

I just measured power consumption of the TV and with SPMC, it drew about 0.5-1W less when playing the sample. That's not a problem of course as it won't make my electricity bill explode. But it might be an indication that there is some more number crunching going on on the SoC, for which 1W of additional power is a lot already.

Kodi runs on very thin devices nowadays and I think it is important to be sensitive on this matter. I am currently analyzing occasional hiccups with the PVR (due to data rate drops over WiFi) and it just makes you wonder whether problems correlate.

**fritsch** · 2016-12-10, 07:50

Means you want to identify a badly written driver that looses bytes whenever the cpu shortly needs to do more things?

Btw. I already told you in my first reply why kodi v17 draws more power while video playback than Jarvis does.

What about your measurements on idle?

CiNcH · (This post was last modified: 2016-12-10, 13:32 by CiNcH.)

Quote: Btw. I already told you in my first reply why kodi v17 draws more power while video playback than Jarvis does.

I thought that already proved to be wrong in my case?

Quote:What about your measurements on idle?

Yes, I started with idle power measurement, which was the same for both.

**fritsch** · 2016-12-10, 13:31

Oki - then everything has been said. Let's keep that thread open here so if someone wants to look after it, he can find this writeup.

CiNcH · (This post was last modified: 2016-12-12, 08:46 by CiNcH.)

I just wanted to do the TRAC entry and I don't think that I got the thing with playback to display synchronization...

You wrote:

Quote:Known. Old Jarvis throttled itself cpu wise in rendermanager. 24 fps on 60 Hz would mean: 24 frames. In Krypton render is running with Display refreshrate. If you want 24 fps only use adjust refreshrate setting.

You say that if my refresh rate was at 60Hz and I played back some 24fps movie, Krypton would render 60 video frames (adding some duplicates I assume), right? I don't get how 'Sync playback to display' helps here. I would assume that this option actually does the 24-to-60 fps conversion. Or did you mean I should enable it for Jarvis and I would get the same high CPU load? That would actually make more sense to me.

That's why I actually enabled the other option which sets the refresh rate according to the video ('Adjust display refresh rate to match video') as I didn't really see the logic behind the other.

Can you clarify that?

**fritsch** · 2016-12-12, 09:46

No. On Jarvis it was not implemented properly. It used a timer and hoped that the gpu would swapbuffer accordingly - which (in short) did nothing with bypass renders.

We have a queue of decoded pictures. Those pics have a timestamp when there "start of rendering" should be, e.g.

[1,40,80,120,160] in a 25 fps video.

Now let's assume your refreshrate is 50hz, meaning your gpu is doing a swapbuffer 50 times a second anyway to drive the display refresh.
Now, we walk to this queue at 1,20,40,60,80,100,120,140,160.

1,20: display 1
40,60: display 40
... and so on.

That has the big advantage that we - as we are now - display driven can exactly enqueue whatever is currently right. We don't need to estimate next swapbuffers and enqueue what we think would come on display. The display drives us. You know, you cannot just wait "25 ms" and then think if you now call swapbuffers it will land on screen immediately.

So much about the Render Manager. Sync Playback to Display additionally measures swapbuffers "delays" and compensates audio so that the displayclock driven video and audio will be in sync. This especially helps if you run 50 fps at 60 hz or 24 fps at 60 hz. You know about the 3:2 Pulldown of earlier times, by hard coding pulldown? With this method described it works "automatically" as always the right frame is taken.

CiNcH · (This post was last modified: 2016-12-12, 13:41 by CiNcH.)

I wrote an EVR Custom Presenter myself so I know quite a bit about frame rendering, swapchains and synchronizing to the VSync.

Let's see whether I got you right...

Let's stick to your 25fps @ 50Hz example...

- In Krypton you put 50fps into the GPU driver queue which then does the swapping.
- In Jarvis the renderer times the swapping of the 25fps.

And when I enable 'Sync playback to display' in Krypton, I get the Jarvis behaviour with some A/V VSync synchronization?

**fritsch** · 2016-12-12, 13:46

No.

CiNcH · 2016-12-12, 14:12

OK. Created the ticket anyway. I don't have to know how it works. I report the numbers and you do the interpretation ^^ .

CiNcH · 2017-03-30, 16:28

I just want to add some new numbers, playing back 1080i H.264 on Android TV Marshmallow (Sony BRAVIA with MT5890 chipset)...

Kodi 17.1: 20% (surfaceflinger: 10%)
SPMC 16.6: 10% (surfaceflinger: 6%)
VLC: 8% (surfaceflinger: 4%)
MX Player (MediaCodec): 5% (surfaceflinger: 4%)
MX Player (libstagefright): 7% (surfaceflinger: 7%)

CiNcH · 2017-03-30, 17:20

Quite some threads running:

Code:
PID   TID    PR CPU% S     VSS     RSS PCY UID      Thread          Proc

31641 31753  0   7% S 1167636K 160744K  fg u0_a153  Thread-11316    org.xbmc.kodi

31641 14031  0   6% R 1167636K 160772K  fg u0_a153  Thread-11415    org.xbmc.kodi

1131   1131  0   4% S  117864K   9008K  fg system   surfaceflinger  /system/bin/surfaceflinger

31641 14067  1   2% S 1167636K 160772K  fg u0_a153  Thread-11417    org.xbmc.kodi

31641 31809  1   2% S 1167636K 160744K  fg u0_a153  Thread-11316    org.xbmc.kodi

30910 30910  0   2% S 1053000K  31592K  bg u0_a40   android.vending com.android.vending

31641  2038  0   1% S 1167652K 160788K  fg u0_a153  CodecLooper     org.xbmc.kodi

31641 31810  1   1% S 1167636K 160744K  fg u0_a153  Thread-11318    org.xbmc.kodi

2809   2809  1   1% S 1030928K 100456K  fg u0_a33   eanbacklauncher com.google.android.leanbacklauncher

31641 31836  1   1% R 1167636K 160744K  fg u0_a153  mali-renderer   org.xbmc.kodi

30762 30762  0   1% D       0K      0K  fg root     SonySOPQCtrlVdo

31641 31641  0   1% S 1167636K 160744K  fg u0_a153  org.xbmc.kodi   org.xbmc.kodi

CiNcH · (This post was last modified: 2017-05-01, 12:51 by CiNcH.)

I updated again the initial posting. I retested several apps with a 720p50 video (TS recording). I am now comparing CPU usage of the whole system, not just the player processes anymore as it turned out that there is also a difference conerning the burden that player apps put on other processes.

Conclusion is that Kodi does not run without problems on Sony and Philips Android TV with the low performance MediaTek SoCs, especially non-Surface mode eats up a lot of CPU time, which seems to perform way better in other media player apps though.

shomari · 2017-05-01, 13:57

How about with http://mirrors.xbmc.org/test-builds/andr...bi-v7a.apk

.. which is a work in progress, yes, but just for kicks you might want to look at that and gauge any differences[even if not to document, necessarily]. I've noticed a difference in cpu usage (different chipset) but in general the optimizations should benefit yours as well.

CiNcH · 2017-05-01, 18:00

Didn't improve CPU usage for me.

Video playback actually got worse (MediaCodec Surface). When navigating the KODI menu in parallel, video picture freezes every couple of seconds.

shomari · (This post was last modified: 2017-05-01, 18:44 by shomari.)

...wow. I wonder how that'll play out going forward, then.

edit: yup the gui causes slowdown with the latest vpupdate test build, but not with the first one.