• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 22
No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)
#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)
Reply
#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.
Reply
#18
So it's not the lack of real multithreading the problem, but the worse resource utilization on Intrepid vs. Hardy kernel ?
Reply
#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.
Reply
#20
Have any of you tried it with the CPU set at full, i.e. Performance mode, or disable Cool N Quiet?
Reply
#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.
Reply
#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.
Reply
#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.
Reply
#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?
Reply
#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.
Reply
#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
Reply
#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)
Reply
#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 !
Reply
#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.
Reply
#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?
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 22

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