No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)

Why do you keep comparing to windows apps? Give us results from mplayer and ffplay. In top you want to be looking at the process list, when you press play you'll see ~5more threads for xbmc.bin spawn, two of them will be using a lot of cpu (for h264 only). Audio decoding is negligible in comparison.

Sorry for mentioning windows. I came from windows world but i will never go back. I just picked up an FFMPEG using player, but i could have said XBMC under windows or XBMC under Hardy because there it all works fine. But a lot of perople having new hardware would like to use the new kernels and it will be more like this in the future and so far it not works ok on Intrepid.

Right but I'm fairly certain you're looking in the wrong place.

Give this a read.

http://www.phoronix.com/scan.php?page=ar...2008&num=1

You say that the only problem is that new kernels run XBMC slower ? So we just need a faster CPU to run it ?

I wonder if anyone was able to play killa sample without framerate drops on Intrepid and what hardware is he using.

Because the 3Ghz Core Duo is way too slow for this. We might need a 4Ghz processor...

Well, I was going to test on my Intrepid box but didn't have that sample and was seeing even loads on other flicks. Since this is apparently such a big deal I will take a copy of the clip over tonight and check it out to see if this occurs on the Intrepid box I recently built. I am pretty sure I tested this previously though when I was testing CPUs so I will be surprised if I see big drops at 3ghz...

Here is the killa sample:

http://rapidshare.com/files/82525583/kil...4.mkv.html

Anyway is this the ffmpeg patch included in XBMC ?

http://code.google.com/p/google-summer-o...z&can=2&q=

My Q6800 can play killa with 5 frames dropped (these are from the initial opening of the file i think) at stock clock.

The AMD 5000+ has no chance at stock. None. Its a 2.6Ghz processor, and i've got it ramped up to 3.25Ghz and it's still dropping ~150 frames.

motd2k Wrote:Edit2: Found a workaround. Line 152 in xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.cpp reads like this...

PHP Code:

int num_threads = std::min(8 /*MAX_THREADS*/, g_cpuInfo.getCPUCount()); 


Change it to this...

PHP Code:

int num_threads = std::min(8 /*MAX_THREADS*/, g_cpuInfo.getCPUCount()+2); 


and you should find it using much more CPU, also I found a fairly significant reduction in dropped frames.

I tried this and it actually helps a lot. Now i only have some few framedrops in the killa sample. The Dark Knight BD rip is actually playing without a problem.

I noticed a strange thing: Playing back the killa i checked in TOP pressing 1 then H to show threads that the two significant threads of xbmc.bin share almost evenly on CPU time BUT on top where i can see the utilizations, i still see uneven numbers. Like the cores were taking different amount of the two threads. One core is taking all of one thread and also some of the other thread and the other core just takes a few of one thread. It is really strange.

This compile option change might tell something to the Devs what we can play in config options to get better core share to reach the performance of the old kernels.

Screenshot of TOP with the strange situation (Threads 49%-45% ; CPUs 99% 13%)


I think the kernel tries to use as few cores as possible leaving the rest of the cores idle to make them downclockable. It is perfectly reasonable if we generally using the kernel for normal tasks. This way we have a 4 core or and 8 core processor used just as much core as it is nneded to fulfill a certain task. But with video decoding i think it's not good. We want to use the cores evenly loaded, better have the two main threads stayed exclusively on one a specific core.

Maybe there is a kernel option for this, how the user want to optimalize his cpu core usage. I think this could be the difference of Hardy and Intrepid kernel that Hardy did not have this so called "energy optimalized" cpu usage. (I already tried to disable powernowd and also speedstep in BIOS with no change)

I tested it with 8.10 on a 2.5Ghz AMD X2. I have no HD content other than the "killa sampla" you guys seem to love.

For SD (MPeg-2), there is a slight imbalance of load between the two CPUs, but it's not flagrant, i.e. maybe 60%/20%. It does vary a lot, and XBMC reports similar numbers to top, with slight delay.

I have 4-6 threads spawned for xbmc.bin, but the first on is 50% of CPU, the 2nd one is 10-15%, and the last two are minimal.

For the killa sampla, the imbalance is more obvious (i.e. 90/10) by the end of the clip.

Since I don't view any h264 content, I am hesitant to recompile, as finally got a build that works properly with pulse audio. Let someone else be the guinea pig.

By the way, disabling CPU throttling helps a lot in the drop frames department.

alanwww1 Wrote:I think the kernel tries to use as few cores as possible leaving the rest of the cores idle to make them downclockable. It is perfectly reasonable if we generally using the kernel for normal tasks. This way we have a 4 core or and 8 core processor used just as much core as it is nneded to fulfill a certain task. But with video decoding i think it's not good. We want to use the cores evenly loaded, better have the two main threads stayed exclusively on one a specific core.

Maybe there is a kernel option for this, how the user want to optimalize his cpu core usage. I think this could be the difference of Hardy and Intrepid kernel that Hardy did not have this so called "energy optimalized" cpu usage. (I already tried to disable powernowd and also speedstep in BIOS with no change)

No. Please get ahold of some operating systems and computer architecture textbooks and give them a read before making any more outlandish assumptions. At least read up on the new linux process scheduler (it's called The Completely Fair Scheduler or CFS). It was enabled by ubuntu in 2.6.26 IIRC. It's not the job of the sch...

...my rant may have sparked an idea as to the cause. If the scheduler takes into account cache coherence, and there is significant spacial locality, it may stick both threads on the same core in an attempt avoid having the same data in multiple caches. Off to read myself...