2009-10-22, 21:54
McGeagh Wrote:Its decoding fine.
The decoding of the video data is done in ffmpeg and that decodes all the frames without dropping any...
Its the YUV2RGB, scaling and rendering of the texture (i.e the SGX | GLES part) thats slow, and cant keep up...
Theres plenty room for improvement, but remember the beagleboard doesnt have very good memory bandwidth, so there will be a point where I cant make it go any faster... Will just have to wait for another board at that point!
Thanks for all your continued support!
@idioteque - not looked at those so cant say anything for certain... if its arm based, and has OpenGL ES2.0 support, it will be able to run this (at varying performance levels)
Congratulations! I have been tracking the progress of this project on and off and have been very impressed with what you have done in so little time…BY YOUR SELF! I honestly think the port of XBMC to ARM is going to offer a very bright future because of the fact that ARM is so low power, so small in size, and so dirt cheap (comparatively speaking that is). I take it; it is your end goal to have a fully functional ARM port of XBMC when you are done, correct?
Either way, I am not particularly familiar with the whole ARM scene but from my basic understanding the beagle board isn’t exactly the fastest ARM platform you can get…is that not so? Also, a few basic questions if you don’t mind answering them…
1. Once the port to ARM is finished won’t the software will be able to run on any ARM based platform with support for OpenGL ES 2.0 just as XBMC can currently runs on any X86 platform with OpenGL support?
2. Are the rest of the inner workings of XBMC fully functional in the state that your port is in now? AKA media library, network connectivity, audio playback, etc? (Basically everything besides the full speed video playback)?
Anyways, thanks for the update and please keep us informed…
Slice
P.S. I know there are ARM solutions from TI and others that offer hardware video/audio decoding capabilities, I was wondering if another potential avenue of exploration would be to strip-out XBMC’s software decoding code and perhaps implement a more platform specific decoding engine to take advantage of these types of hardware devices?