Posts: 45
Joined: Nov 2003
Reputation:
0
plays a fotr 720p sample at more than 30fps from the hard drive. then again i'm not playing it at hd resolutions just 480i but it shouldn't matter that much. noticed there is no significant speed difference between filters though.
Posts: 168
Joined: Feb 2004
Reputation:
0
i know this is going a little off topic but let us keep thing in perspective here, the screen ress of the xbox is only 720 x 576 and at a resolution that low most low end pc can run most games. not only that the xbox can only run one process (one game, app, stream or ui) at a time, so there really is no reason for it to 'run out' of resources.
senior systems engineer
uk
Posts: 761
Joined: Dec 2003
Reputation:
0
Butcher
Retired Developer
Posts: 761
errr, the major resource we lack is memory. it's trivial to use 64mb in one app, so i don't see why we should have "infinite" resources all of a sudden. if you're thinking of what win9x calls "resources" then the xbox doesn't have them - it's not windows.
there are basically 4 resources which are shared between the threads of the process - cpu time, gpu time, memory and i/o bandwidth.
i/o bandwidth isn't usually too much of an issue - only the actively playing media really hits the disk. if you ftp while playing media it can be an issue though that also relates to cpu hit.
gpu time is also not much of a problem in xbmc as we do relatively little drawing (compared to a 3d game).
cpu time is a big issue, especially with some of the high compression video codecs, they basically need all the cpu just for the decode, running other stuff in the background can impact performance badly. it's fairly easy to get round by lowering the background service thread priorities though.
memory is the main problem. there's 64mb for everything. no separate texture memory like a pc, no virtual memory like windows. 64mb has to fit everything - all the code, all the data, all the textures. for reference we use maybe 4-6mb for code, and about 2-20mb in textures most of the time (varies based on skin). other things like maintaining the gui, i/o buffering, python, playing any media etc also take a chunk of memory. typically at the home screen with no media running you're looking at 25-50% of memory gone just for the gui and program state/buffers. playing a movie will use the bulk of the remaining memory, leaving very little for maintaining background services such as email servers and whatnot.
so as you can see running out of resources is very easy to do.
Posts: 761
Joined: Dec 2003
Reputation:
0
Butcher
Retired Developer
Posts: 761
you can't fully emulate an x86 on a gpu, it doesn't have enough instructions. even if you could, why would you? it'd be slower than doing it on the cpu.
Posts: 10,520
Joined: Sep 2003
Reputation:
10
Gamester17
Team-XBMC Forum Moderator
Posts: 10,520
2004-03-19, 15:53
i was only specucating if and how one could use the gpu as a co-processor to the cpu to help (not instead) decode hdtv-video (ex. in mpeg2)
Posts: 761
Joined: Dec 2003
Reputation:
0
Butcher
Retired Developer
Posts: 761
from the docs it looks like moving the motion compensation onto the gpu should be possible from a hardware having the capability standpoint. i'm not sure how easy it will be to integrate that with mplayer though.
Posts: 2
Joined: Mar 2004
Reputation:
0
what about th 720 p movies like tomb raider special box!!!there are an extra dvd that source are 720p or 1080 i movie!!
have xbox much power to play this!!!
Posts: 761
Joined: Dec 2003
Reputation:
0
Butcher
Retired Developer
Posts: 761
maybe, but i don't really have the sort of time or energy required to write gpu based motion comp. or suchlike.
Posts: 761
Joined: Dec 2003
Reputation:
0
Butcher
Retired Developer
Posts: 761
mplayer has support for passing the entire mpeg stream through undecoded to a hardware decoder, i'm not sure if that would help though.
also, there's no software support for quater-pel in xbmc/mplayer currently so i don't think not doing it on the gpu would be an issue.
