• 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 22
No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)
#91
BLKMGK Wrote:Is there anyone besides myself NOT seeing this issue on IntrepidHuh

Maybe this is the reason why you have not found 2.66GHz sufficient for smooth playback of killa sample...
Reply
#92
althekiller Wrote:aron, ffmpeg trunk doesn't have the cabac patch. Build ffplay from our ffmpeg sources in XBMC/xbmc/cores/dvdplayer/Codecs/ffmpeg.
Thanks, didn't know that!
But I've also tried with the XBMC patched version of ffplay -> same results.
So now I'm searching for the responsible lib.
Reply
#93
BLKMGK - i am interested and curious - do you do completely clean install from a ubuntu 8.10 iso (format etc) - or clean install from ubuntu 8.04 (maybe xbmc live) and upgrade to ubuntu 8.10. because upgrading you maybe pulling the problem library with you on the upgrade and hence not seeing it.

I ask because i can only use ubuntu 8.10 with my hardware - and i have seen this issue from my very first install. i.e partition drive -- install ubuntu -- add ppa to sources.list and get/install xbmc packages. alot of debugging later still seeing uneven core utilisation.

Quote:honestly in the end I care that it plays video smoothly and so far it does just that without issue including Killa'.

as do i and unfortunately as it stands i do not see playback without issue. jitters and stutters.

hopefully you'll soon be able to recreate our issues and see first hand - honestly we are not making them up Big Grin
Reply
#94
olympia Wrote:Maybe this is the reason why you have not found 2.66GHz sufficient for smooth playback of killa sample...

<sigh> I have been running XBMC on Linux hardware for probably close to a year, the hardware list in my sig is my main box. That is a 2.66ghz CPU that was unable to run Killa' smoothly until it was overclocked. That machine is running Hardy 8.04 and was upgraded from the previous 7.x build of Ubuntu before it. 3ghz is what it takes and if you have been paying attention you will have seen that on my SECOND box running Intrepid the CPU usage is EVEN and smooth. THAT box was tested with an overclocked Celeron first and then with a 45nm 2.66ghz C2D that yes required 3ghz give or take to stop dropping frames. I do not know how much clearer I can be on this but 2.66ghz ain't cutting it and so far as I know only one person running Linux found a DIFFERENT 2.66ghz CPU to be sufficient - that CPU having more cache than mine.

adix - the Intrepid build I have was done from scratch. Drive formatted, the works. I had originally tried it with Hardy and it ran video fine but I wanted HDMI audio and that required a later video driver that was most easily obtained from Intrepid's repository. So, I formatted it and started all over. I turned off desktop effects, I left PulseAudio alone, I loaded the later ALSA using a script on the Ubuntu forums, I loaded Thunar, I loaded the XBMC deps, I pulled and loaded XBMC. Oh, I have subcommander on there too for playing with the SVN. Everything else is pretty much standard - it has the SBMC splash screens too. In the BIOS I maxxed out vid memory, overclocked the CPU, and uncoupled the memory from the CPU. I loaded up the latest BIOS ASUS has for that board based on things I'd read on AVSforum. I also dorked with the ALSA setup some, never got stereo sound from HDMI but got 5.1 and that was most important. Somewhere in there I updated all of the patches for the OS. If someone can give me the commands I can pull the kernel revision and other stuff. To test I am simply running Killa' and hitting the play button again to get the stats, 10frames dropped up front the first time, 14 the second, CPU usage never goes over 80% and it's almost perfectly split. If someone has a burning need I can try to snap a pic of it, will screenshot work for capturing this?
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
#95
BLKMGK Wrote:I do not know how much clearer I can be on this but 2.66ghz ain't cutting it and so far as I know only one person running Linux found a DIFFERENT 2.66ghz CPU to be sufficient - that CPU having more cache than mine.

I really think you should be more careful about that. Your voice is loud and people are hearing that. Read back just two pages. Alanwww1 also stated, that on Hardy, he was able to see smooth playback of killa even with an E7200 at stock speed. I have the same experience with E7300 and E8200, so forget about cache size.

I just wanted to raise a possible chance why you experienced slow playback at 2.66, not to begin an argue with you........

edit: I corrected E8400 (posted first by accident) to E8200
Reply
#96
There have been ffmpeg updates since BLKMGK did his initial testing. Many fixes went in that directly affect h264 playback, it is well possible that 2.66GHz is enough now.
Reply
#97
Whatever cpu speed we declare for sufficient playback what is a fact that on the same hardware the same xbmc svn version (i tried) 2.6ghz was enough with hardy and 3ghz was not enough in intrepid. So these numbers could change from user to user (depending on svn version, hardware, settings etc) but the minimum 15-30% difference is there. And it is a lot. It makes the very good energy efficient E7200 7300 c2ds not enough for a lot of 1080p material.
Reply
#98
We did it Big Grin

I've debootsrapped a hardy release and copied these files to a separate direcotry (check `ldd ffplay`):
Code:
libasound.so.2
libasound.so.2.0.0
libdirect-1.0.so.0
libdirect-1.0.so.0.1.0
libdirectfb-1.0.so.0
libdirectfb-1.0.so.0.1.0
libdl-2.7.so
libdl.so.2
libfusion-1.0.so.0
libfusion-1.0.so.0.1.0
libm-2.7.so
libm.so.6
libpthread-2.7.so
libpthread.so.0
librt-2.7.so
librt.so.1
libSDL-1.2.so.0
libSDL-1.2.so.0.11.1

Code:
LD_LIBRARY_PATH="/old_libs/" /usr/local/bin/ffplay -threads 3 /storage/killa.sampla.x264.mkv

These libs are dynamically linked to ffmpeg. So now if I start ffplay with "-threads 3" it uses 3 cores for decoding and the vids work well.
Reply
#99
aron Wrote:These libs are dynamically linked to ffmpeg. So now if I start ffplay with "-threads 3" it uses 3 cores for decoding and the vids work well.

You mean it is playing on Intrepid OK and before this copy it was not OK ?

What about XBMC ? How can we use the solution there. What libs are we using on XBMC out of these ?
Reply
alanwww1 Wrote:You mean it is playing on Intrepid OK and before this copy it was not OK ?

What about XBMC ? How can we use the solution there. What libs are we using on XBMC out of these ?

Yep (under intrepid) and I've compiled ffmpeg inside the chroot. So it may be one of the libs or something included. But it runs well outside of the jail.

So It's like I compile it in hardy then copy it to Intrepid, so files from hardy are included like pthread.h ...

I will investigate this tomorrow ... It's damn late here ... I have to go to work tomorrow (today) :S
Reply
I'll put my money on libasound Smile
Reply
Relevant hardware:

Shoebox
  • AMD 4850e (overclocked to 2.88 ghz)
  • Geforce 8600 GS
  • 2 GB ram dual channel


Flatbox
  • AMD 5050e
  • (overclocked to 2.88 ghz)
  • Geforce 8200
  • 2 GB ram single channel

Hard drive 1 boots ubuntu 8.04, kernel 2.6.24-22-generic, Nvidia drivers 180.17, and revision 16823 of XBMC.

Hard drive 2 boots ubuntu 8.1, kernel 2.6.27-11-generic, Nvidia drivers 180.17, and revision 16823 of XBMC.

Test plan:

Playback known functioning difficult x264 rip on shoebox with hard drive 1.
  • The Dark Knight "1080p" rip (actual resolution 1920x800)
  • Section 00:10:25 - 00:10:52

Playback killa sample on shoebox with hard drive 1.

Swap hard drives, and repeat test with same hardware booting ubuntu 8.1.

Repeat process above on the hardware on flatbox.

Findings:

Shoebox
  • Booting from hard drive 1 (8.04)
    • The Dark Knight sample drops no frames.
    • Killa sample drops 202 frames.
  • Booting form hard drive 2 (8.1)
    • The Dark Knight sample drops no frames.
    • Killa sample drops 231 frames.

Flatbox
  • Booting from hard drive 1 (8.04)
    • The dark knight sample drops 8 frames.
    • Killa sample drops 209 frames.
  • Booting from hard drive 2 (8.1)
    • The Dark Knight sample drops 20 frames.
    • Killa sample drops 222 frames.

Summary:

While playing back both samples I watched the output of top over an ssh session from another computer. Top had thread view on and was in SMP mode. In hardy and intrepid I saw even distribution of load over two xbmc.bin threads. The load was higher on intrepid for some reason.

tl;dr - According to my tests intrepid takes more cpu power to do the same thing as in hardy.

Other thoughts:

Perhaps the number of frames dropped while playing back the killa sample makes all of this irrelevant. I'll leave that up to you to decide Rolleyes
Reply
Why do you figure the 4850e did better than the 5050e at same clock?
Reply
I can only assume the discrete 8600 GS graphics card has it's advantages over the integrated 8200, even in linux. The dual channel ram may also account for the differences. I did some tests a few weeks ago on the 5050e system overclocked to 3.0Ghz and was still getting dropped frames on clips that ran fine on the 2.88Ghz system. I going to try again this weekend because I think the frequency scaling was enabled in intrepid at the time. I have since disabled that feature on the intrepid box.
Reply
From what I can tell from wikipedia (that's all the further I care to research the matter) those two procs have different core architectures. Comparing them, even at identical clock rates, is useless for anything but a direct architecture comparison.
Reply
  • 1
  • 5
  • 6
  • 7(current)
  • 8
  • 9
  • 22

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