[aron]

Only with the old Hardy 2.6.24.x kernels work ok.

I have:

Code:

Linux aron-desktop 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 2008 i686 GNU/Linux

I've compiled xbmc/ffmpeg (xbmc version) under Hardy and I get the same results as in Intrepid with the replaced libs. Under Hardy playback is better using ffplay/xbmc (less dropped frames)

Code:

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

Maybe your processor is faster an you are still using one core for processing the video, just not noticing it because of the simpler, smaller libs.

Try playing the sample with ffplay -threads 1 and see if it plays the same as in xbmc.

ffmpeg-mt is working fine playing the sample and other 1080p/i videos.

I dont't really know what to think now ... I don't think it's a kernel problem or lib problem.
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.

So this is good, real good, but not ideal. (for me)
Ones who have a faster cpu it's not a problem, but those who have slower cpu with >2 cores, this becomes a problem, because the first thread does not have the necessary resource to decode the data.
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.

Which libs you copied to where to make Intrepid work like in Hardy ? Was it ffplay worked for you or xbmc ?

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

Playing "The Dark Knight" went real good, and the sample played far better.

Still when there is lot of motion the video stalls for a few msecs.
In top I see that before the video stalls the first thread uses 99% CPU, then it drops.