[alanwww1]

Hi,
I'm really interested in this issue as I'm getting an htpc this next week and I'm unsure of what distribution should I use. In any case, alanwww1 could you please post a link to the kerneltrap thread?
regards,

Hello Pilluli !

Thanks for help testing. Any new information or suggestion is very good.

Here is the kerneltrap thread i opened last night (no answer yet)

http://kerneltrap.org/node/16868

I really belive that a propperly tuned "Completely Fair Schedularer" in Intrepid could or should be as fast and balanced as the old one in Hardy. The other solution would be to revert to the old scheduler in the new kernels (if possible..) but than we would always need custom kernels for every version of new Ubuntu distros.

I read somewhere that there are a lot of tuning parameters for the new scheduler but this is way out of my knowledge.

[aron]

Hi all!

I downgraded to Hardy kernel manually, but I have the same problem. The video is still crappy,

Top looks like this:

Code:

6472 mmc       20   0  400m 139m  46m S 81.6  7.9   2:09.83 xbmc.bin                                                                                        
6477 mmc       20   0  400m 139m  46m R 65.9  7.9   1:48.19 xbmc.bin                                                                                        
6321 mmc       20   0  400m 139m  46m S 16.6  7.9   1:21.39 xbmc.bin                                                                                        
6478 mmc       20   0  400m 139m  46m S  9.3  7.9   0:17.64 xbmc.bin                                                                                        
6471 mmc       20   0  400m 139m  46m S  1.3  7.9   0:02.32 xbmc.bin                                                                                        
6474 mmc       20   0  400m 139m  46m R  1.3  7.9   0:01.58 xbmc.bin                                                                                        
6475 mmc       20   0  400m 139m  46m S  1.3  7.9   0:01.56 xbmc.bin                                                                                        
6476 mmc       20   0  400m 139m  46m S  1.3  7.9   0:01.58 xbmc.bin                                                                                        
6473 mmc       20   0  400m 139m  46m S  0.7  7.9   0:01.54 xbmc.bin                                                                                        
6479 mmc       20   0  400m 139m  46m R  0.7  7.9   0:01.62 xbmc.bin

I don't think this is a kernel issue, but I might be wrong

[alanwww1]

Hi all!
I downgraded to Hardy kernel manually, but I have the same problem. The video is still crappy,

I don't think this is a kernel issue, but I might be wrong

You have Intrepid, with downgraded kernel to 2.6.24 ? I did't know it is possible. Have you recompiled XBMC and the libs also ?

Anyway when i install Hardy from CD, it works fine. So it is really strange.

It is also importand in TOP that how the core utilizations stand. For me the threads share almost the same amount of CPU time, but the cores are loaded unevenly.

What i think would be a good test is to try the latest multihread patched mplayer on both kernels in benchmark mode. I think that could narrow down things as taking out the factors of opengl, menu handling sound playback, sound decoding etc.

My problem is i can not find the propper way to compile mplayer from source with the multiread patch.
All versions i compiled were single threaded or not frame-level multithreaded.

I found this script what automaticly downloads and compiles mplayer MT but i don't know how to use it.

http://gist.github.com/raw/24817/71937e2...9aa9c0e0f2

Please help with this so we could move on debugging.

[slash]

Hi,

I did upgrade my two machines to Intrepid and here are the results:

On my P4 HT 3.2 Ghz (HyperThread) : decoding is well balanced on the two CPUs.
On my C2Duo 2.6 Ghz : decoding is not balaced.

I don't know if my tests are relevent but shouldn't be results equivalent in both cases if it was the kernel?

[alanwww1]

Hi,
I did upgrade my two machines to Intrepid and here are the results:
On my P4 HT 3.2 Ghz (HyperThread) : decoding is well balanced on the two CPUs.
On my C2Duo 2.6 Ghz : decoding is not balaced.

I guess it is not the same situation because HT is a different story.
Have you checked to play "killa sample" on your 2.6Ghz C2D ? On that CPU on Hardy it's ok, but not on Intrepid there it's way slow.

[aron]

After I've installed ubuntu ffmpeg, I started an xterm and started to play with ffplay. And the same file I tried in XBMC seems to play fine with it. Only audio gets out of sync sometimes.

Code:

6895 mmc       20   0 92504  51m  13m R 99.9  2.9   8:13.41 ffplay                                                                                          
6894 mmc       20   0 92504  51m  13m S  2.7  2.9   0:10.86 ffplay                                                                                          
6892 mmc       20   0 92504  51m  13m R  0.7  2.9   0:02.28 ffplay                                                                                          
6893 mmc       20   0 92504  51m  13m S  0.7  2.9   0:02.70 ffplay

Seems to be an ffmpeg problem.

[alanwww1]

I think your ffmpeg version has no multithreaded x264 decoding. Only the latest versions with MT patch has multithreaded x264 decoding. This is what i want to try except i don't know how to compile it like i wrote in my previous post.

Try the "killa sample" it decides things.

[mr_raider]

I've been checking the folding forums, and most people report a drop in FOlding SMP performance from 8.04 to 8.10

http://foldingforum.org/viewtopic.php?f=...pid#p72581

[aron]

Playing the killa sample from Planet Earth with a lot of moving birds, uses 100% of the decoding thread so the video is crapy once again

Code:

/usr/local/bin/ffplay -threads 3 -skiploop 48 /storage/killa.sampla.x264.mkv

So ... yes I've got the latest SVN of ffmpeg with pthreads enabled, and libx264 from git.
So it should work in multi threads, instead it just forks the number of threads specified and uses one thread for decodeing.

Again strange ...

So XBMC is working good ( it's only a frontend ... but a very nice one ).

It has to be a kernel or ffmpeg problem.

[motd2k]

Its not the kernel.

[pilluli]

Hi guys,

A couple of things just to understand the problem a bit more before I can help test it in my hardware (still waiting for it to arrive though.. ) If I understand correctly xbmc ships with a fixed version of ffmpeg isn't it? :confused2:

So, to be sure, any of you guys has tried the exact same version of xbmc (and therefore the same version of ffmpeg) in both hardy and intrepid? If so then I guess we can rule out an ffmpeg or xbmc issue and look for differences in the kernel or other (libc,gcc) libraries ... :mad:

[aron]

If I understand correctly xbmc ships with a fixed version of ffmpeg isn't it? :confused2:

yep

Btw downgrading only the kernel did not do any good, so it's some library issue...
That's why XBMC in hardy worked for alanwww1.

[BLKMGK]

<snip>

BLKMGK - do you do a clean install from CD or a clean install of hardy then upgrade? I'm interested into why don't possibly see the issue.

Clean install of Intrepid. I can tell you my 65nm CPU drops frames at 2.66ghz and so did this C2D although I cannot recall if I tested it on both Hardy and Intrepid.

Frankly since I see pretty EVEN performance on Intrepid playing Killa' I do not think it's the .1ghz added speed making a difference. If folks are seeing 100% and 10% on their cores adding clock speed isn't going to change things Honestly in the end I care that it plays video smoothly and so far it does just that without issue including Killa'. <shrug>

So again, anyone else NOT seeing this issue? I guess this next board will be an interesting build - hope it doesn't display this but if it does I will image the other machine and see if the problem goes away

[althekiller]

BLKMGK, so you had no updates installed then? If that's the case, and you have the time, please install any updates XBMC might use one at a time and test.

aron, ffmpeg trunk doesn't have the cabac patch. Build ffplay from our ffmpeg sources in XBMC/xbmc/cores/dvdplayer/Codecs/ffmpeg.

I now agree with the others, this is unlikely a kernel related issue. It's time to start examining libraries.

[BLKMGK]

I cannot recall if I updated Intrepid, I believe I did but haven't in the last week or three. So far as I know none of the libraries that XBMC uses has been updated since I installed as there have been no additional libraries in the readme and I don't try to update those files often. XBMC however is rebuilt from SVN every few days on this box. I will be happy to try and figure out what's doing this, I may use Acronis to pull a snap from this box just to make sure I have a backup.

I am concerned that so many see this and I do not. I may try leaving this box's config alone and checking performance when I rebuild MY box as it's about to receive the same motherboard and CPU - I will look to see if there are pending updates though and note them. If the new build sees an issue and the old doesn't then it will be time to look for differences I think. I believe my testing was sound though - play the clip, look for dropped frames, observe the two CPU counters. Kind of hard to screw that up