No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)

  Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
BLKMGK Offline
Donor
Posts: 1,738
Joined: Jul 2006
Reputation: 4
Location: USA Virginia
Post: #16
I guess the question is do we drop more frames on same content on 8.1 Intrepid vs earlier 8.04 Hardy?

I have just pulled trigger on the new ASUS board for HDMI output so I'll have something here to test soon enough. I am also taking some BD rips over to the other machine so I can test on it too. If there's anything I can do to help I will be happy to try - not sure I am quite up for kernel recompile though without the EZ-bake version of the directions <sigh>

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)
find quote
althekiller Offline
Team-XBMC Developer
Posts: 5,001
Joined: May 2004
Reputation: 12
Post: #17
mr_raider Wrote:If look at gnome system monitor, the load is balanced. I think this is just XBMC misreporting the CPU loads.
We get the loads directly from the OS, so the kernel would have to be lying to us.
BLKMGK Wrote:I guess the question is do we drop more frames on same content on 8.1 Intrepid vs earlier 8.04 Hardy?
Yes.
find quote
alanwww1 Offline
Team-XBMC Member
Posts: 1,360
Joined: Nov 2008
Reputation: 33
Location: Hungary
Post: #18
So it's not the lack of real multithreading the problem, but the worse resource utilization on Intrepid vs. Hardy kernel ?
find quote
alanwww1 Offline
Team-XBMC Member
Posts: 1,360
Joined: Nov 2008
Reputation: 33
Location: Hungary
Post: #19
I tried the latest Jaunty alpha Kernel, with the latest XBMC SVN and...

well not so obviously like with Intrepid but still the performance is a lot worse. A lot of dropped frames with the 1080p content played without a dropped frame on Hardy.

I really can't belive that even with a 3Ghz Core 2 Duo CPU one can not play a 1080p movie without droppped frames, whilest the same movie is perfectly playable on the windows version of XBMC on a 2Ghz CPU with 70% utilization.

If i do the math, i can not come down to any other problem that (whatever the core utilizations show in XBMC) the video decoding is working single threaded on kernels newer than 2.6.24. I still think it is some compile option we need to change for ffmpeg to cope with the new kernels.
find quote
mr_raider Offline
Senior Member
Posts: 105
Joined: Dec 2008
Reputation: 0
Post: #20
Have any of you tried it with the CPU set at full, i.e. Performance mode, or disable Cool N Quiet?
find quote
alanwww1 Offline
Team-XBMC Member
Posts: 1,360
Joined: Nov 2008
Reputation: 33
Location: Hungary
Post: #21
mr_raider Wrote:Have any of you tried it with the CPU set at full, i.e. Performance mode, or disable Cool N Quiet?

It is all working fine on Hardy and windows speedstep enabled and ondemand mode. It is no difference.

Whatever you set for Intrepid or Jaunty the result is the same.
find quote
althekiller Offline
Team-XBMC Developer
Posts: 5,001
Joined: May 2004
Reputation: 12
Post: #22
WRONG, as I said before the decoding _IS_ still threaded. Halt execution with a debugger and have a look at the threads, there are three from libavcodec. The problem is that they are apparently being scheduled to the same core for some reason, which ruins the whole parallel thing. Have a dig through LKML and look for changes involved in the process schedulers. Also find out _which_ scheduler Ubuntu is using and what applicable patches if any they are making to the kernel. It would also be interesting to see results from similar kernel versions on other distros.
find quote
alanwww1 Offline
Team-XBMC Member
Posts: 1,360
Joined: Nov 2008
Reputation: 33
Location: Hungary
Post: #23
althekiller Wrote:WRONG, as I said before the decoding _IS_ still threaded. Halt execution with a debugger and have a look at the threads, there are three from libavcodec. The problem is that they are apparently being scheduled to the same core for some reason, which ruins the whole parallel thing. Have a dig through LKML and look for changes involved in the process schedulers. Also find out _which_ scheduler Ubuntu is using and what applicable patches if any they are making to the kernel. It would also be interesting to see results from similar kernel versions on other distros.

Thanks for the info. I will try to make a test on latest Fedora. Also i think it would be interesting to test mplayer paying the same files on both kernels.
find quote
mr_raider Offline
Senior Member
Posts: 105
Joined: Dec 2008
Reputation: 0
Post: #24
althekiller Wrote:WRONG, as I said before the decoding _IS_ still threaded. Halt execution with a debugger and have a look at the threads, there are three from libavcodec. The problem is that they are apparently being scheduled to the same core for some reason, which ruins the whole parallel thing. Have a dig through LKML and look for changes involved in the process schedulers. Also find out _which_ scheduler Ubuntu is using and what applicable patches if any they are making to the kernel. It would also be interesting to see results from similar kernel versions on other distros.

Then why would affect XBMC only? I'm running Folding@home SMP on Ubuntu 8.10 and it's distributing all four processed evenly on both cores of my x2 4200?
find quote
althekiller Offline
Team-XBMC Developer
Posts: 5,001
Joined: May 2004
Reputation: 12
Post: #25
I dunno, maybe we do some stupid shit in our winapi emulation. It obviously doesn't do this on all apps it could be something to do with thread priorities. More experimentation is needed to narrow it down, I'll leave it to you guys. Wink I'd start with google.
find quote
theuni Offline
Team-XBMC Communication Manager
Posts: 1,105
Joined: Oct 2007
Reputation: 2
Location: Atlanta, Ga, USA
Post: #26
Just upgraded my gentoo box to 2.6.27 and I notice no difference (was 2.6.26 before). CPU load is still split pretty evenly for me. I dare to disagree with AlTheKiller... I still believe it could be a kernel option change (assuming the problem is a kernel upgrade at all. I'm also assuming that those who upgrade their kernel upgrade their ugly proprietary video drivers as well.)

Rather than quote myself... see here

I'd really like to see how the new kernel with old options performs.

TheUni
find quote
BLKMGK Offline
Donor
Posts: 1,738
Joined: Jul 2006
Reputation: 4
Location: USA Virginia
Post: #27
FWIW, a BRIEF test tonight on a BD rip I recently did had even CPU usage across cores. It was a dance scene at the start of Another Cinderella Story (stop snickering it was handy and the kids want it). NOT the toughest clip most likely but lots of movement and CPU cores got up over 40%. I WILL try Killa' on that box again soon. I have also ordered new hardware for my box and should have it installed by next weekend for testing. The box I tested on tonight was a full normal Ubuntu 8.1 install - nothing strange but newest ALSA and the repository NVIDIA drivers. We'll see how my box works out, I may try an "upgrade" of Ubuntu just for fun Wink

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)
find quote
alanwww1 Offline
Team-XBMC Member
Posts: 1,360
Joined: Nov 2008
Reputation: 33
Location: Hungary
Post: #28
BLKMGK Wrote:FWIW, a BRIEF test tonight on a BD rip I recently did had even CPU usage across cores. It was a dance scene at the start of Another Cinderella Story (stop snickering it was handy and the kids want it). NOT the toughest clip most likely but lots of movement and CPU cores got up over 40%. I WILL try Killa' on that box again soon. I have also ordered new hardware for my box and should have it installed by next weekend for testing. The box I tested on tonight was a full normal Ubuntu 8.1 install - nothing strange but newest ALSA and the repository NVIDIA drivers. We'll see how my box works out, I may try an "upgrade" of Ubuntu just for fun Wink

Hello Blkmgk !

Thanks for helping out testing here.
You say you have Intrepid with Alsa 1.017 or 1018a ?
I did a test last night with the latest mplayer build (without enabling VDPAU) and there i also got the same (bad) uneven cpu load share. The sample i used was the begining part of The new Dark Knight movie in 1080p with a very high bitrate. (Which perfectly plays for example on XP with FFDSHOW codecs which as i know also FFMPEG based)

It is really strange having the nativly linux based ffdshow performing twice better on damned windows than on Linux !
find quote
motd2k Offline
Team-XBMC Developer
Posts: 666
Joined: Dec 2008
Reputation: 0
Location: England
Post: #29
Is anyone having this trouble running on an Intel CPU? My Q6800 runs with all 4 cores pretty even, but my dual core Athlon 5000+ alternates between one core running 100% (and the other ~20%) and vice-versa.

The Gnome system monitor graph literally looks like a roller coaster, where one CPU takes on the whole decoding task for around 15 seconds before switching to the other core.
(this is playing killa...)

This is vanilla intrepid (with updates up-to today), NVidia 180.16, and SVN xbmc, playing any h264 content.
(This post was last modified: 2009-01-05 16:46 by motd2k.)
find quote
mr_raider Offline
Senior Member
Posts: 105
Joined: Dec 2008
Reputation: 0
Post: #30
I don't have an Ubuntu box handy here, but can anyone check in system monitor what the "nice" value of the decoding process is?
find quote
Post Reply