Beagleboard project for GSOC 2010
I have been selected by the Beagleboard community and Google to work on Google Summer of Code 2010. My project will consist of optimizing the rendering of XBMC for the embedded market.
The Beagleboard is an arm based embedded device. Similar hardware can be found in the smart phone segment, for instance the first generation of Android based phones. The current version of the hardware will not be able to deliver 1080p but upcoming generations might. This opens up a wonderful possibility for XBMC.
The problem with XBMC is that it is just too heavy to render as is. Most of the time the interface sits close to static and while a user would perceive this as an idle state, XBMC is far from idle. Every frame the application renders the interface from the ground up and no matter if the interface is completely static this is done at 30-60 times a second! Because of this, the project will focus on moving to an event based rendering system. This will introduce a true idle state and will lower resource usage when the application is idle, however this in itself is not enough. Even if a window is static initially, a skinner can easily add non-static elements such as scrolling text or animated images, which means we again have to render at full frame rate. Thus lowering the actual rendering overhead is also necessary.
During the summer I will keep the community updated on this blog on a weekly basis. Since some of the content will be very technical it has been decided that only a part of the posts will be pushed to the front page of xbmc.org. If you are interested in getting all the updates regarding this project navigate to the full URL for my blog as it will contain the unfiltered posts as well. For those interesting in helping out I will be idling in both the standard XBMC and the beagle board IRC channels. I will be working in a branch in the normal XBMC svn (not created yet) but will be named gsoc-2010-beagleboard and anyone is free to check out the progress there.
I hope you have enjoyed this introduction and I will end by saying that this will be a great summer for the users of slower hardware and a grand summer for the possibility of a small, silent, affordable and low powered device capable of delivering the full XBMC experience!
Great news that you’ll be working on a event based XBMC – that’ll be awesome. But just to get you right, your event based changes will (hopefully) make it into trunk so that every platform can benefit from it, not only embedded right?
I could be missing something obvious but I can’t see how to subscribe to your blog, pointing an RSS reader to the page just finds my existing subscription to the general XBMC feed which as you say your blog won’t already appear on.
@NeToU
It’s not all that obvious. The feed is here: http://xbmc.org/author/topfs2/feed/
I’ll try to find a place to stick links to active blogs.
@da-anda
Yup the hope is that the changes will make it into trunk and that any device will benefit from the eventbased design. However I must point out that it won’t be a drop in placement so both opengl and direct3d rendering will probably need to be altered aswell thus it may be disabled for them to begin with.
Also much of the stuff that will be added might push the requirements up for XBMC so to bring them down for older hardware may also take some time which is why the changes may take some time before activated on desktop systems.
Interesting! Especially since this would benefit all platforms in the end right?
And the possibilities this brings is huge. XBMC on an Android tablet anyone? Count me in! :D
Good luck :)
Great initiative! Looking forward to read about the progress. Good luck!
@theuni: while you’re at it, can you enable the option for full content in the xbmc.org feeds? thanks!
Great! About time. :P
I am happy to know that finally our htpc will use less computable resources and therefore less power consumed while idling.
Let it be greener! :)
Sounds interesting, good luck.
I always assumed mobile devices will use some kind of simplified skin, not just because of speed issues as you mentioned, but also because mobile devices have much smaller memory capacity.
The question is, what kind of screen are you gonna use in this project?
are you assuming a mobile device connected to a normal TV with 720p,
or maybe some kind of mobile video played with small LCD screen?
Just to make myself clear, my work won’t be targeting mobile devices. The target is still HTPC’s run on a big screen, the hardware just happens to be similar.
That being said the work done will probably help it become a reality to run on mobile devices but as you say, for XBMC to be usable on a mobile device it really needs a different skin.
great news for the green comunity too
Best of luck topfs2, this sounds great
Interesting news. After that, lets get a Team XBMC version of Google TV going… if not already on the menu ;-)
Liking the sound of this. Obviously a lot of work to be done, especially merging into main svn and getting to work with all diff distros.
As a old school user still clinging on to xbmc on my trusted xbox (use 360 for any hi def) can you see much impact in lowering the resources on the xbox’s limited resources.
This is not a good place for that discussion, please take it to the forum instead.
Sounds great, reducing the load caused by the rendering engine would be a great thing. Even if XBMC cannot render even SD video on ARM processors it would still be great to see the rendering load reduced.
Of course I hope that a phone/tablet will be able to run XBMC in a few months and maybe in the near future even playback 1080p movies but I won’t hold my breath because of the hardware not yet being able to do this ;-)
I like the prospects of this. I currently run XBMC on my HTPC setup, but with the recent install of a PC into my car, XBMC was just a bit too heavy for the applications. I had hoped that it would suffice for a front end, but ultimately it proved to be lacking. I’ve been using XBMC since the original xbox days and I still have a original xbox that uses it, but if I could reasonably bring this excellent interface reasonably into my car too, I would be in heaven.
@Jeroen
Agreed! XBMC on any sort of pocketable PMP device is my dream.
I’m really happy to hear that XBMC is continuing to expand its platforms. I also think the focus of a lower rending load is awesome and could benefit more than ARM platforms. Can’t wait to hear the progress!
Hello,
switching to an event based rendering system is really interesting, I’m looking forward to reading your next technical posts about it :)
I already have a question about this switch, how will you do to maintain the framerate for a movie playback? Will you fire an event each time a new frame is ready to display?
Regards
Rno
Awesome news! I was just explaining to a friend why XBMC ate so many CPU cycles when “idle”–great to see that this is getting some attention. Best of luck, I’ll definitely be following your updates!
Cool…as I understand it, Beagleboard is very similar hardware to OpenPandora…http://www.open-pandora.org/, which are finally starting to ship now!
My question is how will you work the porting issue? It seems to be easier and more maintainable to port xbmc to the iPhone ObjectiveC language then to port Xbmc from C to Java. How will you work in the Android APIs? Which API version are you working with? Please reveal some of the greasy details
@Adam Outler
This has nothing to do with Java or Android. Linux != Android.
Great to hear this! Is a nice step looking forward, i-m totally agree about been greener!
He’s not porting xbmc to mobiles, he porting it to arm based embedded devices. in theory it could work on arm based mobile phone, but i’m guessing this is more aimed at TV’s with inbuilt ARM kit and to reduce the size of htpc.
@Rno
I think you are missing an important point here, the playback of media files is a different thing all together. The UI is all the stuff you see before the movie starts to play and after it is done. There are some UI elements you might see during the playback of a video, when you pause a video or when you change settings during the movie etc. But normally during playback there are no UI elements visible during playback.
If you now switch on CPU usage monitoring you will see that during movie playback the CPU usage is ~5 to 10% but while you are selecting the movie or even just looking at the home screen you can see your CPU usage at ~50 to 65%. With event based rendering you will likely see a usage of somewhere in the area of 5% or even less as there will only be work to be done when you move the mouse or display new/changing UI elements.
Is there any change that this will work on a Dreambox? I have a Vu+ Duo and the media player really sucks. It has a 405mhz broadcom mips processor with no graphics card. Keep up the good work.
@rcoops
Thank you for your answer :-)
During playback of a movie you can go back to home and (in the default skin) there is a live thumbnail of the movie. I think this thumbnail is rendered as the same fps the movie has, right? What about such a UI element like that: live thumbnail of the movie?
I can see future set-top boxes (appletv included) running on ARM processors in the future. Any advances to put XBMC on these is very welcome! As far as I am concerned, these don’t need to be pocketable, but they will be smaller, cheaper and use less electricity, so I am all for it!
@topfs2
kjhggggggg
Thanks so much for taking on this project. I run three XBMC boxes; an AppleTV on our HDTV, an old Macbook on our bedroom SDTV, and a first-gen eeepc on our guest room SDTV. While the AppleTV gets along just fine, the Macbook spins up the fans pretty much instantly when on the interface, and the eeepc can actually barely handle the interface at all. I have no video playback complaints for any of the machines, so anything that can help improve UI performance is awesome.
Hi,
This sounds very nice!
Will you port XBMC to use Open GL ES instead of Open GL for rendering or will you use some other method?
Well XBMC is already ported to Open GL ES 2.0 in trunk (thanks to mcgeagh). My project will be more regarding optimization of it. Some optimizations will be inside opengl es and some will be more general and with regards to how stuff is rendered. Dirty region and eventbased rendering is one of those more general optimizations which will benefit more than OpenGL ES.
Ok, sounds great!
Will your optimizations be platform independent or will accept beagleboard (omap) specific optimizations?
(Such as using sgx extension for texture streaming).
Anyhow good luck! @topfs2
Hmm the feed links for topfs2 dont seem to update, is there somewhere I can check on progress?