XBMC for Windows - Performance
#16
it is somehow using more than one core but a lot less efficiently than on Linux builds, i never see utilization over 70%/core (this is measuring from the windows task manager graphs) whereas on the Linux build with the killa sample utilization goes through the roof but i drop no frames and the clip plays smoothly.

For me the difference isn't terribly important since I can still playback any real content I like no worries, but for people with slower systems this may actually be a rather annoying issue, is there any way I can file some debug logs or something to help troubleshoot the issue?
Reply
#17
i belive in vista and possible xp does some core balancing no matter
if the applicaton is capable or not itself. thats why you will read out
some actions on the second core.

i gonna du some tests on my vista machine and on my xp machine and report back.
Reply
#18
you could probably try playing around with the CPU affinity of the XBMC process to see how much performance is being gained by the windows time slicing (i think thats what i heard it called somewhere).
Reply
#19
Once "our" ffmpeg dlls works with threading on windows we can see if this improves performance
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#20
ashlar Wrote:You mean you lost no frames and sound was good while playing the killer BBC Planet Earth sample? With no multicore usage it should be impossible!

XBMC IS multicore decoding ni Linux which is what the Live distro is using. 2.4Ghz sounds a bit low to not get any dropped frames with the Killa clip but it would certainly be better than Windows if there's no multicore on that platform. Linux working smoothly for me, no dropped frames watching birds...
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
#21
WiSo Wrote:Once "our" ffmpeg dlls works with threading on windows we can see if this improves performance

This isn't a generic ffdshow problem is it? I also use zoom player with ffdshow and it seems to multithread just fine.
Reply
#22
ewok666 Wrote:This isn't a generic ffdshow problem is it? I also use zoom player with ffdshow and it seems to multithread just fine.
ffdshow is not the same thing as ffmpeg, though it's based on the same codebase (I think).
XBMC has never used ffdshow, as it's windows only.
Reply
#23
yep the vsync option worked for me too Smile the skins seem to consume a lot of CPU cycles otherwise....
Reply
#24
WiSo Wrote:Once "our" ffmpeg dlls works with threading on windows we can see if this improves performance

Are there any indications as to when this will be achieved?
Reply
#25
eriksmith200 Wrote:Are there any indications as to when this will be achieved?
FFmpeg developers are working on this for GSoC (Google Summer of Code), ...not XBMC developers. Once FFmpeg have implemented it into their own SVN then it should hopefully not be long before it will be added to XBMC, ...all I can tell you is that it will not happen before November at the earliest (because XBMC is in a feature freeze until then).
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#26
Threading in windows might be a XBMC problem only. I assume ffmpeg works with threading in windows but somehow it doesn't harmonize with out dll loader (maybe).
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#27
Gamester17 Wrote:FFmpeg developers are working on this for GSoC (Google Summer of Code), ...not XBMC developers. Once FFmpeg have implemented it into their own SVN then it should hopefully not be long before it will be added to XBMC, ...all I can tell you is that it will not happen before November at the earliest (because XBMC is in a feature freeze until then).
Can this be considered a feature, though?
If multithreading is working fine on linux and osx, this seems more a bug to me. Even more so if multithreading in ffmpeg under windows is working with other applications.

Maybe it's just semantics Big Grin
Reply
#28
The GSoC patches I mentioned are not even if FFmpeg's own SVN so yes they are definitely classified as new features and not bugs.

Rolleyes
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#29
yeah but surely given that it works fine on linux just not on windows, we dont need any new patches we just need the windows version to do the same as linux already does?
Reply
#30
Gamester17 Wrote:The GSoC patches I mentioned are not even if FFmpeg's own SVN so yes they are definitely classified as new features and not bugs.

Rolleyes
Instead of rolling eyes you might want to re-read what I wrote. Why is it working fine under Linux, then?
It was Wiso that wrote that ffmpeg multithreading works fine under Windows but it doesn't harmonize with XBMC's dll. I didn't.
Reply

Logout Mark Read Team Forum Stats Members Help
XBMC for Windows - Performance0