[alanwww1]

Code:

model name    : AMD Phenom(tm) 8450 Triple-Core Processor
cpu MHz        : 2100.130

Yes i think your CPU is only sufficient if you have a decoder using at least 3 threads. Even if a two threaded decoder works 100% fine two cores with that clock are not enough for propper decoding.

This cabac patch:
1. decodes the video in the first thread
2. at the same time it does prediction idct deblock in the secod thread (I think this is called Entropy-decoding)
This is why using -threads is not working.

Yes i just read that also in the DVDVideoCodecFFmpeg.cpp file. I think the future is frame based multithreading as in the market there will be CPUs with more and more cores with lowered clock rates.

I'm going to try to make a patch to the ffmpeg XBMC uses to make it frame based.
Maybe I'm wrong, so we need a dev or somebody with a better knowledge to confirm this.

I thought about the same thing but Althekiller clearly told me that they won't use this branch because it is not stable. I think it looks pretty alright and at least we could find out together with Devs a way how to experimentaly implement it instead of the existing ffmpeg version. I Thought we could try to just copy the source to xbmc's ffmpeg dir and see what happens when it is compiled.

After changing the libs that I've posted in one of my previous posts, playing with ffplay and xbmc was smoother under intrepid.

Can you help us if you have time to make this a little more precise how you did it. For me and all of us how are not into such hardcore linux things. Have you overwritten the libs in Intrepid ? Are these libs in /lib directory ? Isn't it a problem if the version numbering is different (for example libpthread) ? After that it effects both ffplay and xbmc ? I intend to check which particular lib is responsible for this so Devs can track it down what shuld be changed in the code to make it work with the default Intrepid libs.

Thanks for all your help so far.