• 1
  • 9
  • 10
  • 11(current)
  • 12
  • 13
  • 22
No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)
If anyone had the ruby script not working, i discovered that i left out packages git-core and subversion build-essential from install. So run:

sudo apt-get install git-core subversion build-essential

before running the script.
Reply
The patch in the attachment of the mail as is stated clearly in the body. I have no idea if that will apply directly or not as a lot of stuff in the h264 decoder has changed since this was applied. I know mplayer uses its own branch of ffmpeg as well so applying there might not be straight forward either. Regardless, I see this whole foray as slipping off topic. Aron is on the right trac with testing the hardy libraries.
Reply
althekiller Wrote:I have no idea if that will apply directly or not as a lot of stuff in the h264 decoder has changed since this was applied.

Thank you for the info, but i don't get it. You say there is an old patch from 2007 and a lot of code changed from that time, but how you apply this patch to your current ffmpeg libs in XBMC ? Or there is a version or branch of ffmpeg where this patch is already applied and was developed that way ? Sorry for being a little problematic, but i might take us somewhere to check things outside xbmc to narrow down problems.
Reply
If your lucky maybe just apply manually with text editors that is if only line numbers etc has changed.
otherwise you need to rewrite the patch to match the newer code.
Reply
dizzey Wrote:If your lucky maybe just apply manually with text editors that is if only line numbers etc has changed.
otherwise you need to rewrite the patch to match the newer code.

Tha's ok. But how it ios applied in xbmc with current ffmpeg revisions ?
Reply
I tried to get Aron`s results with compiling ffmpeg from xbmc`s source code. I configured it with --enable-pthreads compiled but,

When i try ffplay -threads 2 killasample.mkv

i have weird colorful picture while playing, getting the following error message:

[h264 @ 0x88d0a10]number of reference frames exceeds max (probably corrupt input), discarding one
[h264 @ 0x88d0a10]Cannot parallelize deblocking type 1, decoding such frames in sequential order

Am i making something wrong ?

(same result on Hardy and Intrepid)
Reply
alanwww1 Wrote:I tried to get Aron`s results with compiling ffmpeg from xbmc`s source code. I configured it with --enable-pthreads compiled but,

When i try ffplay -threads 2 killasample.mkv

i have weird colorful picture while playing, getting the following error message:

[h264 @ 0x88d0a10]number of reference frames exceeds max (probably corrupt input), discarding one
[h264 @ 0x88d0a10]Cannot parallelize deblocking type 1, decoding such frames in sequential order

Am i making something wrong ?

(same result on Hardy and Intrepid)

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%.
Reply
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. Huh
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...
Reply
alanwww1 Wrote:That's why it would be good to compile properly the ffmpeg version xbmc includes...

These are the configure parameter XBMC uses to compile ffmpeg:
(it's in build_xbmc.sh)

Code:
./configure --extra-cflags="-D_XBOX" --enable-shared --enable-postproc --enable-gpl --disable-static --disable-vhook --enable-swscale --enable-protocol=http --disable-altivec --disable-ipv6 --enable-pthreads --disable-debug

Btw.. I get something like this if it helps:
Image
Reply
Yepp !

I have the same trance-likeSmile picture. But only with threads enabled.
Surely we need some help from Devs how to do it.

Have you tried the ffmpeg-mt branch ( http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt ) for me it works under Intrepid compiled with mplayer.
Reply
Strange ... I downloaded Hardy and installed on the same hw and still video plays stalled. The threads are 55% 61%, though playback is better under hardy.
Playback is exactly the same as under Intrepid after replacing the libs.
Hardy installed with no update.

Kernel: 2.6.24-19-generic SMP

@alanwww1: what kernel do you have installed? What media have you used to install it? ffmpeg-mt works for me real good ...
Reply
I tried every possible existing kernel for Intrepid and also for new Jaunty alpha. I tried Kubuntu Live CD, Ubuntu LiveCD, Ubuntu Alternate with minimal install (only Xorg, no graphical user interface), Ubuntu Server CD

ALL kernel verions with ALL types of distros with the 2.6.27.7 or 9 or 2.26.28.x kernels has the same problem. Only with the old Hardy 2.6.24.x kernels work ok.

Which libs you copied to where to make Intrepid work like in Hardy ? Was it ffplay worked for you or xbmc ?
Reply
alanwww1 Wrote: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. Wink

Quote: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" Big Grin 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.
Reply
aron Wrote:
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.

aron Wrote: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.

aron Wrote: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. Wink

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.

aron Wrote: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.
Reply
Using "ldd": ldd /usr/local/bin/ffplay
It gives you a list of dynamically loaded libs.

Copy them to a separate directory, and override the search path with
LD_LIBRARY_PATH="/hardy_libs/" /usr/local/bin/xbmc

( http://forum.xbmc.org/showpost.php?p=266...stcount=98 )

Big Grin

By the way, compiling ffmpeg-mt and the replacing /usr/local/share/xbmc/system/players/dvdplayer/avcodec-52-i486-linux.so with /usr/local/lib/libavcodec.so.52.7.0 gives us frame-based multithreading under XBMC Wink But replacing the lib is not the right way...

The right way is to create a patch, so it can be applied to XBMC ffmpeg source.
Reply
  • 1
  • 9
  • 10
  • 11(current)
  • 12
  • 13
  • 22

Logout Mark Read Team Forum Stats Members Help
No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)1