[aron]

I have the same problem with XBMCLive ... Ubuntu 8.04 2.6.24-19-generic kernel

[althekiller]

nipnup, please elaborate on just what "not all CPU is being used" means. Are you seeing the unbalanced load distribution or something else? Be descriptive, we can't read your mind.

[nipnup]

Basically, I get somewhere around 20-30% idle CPU (on a 2.3GHz Athlon X2). The two decoding threads are not entirely balanced but close enough on 2.6.28 but it is unclear to me why there is any idle CPU left (when clearly the video is not playing at full frame rate)? Could there a synchronization issue between the two threads that makes em wait?

[althekiller]

Yes, a lot of things can cause the video playback to be poor. Many of which throwing CPU at won't fix. We sync off the audio clock so if that's not stable the video won't be either. Regardless, so long as the cores usage is balanced, that's what we're looking for here.

[aron]

althekiller: Can you please tell me where can I find this cabac patch for FFMpeg ? Don't seem to find a working one ...

Thanks

[althekiller]

Seems it was accepted into mainline sometime in september. Frame based parallelism is currently on the chopping block.

[alanwww1]

Aron !

I think you are looking for this one. It is ffmepg from MT (multithread) branch:

just get it like this:
git clone git://gitorious.org/ffmpeg/ffmpeg-mt.git ffmpeg-mt

./configure --enable-pthreads
make
sudo make install

ffplay will be under /usr/local/bin

It really makes as threads as you set. I checked it in TOP. CPU usage is pretty even. I will further investigate.

I want to try it with mplayer so we can check framerate and other information while playback. I can't find a way hot wo use the ffmepg-mt libs in mplayer.

[althekiller]

If you're going to do stuff with mplayer make sure to pass it "-demuxer lavf" so you use ffmpeg's demuxer.

[alanwww1]

YES ! I did it with mplayer using the multithreaded ffmpeg branch libs.

On Intrepid, with the same 3ghz C2D machine where on xbmc i had more than hundred dropped frames:

I made a Ruby script for complete download configure and installation of mplayer with ffmpeg-mt libs and patched using the libs properly.

here you can download it:

http://rapidshare.com/files/181922417/in...ayer-mt.rb

After that you have to
sudo apt-get install ruby git-core subversion build-essential
sudo apt-get build-dep mplayer
sudo ruby inst-mplayer-mt.rb

It is ready for use !

You can try killa the following way:

mplayer -demuxer lavf -vo gl2 -fps 25 -lavdopts lowres=1 -lavdopts threads=4 killa.sampla.x264.mkv

You will have no droppped frames and 60-75% CPU usage EVENLY distributed between the cpu cores on a 3ghz C2D

So i think we just need to know the difference netween this ffmpeg version and the version in xbmc and we are there.

Please test it, if you have time !

[althekiller]

We don't use ffmpeg-mt so I'm not sure where you hope to get with this.

I've misread and the cabac patch that we used has not been accepted into ffmpeg. Though I did read something about slice based parallelism of cabac_residual so who knows... Regardless, the patch is here http://lists.mplayerhq.hu/pipermail/ffmp...35877.html .

[alanwww1]

We don't use ffmpeg-mt so I'm not sure where you hope to get with this.

I mean xbmc uses ffmpeg's libavc codec for h264 decoding right ? This ffmpeg version's libs really use as many threads as you wish and utilizing the cores very well. Even on Intrepid.

http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt

Am i totally wrong checking this out ?

[althekiller]

As far as this thread is concerned, yes. What you have is Alexander Strange's GSoC playground for generic frame based multi-threaded decoding. We won't be using it until it is merged back to ffmpeg trunk, which AFAIK there is no ETA on. Last I heard the all of the codec specific stuff still needed done.

[alanwww1]

I saw that there is already and ffdshow-mt codec for windows based on this branch and what i read is it has great performance over the other h264 decoders under win.

http://www.xvidvideo.ru/content/category/1/40/30/

[althekiller]

You aren't going to convince us to start using an unstable branch that will at some point or another be merged or abandoned (last commit sept 15 2008!) just to cover up the underlying cause of another problem. Please stay on task.

EDIT: Oops clicked the 2 instead of the one, dec 24th isn't that bad still not going to happen.

[alanwww1]

You aren't going to convince us to start using an unstable branch...

It's all your decision as you have all the real knowledge about the whole situation. With this expriment we at least see that with a different ffmpeg version we have a working multithreaded decoding, which could mean that we have to look for the solution around ffmpeg compiling on Intreid.

For further testing, can you help us more about the patch you are using. I did not found the actual patch following the link you mentioned. I would like to try it with mplayer to check some things if possible.

Thank you one again for your attention to this problem !