• 1
  • 7
  • 8
  • 9(current)
  • 10
  • 11
  • 22
No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)
alanwww1 Wrote:The possible reasons:
- The new Completely Fair Scheduler CFS intruduced from 2.6.26 kernel, has a different method for load distribution to CPUs.

As far as i know:

the “Completely Fair Scheduler”, a new process scheduler introduced in Linux 2.6.23 that provides improved interactive performance.

http://news.softpedia.com/news/What-To-E...1246.shtml

According to the above doc. Hardy images contained the CFS. The main problem here is not scheduling, the threads are being forked but only one of them is doing the work under Intrepid.

After replacing the libs and compiling ffmpeg under a hardy chroot, I get better performance it seems like ffplay is working threaded but still video playback sometimes stalls...

However I'm still experimenting with some things ...
I will post the results I get Wink
Reply
Sorry, i thought it was only introduced in Intrepid...
Reply
Hmm, maybe I misread the doc I was reading. Regardless, you can clearly see that two threads are being spawned and doing work in top. The problem is that they are both doing the work on the same core.
Reply
Btw... if i compile XBMC version of ffmpeg and try to play a file with ffplay under intrepid using "-threads 2" parameter the video is buggy. In top I see that all cores are loaded, but it seems like only one cores decoded video is shown.

I'm not a pro in video decoding so maybe I'm wrong...
Reply
Playback for me is ridiculously slow for some content with lots of frames getting dropped. Weird thing is I get worse playback for some PAL Xvid content than for 720p H264.

720p H264 with Big Buck Bunny plays back pretty damn smooth with CPUs at ~30%/30%. This is in a .mov container. A few dropped frames.

720p H264 from recorded DVB-T content plays back reasonably with CPUs at ~60%/30%. This is in an .mpg container. More dropped frames than Big Buck Bunny.

1080i H264 (with PAFF interlacing) from recorded DVB-T content plays back choppy with CPUs at ~100%/65%. In an .mpg container. Huge number of dropped frames. FPS only ~19.

PAL 720x576 Xvid rip (MPEG4) has one CPU pegged at 100% with the other at ~10%. This is in an AVI container. Lots of dropped frames. This was silky smooth on the original XBox!

1080p H264 Killa Sample has one CPU pegged at 100% with other at ~20%. In an MKV container. Not too many dropped frames but playback is pretty choppy at only ~19FPS.

I'm running an ATI video system, but I'm not sure how much affect that has on playback. Similarly running AMD CPU and I don't know what impact that has. Many people suggest using Intel, but I had to find a mATX board with 2 PCI slots and DVI/HDMI out and there was bugger all choice with that requirement.

I can't believe the original XBox is whomping the 3.0Ghz CPU and 10 years newer GPU for playback of Xvid rips of PAL content.

HD 3200 / 780G graphics
AMD X2 6000+ (3.0Ghz)
2Gb RAM
ATI Catalyst 8.12 drivers
skiploopfilter set to 48 in advancedsettings.xml
VSync turned all the way on with Catalyst Control Center
VSync decided by driver in XBMC
Running SVN version of XBMC from 09-Jan.
My xorg.conf is pretty standard at the moment.

The code changes for number of threads doesn't seemed to have improved much.
Reply
You're using Ubuntu 8.10 and have something useful to offer this topic? Otherwise I'm moving that post to it's own thread. ATI is not under the gun here, nor will it be.
Reply
Yes, I'm using Mythbuntu 8.10. Post was mainly because I get completely different CPU core usage profiles depending on the content that is being played. Not sure if that information helps determine whether the issue is something to do with ffmpeg, or something else entirely. Xvid decoding has the worst CPU imbalance.

Question regarding ATI was mainly because I don't know what impact the GPU has on the performance.

Happy to create another thread regarding ATI performance in general if you think that is the better path.
Reply
Please do (and modify your previous), it has nothing to do with this thread.
Reply
What I don't understand is why the one Intrepid system I have used seems fine with even playback on both cores playing Killa. I have not had a chance to pull kernel info and what not from it but will try to remember to do so tomorrow and test again with Killa' as I compiled a new SVN pull tonight. Oddly it says compiled on the 6th of January and not tonight in the info screenHuh Frankly if it takes 3.1ghz to playback on Intrepid so be it as this software handles the newer hardware easily...

Having a heck of a time backing up my Hardy install though and finally had to switch to a different network share. It appears to be backing up now so I'll be yanking stuff out soon. I will be up pretty late swapping the hardware, dunno' if Intrepid will get on there tonight or not but I will do it ASAP. I will also backup the working Intrepid box first chance I get! Big Grin
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
Reply
What hardware doesnt Hardy support? It's only from July....

If its a problem with audio (over HDMI specifically) then just install the latest alsa.
Reply
motd2k Wrote:What hardware doesnt Hardy support? It's only from July....

If its a problem with audio (over HDMI specifically) then just install the latest alsa.

Audio is not a problem, or it is solvable by the latest alsa, but resume from standby is not working at all on Hardy with an asus p5n7a-vm (nforce 730i), while it is perfect on Intrepid.
Reply
I have been testing the XBMC PPA SVN Version today with a stock 2.6.28 kernel built using Debian infrastructure (only non standard config item was low latency desktop). With Killa Sampla, I get 120-150%CPU on my C2D 2.0GHz but still about 30% Idle CPU remaining. This is better than with the Stock Intrepid Kernel but still not optimal as it still does not use the whole CPU...

Now I will go on to build a stock 2.6.24 kernel by hand just to see what happens.
Reply
motd2k Wrote:What hardware doesnt Hardy support? It's only from July....

If its a problem with audio (over HDMI specifically) then just install the latest alsa.

Also i heard people ho has the new G45 chpipset which only works on newer kernels. And anyway we can't stay on Hardy forever. Need to find a way to make it work better on new kernels.

I did a test in Jaunty alpha 2 and has the same problem, maybe even worse. So it affects all kernels later than Hardy's !
Reply
aron Wrote:As far as i know:
the “Completely Fair Scheduler”, a new process scheduler introduced in Linux 2.6.23

Anyway i think CFS had a lot of updates since thans so i think we sould not take out this from the possible reasons of performance drops.

I found a thread about having different compile configuration from release to release . So i still think we could have this problem:

https://bugs.launchpad.net/ubuntu/intrep...bug/188226
Reply
Same story on kernel.org 2.6.24.7, not all CPU is being used but a lot more than on stock Intrepid kernel.

Is there any Kernel.org Version / Kernel Configuration combo known to work? I have no issues with building my own Kernel, but the current situation is deeply unsatisfying.
Reply
  • 1
  • 7
  • 8
  • 9(current)
  • 10
  • 11
  • 22

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