2009-01-12, 14:36
aron Wrote:No you don't ... I have the same problem too, thats why I asked for the patch. I don't think this is normal.
I didn't have the time to do any testing with older hardy libs but I will go for it today ...
Using it without -threads under intrepid uses 2 cores but under hardy it uses one core only at 100%.
You also have the weird colors ?
I think the FFMPEG which is in XBMC should have tha patch already applied. So anyway i am a little bit confused now.
Have you got any ffmpeg version working ok on Intrepid, with threads 2 option and with no weird colors ?
I still don't know how much multithreading is done with the different ffmpeg versions. From the CPU utilizations for example i see in XBMC Intrepid that it has at least two threads, but the threads are working sequential actually. So one thread is 50% the time doing his job, but the rest of the 50% it just waits for the other thread to be finished. I think this is exactly the problem we have in xbmc Intrepid now. The question is that why we don't see this problem on Hardy. One answer could be that on Hardy we have the exact same problem, the only difference is that somehow it don't eats up so much resource so the CPU could decode the stream even with the sequential (semi multithreaded) way.
That's why it would be good to compile properly the ffmpeg version xbmc includes...