[nipnup]

I understand it is slightly offtopic, but while I can get relatively good decoding performance out of the ffmpeg-mt patch on my lowly 2.3GHz X2 (enough for 720p which is all my display can do, anyway), I also get pretty bad tearing with it (Nvidia 8200). Anyone else seeing this?

Maybe I'll just go back to the ExternalPlayer hack and use vdpau....

[fasteddy]

I understand it is slightly offtopic, but while I can get relatively good decoding performance out of the ffmpeg-mt patch on my lowly 2.3GHz X2 (enough for 720p which is all my display can do, anyway), I also get pretty bad tearing with it (Nvidia 8200). Anyone else seeing this?

I'm using an onboard 8200 with the latest driver (180.22) and I don't get any tearing (I'm using an X2 3.1GHz). However, I have noticed that this patch has reduced stability a little. I get occasional crashes if I skip several times in a row (perhaps related to althekiller's point about frame counting?). Overall, though, this is a minor inconvenience, as I don't tend to use skip all that often.

[alanwww1]

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 did the following:

I have dualboot for Intrepid and Hardy, Both has xbmc final 8.1 installed (not the svn)

So far everything works as excepted(Hardy: OK, Intrepid: crap)

I copied the libs related to ffplay from Hardy's partition to a temp dir on Intrepid's partition. I copied most from /lib, some of them i found in /lib/tls/i686/cmov and /usr/lib.

Then i used the magic command:

export LD_DEBUG=files
LD_LIBRARY_PATH="/home/atti/temp/" /usr/bin/xbmc

from the debug i see that xbmc uses ALL the copied libs from Hardy partirion. But... The performance and everything remains the same crap.

I also tried to copy the whole /usr/share/xbmc dir from Hardy partition to Intrepid's. Still no change.

Than i tried to copy the rest of the libs which xbmc uses but ffplay doesn't. It gave me a segmentation fault when i ran xbmc. I removed some of them eg. libc.so.6 libgl.so.1. from the temp dir so that i don't get segmentation fault. But still no change at all. Bad performance on Intrepid.

Now i really don't know what to think where the problem really is. The only thing differs now is the kernel, drivers and some libs and kernel modules. Someone reported to downgrade Intrepid's kernel to Hardy's version with no luck. So we can take out kernel difference. Someone reported the same problem with Intel integrated video. So we can take out nvidia kernel module.

Maybe Aron could help, because he reported to have it working under Intrepid with the lib exchange method i also used. But i don't know why it is not working on mine. Maybe he also did something else which i didn't.

What have i made wrong Aron ? Please help !

[erix]

There seems to be the same problem also on XBMCLive with 2.6.24-19-generic kernel.

I have built XBMC from SVN with this patch on XBMCLive and I can notice considerable improvement in performance of 1080p playback.

I have an AMD 64 X2 6400+ CPU and couldn't play that killa.sampla smoothly, lot of dropped frames. After this patch it looks OK to my eyes (also the dropped frame counter looks OK).

-erix-

[tslayer]

Ya, but as one of the previous folks mentioned, try skipping or ffwing a few times. It will crash.

Otherwise, yes, nice improvement in performance.

[aron]

Ya, but as one of the previous folks mentioned, try skipping or ffwing a few times. It will crash.

Otherwise, yes, nice improvement in performance.

Yep!

Skipping while playing mkv files does not crash ffmpeg (at least for me it doesn't), but skipping while playing formats does crash xbmc.

I'm working on a way to fix this issue...

[alanwww1]

Aron, if you have a little time can you check what i made wrong with lib changing. I want to check which lib is responsible for the bad performance in Intrepid.

http://forum.xbmc.org/showpost.php?p=270...tcount=198

Thanks !

[[Ad0]]

I finished the patch ...

Really well done!!! My previously choppy 1080p now plays smooth!

[BLKMGK]

Okay... now I think I am seeing this too on the new build -WTF?!

Differences between previous and this one...

1) This one likels used a newer ALSA update script but nto by much.
2) This one had options snd-hda-intel model=6stack-dig placed in the /etc/modprobe.d/alsa-base file. Previous had an .asoundrc file created.
3) This one has working code to underclock the CPU as needed, other machine is overclocked and cannot clock down per the BIOS settings.

I think those are the only differences. I may take a portable drive over and image that other machine to try that image here just to see. That one has navigation audio but no stereo output, this one has stereo output at 48khz (chipmunks), working 5.1, and no nav sounds.

Is weird, CPU will be balanced, then one begins to take over, then it drifts back the other way and the previously undertasked core gets heavily tasked. I may overclock this sucker just to see if that fixes it which might point to the CPUNow stuff maybe. <shrug>

[alanwww1]

I made some testing.

I was able to compile ffplay from xbmc's ffmpeg version with (and that was the key)

./configure --extra-cflags="-D_XBOX" --enable-pthreads

And on Intrepid i have a 100% working ffplay with cores evenly loaded playing killa sample with no framedrops !

So with tge SAME hardware, SAME original kernel, SAME original libs, SAME compile options, SAME ffmpeg version,

ffplay works under Intrepid,
Xbmc works properly only under Hardy, but still not under Intrepid

Maybe the difference is the way xbmc calls the libavc codec compared to ffplay.

[pilluli]

Hi alan,

I made some testing.

I was able to compile ffplay from xbmc's ffmpeg version with (and that was the key)

./configure --extra-cflags="-D_XBOX" --enable-pthreads

I was able to compile ffplay as you suggested. However, how do you see the dropped frames in ffplay? To be honest I see more or less the same jerkiness in the killa sample using xbmc and ffplay :-?

[alanwww1]

Sorry i just realized that it was the patched source i took out from xbmc source and that one i compiled. Of course it was ok with h264.

But now i tried the clean xbmc source both compile on Hardy and Intrepid and now it still has the same problem as XBMC has.

While playing you could open up a new terminal and run top. There you press key "1" to make it show the core loads separately. Than you press shift+h to show the individual threads.

This is how i check if things are ok or not. On Hardy the cores are 90-90 % on Intrepid it is 90-10 % while playing back killa
Don't care about the actual picture as ffplay use a very primitive methot of displaying the frames and it make things look lot worse than it actually is. So only check the core utilizations !

Now i try to disable as many things in ffplay as possible (for example network, audio etc.) and compile it with --disable-shared option. This way i get a minimized ffplay with libavc integrated just to check what running differently with the two distros. This way i will try to check each libs it loads while playing back the stream searching for one which is different. The problem is it loads a lot of libs (30-50). You can check what libs and files it uses typing

export LD_DEBUG=files
ffplay -threads 2 /home/user/killa.mkv

beforre running the command. It would be welcome if you could also try figuring out what runs differently with Hardy and Intrepid.

[alanwww1]

I realized some notable difference in running ffplay on Hardy or Intrepid.

Running the same code on Hardy and Intrepid there is one library which is used on Intrepid but not used on Hardy:

librt.so.1

Does anyone know what this is used for ? Why is it not used on Hardy and why used on Intrepid ?

Could this point to some difference why we are having bad performance on Intrepid.

I found out anyway that it does not matter if the loads are balanced or not over the cores. What matters is that the sum of the two core utilization seem to be under 100-120% under Intrepid while on Hardy it is somewhere 170-190% under full load.

So it is not the lack of multithreading or multi core usage we have but the problem is that the video decoding threads are running sequential: somehow the data exchange between the threads is not working properly and one thread waits for the other thread to be ready and so on.

If we could know more about the way this CABAC patch working form Devs we could maybe move foreward to test further things.

[spozen]

So the only issue with arons patch is that it will crash XBMC when FF SD material?

And how do i get rid of it when you guys find a real solution? (no offence, i appreciate your work aron)

[fasteddy]

So the only issue with arons patch is that it will crash XBMC when FF SD material?

And how do i get rid of it when you guys find a real solution? (no offence, i appreciate your work aron)

You can just delete your XBMC directory (not ~/.xbmc) and check out the SVN again. Configure, make, make install as normal.