• 1
  • 11
  • 12
  • 13(current)
  • 14
  • 15
  • 22
No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)
Thanks aron!

It works well. My setup went from dropping 50-60 frames during killasampla to zero dropped frames. While the CPU usage hovers at 90% on both cores.
Reply
Now that you guys have a patch to an unstable branch of ffmpeg that we WILL NOT BE INCLUDING until it is merged with ffmpeg HEAD, can we get back to finding a real solution to the problem?
Reply
althekiller Wrote:No, but you can diff the clean sources from ffmpeg that reside in the /vendor dir of svn with the ones in linuxport.

Sorry but i still don't know where i can find the diff file. Or it is already applied in the svn source ? If so why is it showing weird colors when we start ffplay -threads 2 enabled ?
Reply
alanwww1 Wrote:Sorry but i still don't know where i can find the diff file. Or it is already applied in the svn source ? If so why is it showing weird colors when we start ffplay -threads 2 enabled ?

No it's not, and it won't be because it's unstable. This is far more complex than the cabac patch.

Run all as root (sudo -s)

1. Download freshest SVN
2. cd to linuxport/XBMC/
3. run:
Code:
wget http://trac.xbmc.org/raw-attachment/ticket/5680/xbmc_ffmpeg_mt.patch
3. run(in linuxport/XBMC/):
Code:
patch -p0 < xbmc_ffmpeg_mt.patch
4.
Code:
./configure
5.
Code:
make -j2
(-j switch start 2 compiler threads, so it will compile faster)
6.
Code:
make install
Reply
Aron, you indicated earlier that this causes avi's to be a bit buggy. What did you mean by that? I'm curious to try your patch, but since a good deal of my files (tv mostly) are avi, I don't want to have to recompile twice (once for the patch, once to undo it).
Reply
Thank's Aron, but i asked Althekiller about xbmc's patch. It would still be good to make it clear why it is going with so bad performance under Intrepid.

I will also make a test if there is any performance difference with ffmpeg-mt patch applied in Hardy or in Intrepid. That would also tell us if it is effecting ALL ffmpeg versions or only the patch in xbmc.

I noticed a strange thing with SPEEDSTEP on two Intel based computers.

If i ENABLE speedstep i have the multithreaded performance dramatically BETTER.
If i DISABLE speedstep i have WORSE performance.

I really don't understand this. It is making differnce also in Intrepid and Hardy.

So anyone having speedstep disabled in BIOS should have it enabled for optimal performance.

It does not seem to be like that on windows. Somehow it is related to Linux kernel only.
Reply
fasteddy Wrote:Aron, you indicated earlier that this causes avi's to be a bit buggy. What did you mean by that? I'm curious to try your patch, but since a good deal of my files (tv mostly) are avi, I don't want to have to recompile twice (once for the patch, once to undo it).

If you directly replace the lib (avcodec) avi playback is buggy, but this is a direct patch.
I haven't noticed any problems with the patched version yet.

@alanwww1: I'm working on the main problem as well. I've created the patch because I don't have a cpu with large CPU clock. So decoding for me is slow, whatever kernel/distro I use. I understand that this patch will not be added, I endorse the decision, but if it helps anyone else it was worth creating it Wink
Reply
aron Wrote:I endorse the decision, but if it helps anyone else it was worth creating it Wink

Definetally ! It really is awesome ! I think i will use this patch in everyday xbmc usage, but anyway i also want to help Devs debugging the original issue.
Reply
I'm all for a permanent official solution, but in the meantime, my X2 6000+ 3.1Ghz is choking even on relatively low-bitrate 1080p blu-ray rips. If this can help in the short term, then it makes it a lot easier to wait on a better fix. Thanks for releasing this in such a user-friendly patch, Aron.
Reply
has anyone tried compiling with gcc4.1? could be the compiler change i suppose.
Reply
Great work guys -- haven't tested the patch but i will -- looks like a great interim solution for us people stuck on Intrepid.

Just thought i'd share - i know you guys had pretty much ruled out the scheduler as the problem - but i can completely confirm that CFS isn't the problem, i've just installed 8.10-server (which uses the Deadline I/O scheduler compared to CFS). Had exactly the same problem.

I might give trying to get intel HDMI audio working a rest and help look into this problem with you guys, (so fed up of alsa, xorg and eld patches now). problem is i'd have to install hardy on my laptop (hopefully that'd be similar enough to htpc hardware but able to run hardy) so think it prob be weekend.

Right going to try your patch Nod - keep up the good work

Quote:has anyone tried compiling with gcc4.1? could be the compiler change i suppose.

i will have a go now
Reply
Aron i tried the library copying thing you suggested previously but i had no luck.

I copied the libs from the 100% working Hardy install as follows. I also made the lmissing links.

Code:
lrwxrwxrwx 1 atti atti      39 2009-01-14 22:30 libasound.so -> /home/atti/libshardy/libasound.so.2.0.0
lrwxrwxrwx 1 atti atti      39 2009-01-14 22:30 libasound.so.2 -> /home/atti/libshardy/libasound.so.2.0.0
-rwxr-xr-x 1 atti atti 2883036 2008-12-29 22:31 libasound.so.2.0.0
lrwxrwxrwx 1 atti atti      43 2009-01-14 22:30 libdirect-1.0.so.0 -> /home/atti/libshardy/libdirect-1.0.so.0.1.0
-rw-r--r-- 1 atti atti   76120 2008-04-08 17:21 libdirect-1.0.so.0.1.0
lrwxrwxrwx 1 atti atti      45 2009-01-14 22:29 libdirectfb-1.0.so.0 -> /home/atti/libshardy/libdirectfb-1.0.so.0.1.0
-rw-r--r-- 1 atti atti  400488 2008-04-08 17:21 libdirectfb-1.0.so.0.1.0
-rw-r--r-- 1 atti atti    9684 2008-09-12 16:32 libdl-2.7.so
lrwxrwxrwx 1 atti atti      33 2009-01-14 22:29 libdl.so -> /home/atti/libshardy/libdl-2.7.so
lrwxrwxrwx 1 atti atti      33 2009-01-14 22:27 libdl.so.2 -> /home/atti/libshardy/libdl-2.7.so
lrwxrwxrwx 1 atti atti      43 2009-01-14 22:27 libfusion-1.0.so.0 -> /home/atti/libshardy/libfusion-1.0.so.0.1.0
-rw-r--r-- 1 atti atti   26704 2008-04-08 17:21 libfusion-1.0.so.0.1.0
-rw-r--r-- 1 atti atti  145232 2008-09-12 16:32 libm-2.7.so
lrwxrwxrwx 1 atti atti      32 2009-01-14 22:26 libm.so -> /home/atti/libshardy/libm-2.7.so
lrwxrwxrwx 1 atti atti      32 2009-01-14 22:26 libm.so.6 -> /home/atti/libshardy/libm-2.7.so
-rwxr-xr-x 1 atti atti  112354 2008-09-12 16:33 libpthread-2.7.so
lrwxrwxrwx 1 atti atti      38 2009-01-14 22:23 libpthread.so.0 -> /home/atti/libshardy/libpthread-2.7.so
-rwxrwxrwx 1 atti atti   30624 2008-10-03 12:57 librt-2.7.so
lrwxrwxrwx 1 atti atti      33 2009-01-14 22:22 librt.so -> /home/atti/libshardy/librt-2.7.so
lrwxrwxrwx 1 atti atti      33 2009-01-14 22:22 librt.so.1 -> /home/atti/libshardy/librt-2.7.so
lrwxrwxrwx 1 atti atti      41 2009-01-14 22:17 libSDL-1.2.so.0 -> /home/atti/libshardy/libSDL-1.2.so.0.11.1
-rw-r--r-- 1 atti atti  420376 2008-01-05 05:52 libSDL-1.2.so.0.11.1
lrwxrwxrwx 1 atti atti      41 2009-01-14 22:18 libSDL.so -> /home/atti/libshardy/libSDL-1.2.so.0.11.1

I run it with LD_LIBRARY_PATH="/home/atti/libshardy/" /usr/bin/xbmc
But i have no change. Still the same uneven core loading.
What am i doing wrong? I also checked with

Code:
export LD_DEBUG=files
LD_LIBRARY_PATH="/home/atti/libshardy/" /usr/bin/xbmc

Like this i can exactly follow while xbmc runs, when and what libs does it pull. It really pulls the exact libs i copied from Hardy. Maybe the file permissions or the owner could it be the problem ?
I am stuck a little...
Reply
alanwww1 Wrote:Like this i can exactly follow while xbmc runs, when and what libs does it pull. It really pulls the exact libs i copied from Hardy. Maybe the file permissions or the owner could it be the problem ?
I am stuck a little...

Try running:
Code:
LD_LIBRARY_PATH="/home/atti/libshardy/" ldd /usr/share/xbmc.bin
(xbmc.bin is the real executable)

This will print all the shared library dependencies of the app and the path of the libs. Check that all libraries replaced are found in /home/atti/libshardy/ .

+ I compiled xbmc under under hardy, so maybe that's the problem.
Reply
Yep, your patch helped. Now I can watch Dark Knight w/ zero (noticeable) dropped frames. I was missing a library, but other than that it all went smoothly. Thanks!
Reply
Just an FYI, there's no guaranty our frame counting code works with that patch.
Reply
  • 1
  • 11
  • 12
  • 13(current)
  • 14
  • 15
  • 22

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