Any people has ran XBMC on beagleboard-XM and get the the result when
play 720p movie?
I'm try to use XBMC to play 720p movie, but the FPS is very low,
around 10fps, the CPU occupy is nearly 100%.
But under the same system environment, the Mplayer play the same 720p
movie very smooth, nearly 24fps. and the CPU
occupy is no more than 50%.
My confuse is the Mplayer and XBMC use the same FFmpeg as video codec,
and when the XBMC play the movie in full screen mode.
the XBMC GUI should not eat too much CPU resource. Why the result is
so different? Does any specify system optimize or parameter needed?
Any suggestion are appreciate.
Both XBMC and Mplayer are compiled from the newest angstrom
distribution /OE repo.
I haven't try above one, I suppose the modification by above project
has bee merged into the mainstream of XBMC git repo.
But under the same system environment, the Mplayer play the same 720p
movie very smooth, nearly 24fps. and the CPU
occupy is no more than 50%.
My confuse is the Mplayer and XBMC use the same FFmpeg as video codec,
yes
and when the XBMC play the movie in full screen mode.
the XBMC GUI should not eat too much CPU resource.
you are in for a surprise
Yes, really, I just confuse what is the bottleneck to make the XBMC
eat so much CPU resource. even when play movie in fullscreen mode
when this time the GUI needn't be run in fact.
When only tun XBMC the CPU occupy is lower than 20%. The Mplayer will
occupy no more than 50% CPU resource when play 720p movie with 24fps.
but when XBMC play the 720p movie , it takes nearly 100% but only
reach 10fps. So it must be something eat the CPU but not the video
decoder .
XBMC mainline still uses gles shaders to do the conversion from yuv to
rgb. While ideally this ought to be the GPU's job it seems like some
of this sadly falls back to CPU in the drivers (I do not know what
since I do not have the code etc.).
Also, XBMC overall is not really as optimized for video playback as
mplayer is, we do some unnecessary memcpy's (which my gsoc took away
but can't really be backported as its a hack) and they take quite a
lot of cpu cycles on a beagle. Next you need to understand that XBMCs
GUI runs in gameloop design, and it still runs during movie playback
as you can have widgets on top of the video if the skinner so desire.
Our GUI Design, which is what I partly tried to reorginize during
gsoc, is not very suitable for low performance systems like the
beagle, we are trying to amend this but have quite a long way to go
still.
Long story short, we use A LOT more resources than we ideally should.
And you can't really compare XBMC to mplayer, we will never reach
being that low spec as we are a fundamentally different type of
application, we are meant to be both mplayer and the desktop
environment underneath as we are the full frontend of your device.
During GSoC I implemented an omap overlay based render (thanks to
omapfbplay by måns) which does not share the problems of the gles
renderer and it did handle 720p presentation of an SD video without
any real problem for me on my c4. This has _not_ been merged back into
mainline, mostly because my current school have been taking all my
time (haven't done anything significant floss lately) and partly
because I'd like to go over the implementation a bit more before
merging (might opt to just put it in ASAP).
I haven't try above one, I suppose the modification by above project
has bee merged into the mainstream ofXBMCgit repo.
>> But under the same system environment, the Mplayer play the same 720p
>> movie very smooth, nearly 24fps. and the CPU
>> occupy is no more than 50%.
>> My confuse is the Mplayer andXBMCuse the same FFmpeg as video codec,
> yes
>> and when theXBMCplay the movie in full screen mode.
>> theXBMCGUI should not eat too much CPU resource.
> you are in for a surprise
Yes, really, I just confuse what is the bottleneck to make theXBMC
eat so much CPU resource. even when play movie in fullscreen mode
when this time the GUI needn't be run in fact.
When only tunXBMCthe CPU occupy is lower than 20%. The Mplayer will
occupy no more than 50% CPU resource when play 720p movie with 24fps.
but whenXBMCplay the 720p movie , it takes nearly 100% but only
reach 10fps. So it must be something eat the CPU but not the video
decoder .
XBMC mainline still uses gles shaders to do the conversion from yuv to
rgb. While ideally this ought to be the GPU's job it seems like some
of this sadly falls back to CPU in the drivers (I do not know what
since I do not have the code etc.).
Also, XBMC overall is not really as optimized for video playback as
mplayer is, we do some unnecessary memcpy's (which my gsoc took away
but can't really be backported as its a hack) and they take quite a
lot of cpu cycles on a beagle. Next you need to understand that XBMCs
GUI runs in gameloop design, and it still runs during movie playback
as you can have widgets on top of the video if the skinner so desire.
Our GUI Design, which is what I partly tried to reorginize during
gsoc, is not very suitable for low performance systems like the
beagle, we are trying to amend this but have quite a long way to go
still.
Long story short, we use A LOT more resources than we ideally should.
And you can't really compare XBMC to mplayer, we will never reach
being that low spec as we are a fundamentally different type of
application, we are meant to be both mplayer and the desktop
environment underneath as we are the full frontend of your device.
During GSoC I implemented an omap overlay based render (thanks to
omapfbplay by måns) which does not share the problems of the gles
renderer and it did handle 720p presentation of an SD video without
any real problem for me on my c4. This has _not_ been merged back into
mainline, mostly because my current school have been taking all my
time (haven't done anything significant floss lately) and partly
because I'd like to go over the implementation a bit more before
merging (might opt to just put it in ASAP).
--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagleboard@googlegroups.com.
To unsubscribe from this group, send email to beagleboard+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
----- End message from tobias.arrskog@gmail.com -----
I haven't try above one, I suppose the modification by above project
has bee merged into the mainstream ofXBMCgit repo.
>> But under the same system environment, the Mplayer play the same 720p
>> movie very smooth, nearly 24fps. and the CPU
>> occupy is no more than 50%.
>> My confuse is the Mplayer andXBMCuse the same FFmpeg as video codec,
> yes
>> and when theXBMCplay the movie in full screen mode.
>> theXBMCGUI should not eat too much CPU resource.
> you are in for a surprise
Yes, really, I just confuse what is the bottleneck to make theXBMC
eat so much CPU resource. even when play movie in fullscreen mode
when this time the GUI needn't be run in fact.
When only tunXBMCthe CPU occupy is lower than 20%. The Mplayer will
occupy no more than 50% CPU resource when play 720p movie with 24fps.
but whenXBMCplay the 720p movie , it takes nearly 100% but only
reach 10fps. So it must be something eat the CPU but not the video
decoder .
XBMC mainline still uses gles shaders to do the conversion from yuv to
rgb. While ideally this ought to be the GPU's job it seems like some
of this sadly falls back to CPU in the drivers (I do not know what
since I do not have the code etc.).
I have success compiled the GSOC version XBMC which you made, but it
show black screen after start it on my beagelebaord-XM. maybe some
issue due to interface upgrade. If the yuv to rgb will effect the
CPU resource utilizatio, could you point to me which patch in the
GSOC version do such thing, then I'll try to merge them in the XBMC I
used to now and see anything better.
Also, XBMC overall is not really as optimized for video playback as
mplayer is, we do some unnecessary memcpy's (which my gsoc took away
but can't really be backported as its a hack) and they take quite a
lot of cpu cycles on a beagle. Next you need to understand that XBMCs
GUI runs in gameloop design, and it still runs during movie playback
as you can have widgets on top of the video if the skinner so desire.
Our GUI Design, which is what I partly tried to reorginize during
gsoc, is not very suitable for low performance systems like the
beagle, we are trying to amend this but have quite a long way to go
still.
Long story short, we use A LOT more resources than we ideally should.
And you can't really compare XBMC to mplayer, we will never reach
being that low spec as we are a fundamentally different type of
application, we are meant to be both mplayer and the desktop
environment underneath as we are the full frontend of your device.
During GSoC I implemented an omap overlay based render (thanks to
omapfbplay by måns) which does not share the problems of the gles
renderer and it did handle 720p presentation of an SD video without
any real problem for me on my c4. This has _not_ been merged back into
mainline, mostly because my current school have been taking all my
time (haven't done anything significant floss lately) and partly
because I'd like to go over the implementation a bit more before
merging (might opt to just put it in ASAP).
I see some brief overlay modify introduce the XBMC GSOC website, any
more detail introduce about it, or any patches link, I'd like to apply
them in the currently XBMC I used and do some tests. Thanks.
Does XBMC for beagleboard is able to use the codecs from gstreamer?
I'm running XBMC with the branch gsoc-2010-beagleboard with angstrom
and it still is very slow with 720p videos and resolution, and uses
approximately 100% of CPU.
