GSoC 2010 Port XBMC to BeagleBoard

Hi I'm one of the developers of xbmc media center and I noticed you
have listed xbmc as a possible project for GSoC.

About me. I'm a computer science student on my third year and will be
taking my major in graphical programming but I've also contemplated
embedded systems so for me working on beagleboard would be alot of
fun.

My alias over at xbmc is topfs2 and most of my prior work have been in
the linux department and the PAPlayer (which is a component not
working in the current beagleboard version of xbmc so I could try to
get that working). Recently I've taken on the jsonrpc interface and
webinterface (the latter is not by strong suite though).

I'd say that during GSoC I'd aim at getting PAPlayer to work proper,
but speaking with mcgeagh (the guy that have done the initial port)
graphics is the most troublesome part.

Before the lightning strike hit our server and we failed to apply for
GSoC ourself I had planned to apply with a graphics rendering redo
which would allow event triggered rendering, dirty region rendering
and general optimizations of our rendering (not forcing blend and
such). All of these improvements would have benefited beagleboard
greatly so I'd love a chance to do the same work but here instead.

Cheers,
Tobias a.k.a topfs2

Hi I'm one of the developers of xbmc media center and I noticed you
have listed xbmc as a possible project for GSoC.

About me. I'm a computer science student on my third year and will be
taking my major in graphical programming but I've also contemplated
embedded systems so for me working on beagleboard would be alot of
fun.

My alias over at xbmc is topfs2 and most of my prior work have been in
the linux department and the PAPlayer (which is a component not
working in the current beagleboard version of xbmc so I could try to
get that working). Recently I've taken on the jsonrpc interface and
webinterface (the latter is not by strong suite though).

I'd say that during GSoC I'd aim at getting PAPlayer to work proper,
but speaking with mcgeagh (the guy that have done the initial port)
graphics is the most troublesome part.

Before the lightning strike hit our server and we failed to apply for
GSoC ourself I had planned to apply with a graphics rendering redo
which would allow event triggered rendering, dirty region rendering
and general optimizations of our rendering (not forcing blend and
such). All of these improvements would have benefited beagleboard
greatly so I'd love a chance to do the same work but here instead.

Agreed. Please make an application!

Since I cannot update my proposal here is the revised one.

==About your project==

The project I would like to propose is to get XBMC, an award winning
media center software, running better on slower hardware found in
embedded systems. If the project would be successful it would allow
the community to build a small, cheap and open HTPC / media center
(Home theater PC - Wikipedia) based on XBMC and the
BeagleBoard.
XBMC have already been ported to ARM but runs at about 10fps on the
BeagleBoard. I believe there is room for improvements in this
department. To explain how I wish to accomplish this we first begin
with a little history.
XBMC was created for the Xbox gaming platform and designed in a game-
loop design. This means that the application renders the graphical
user interface from the ground up every single frame. This approach is
fine for a game were each frame is different and since the Xbox is
still rather powerful in terms of graphics it was not a big
limitation. Since most of the graphical user interface is built around
static elements this is very wasteful, especially on slower hardware.
The graphical library used by XBMC is made up by windows and dialogs,
both of these are populated by controls. A control can for example be
an image, text or button. There also exist a control, control-group,
which is a group of controls (classic composite pattern). The
graphical library is extremely flexible and everything can be defined
by the skinner.
The core problem with slower hardware is that it cannot render the
entire graphical interface in a decent frame rate hence it needs to
render less. My proposal to fix this is to firstly only render when
something needs to be redrawn, moving towards an event based rendering
system. This change will lower idle usage but is useless in itself
since even if some views are static a skinner can easily add a control
which is not static (scrolling text or animated image) and the
graphical library would need to render at full speed again. So to
lower the actual rendering overhead I would like to allow some of the
more advanced controls (say a text field or control group) to be
rendered once into a frame buffer, this frame buffer could then be
used instead of rendering the whole control when the rest of the
viewport needs rendering and would therefor lower the polygon count
drastically (each glyph is a quad). Finally since OpenGL supports to
only render into a specific region of the viewport I would also like
to make the graphical library able to leverage this. This would allow
to only clear a region which is likely to be in need of rendering and
then just render the selected region. Problematic part of this
technique is that it involves a great deal of processing to finalize
the region needed to be rendered since the graphical library is in 3D.
It has been suggested in the Beagle Board IRC to utilize OMAP3 for yuv-

rgb conversion which is currently done by a shader.

Since XBMC is mostly written in C/C++ that would be the core
programming language on this project. The libraries used would be
OpenGL ES.
Since my school system in Sweden continue throughout May the first
weeks (1-2) would be spent on profiling to finalize which of the
strategies would yield the biggest impact on the rendering speed, also
know how advanced the controls are needed to be before its beneficial
to pre render them. This point is vital since it gives an insight on
what to focus on during the next steps and it may be possible to begin
profiling earlier to give a chance to alter the focus.
Week 3 would be spent on general optimizations like smartly disable
blend on controls which does not need it, occlusion culling so the
graphical library don't render controls which have no possible impact
on the final viewport.
The following week (4-5) would be spent on refactor to allow the
solutions needed for Beagle Board to be possible. For example since
the graphical library calculate positions and render at the same time,
these needs to be separated to be able to calculate if the control
needs rendering. When the graphical library knows which controls are
needed to be rendered the move towards an event based rendering can
begin.
Week 6 would be spent on actually get the event based rendering
working, making other parts of the XBMC core able to issue a render
event when something have changed (input device pressed or a label
have changed).
Week 7 would be spent on adding a pre rendering stage accessible for
controls which can be used in render.
Week 8 would be spent on solving the dirty region problem, allowing
each control to have a transformation matrix so we can guess the
outcome of an added transformation. Here is also room for adding
frustum culling to not render and calculate controls which has no
possible impact on the final viewport.
Week 9 would be spent utilizing the OMAP overlay to remove the need
for yuv->rgb. This step should hopefully get lag free video playback
(SD content). This week could alternatively be spent on getting neon
up and running with ffmpeg.
Week 10 is pencil down and thus the bugg testing and documentation-
week begins.

I think I will be able to pull this off since I have been a member of
the development team of XBMC for over a year and can bring in the
knowledge of the rest of the team to help.
Also I have always been very interested and played alot with rendering
code and given that I know a great deal about XBMC code I think that I
would be a perfect candidate to making the needed optimizations of the
rendering.

==You and the community==

If the project succeeds it would make it possible to build a small,
affordable HTPC based on open source software on an open platform.
This would make it possible to create HTPC's that are based on the ARM
platform and are open source.
Outside Beagle Board community this project would lower the general
requirements on running XBMC so its of benefit to more than just
Beagle Board even if its the more important one.

From the wikipedia from BeagleBoard/GSoC/Ideas-2023 - eLinux.org
"XBMC is an open-source, cross platform media center that would allow
you to display high definition video on your TV that is streamed from
your local network or the internet. XBMC on Beagle Board would would
be a very low cost, low power platform that would allow the media
center to literally be embedded in the TV."

If I get stuck and my mentor isn't around I can always get help in the
XBMC community (we have a few Beagle Board equipped developers) or the
Beagle Board community over IRC.

==Miscellaneous==

I don't have a running Beagle Board yet but a TI sponsored one is in
shipping.

Hi,

Tobias asked me to review his proposal. For background, I'm one of the
mainline XBMC devs that deals with Linux/OSX platform and have
recently integrated Broadcom CrystalHD support into XBMC for hardware
video decode.

Tobias has correctly identified and targeted the major issue with
porting XBMC to ARM platforms such as the BeagleBoard. GUI rendering
under the current XBMC methods is very slow on an embedded platform
such as ARM. His development timeline is focused and looks quite
reasonable in the time allotted. The only question I would have is
with week 9 and would suggest that be spent working with OMAP overlay
instead of ffmpeg/neon decoding issues. Work elsewhere with OpenMax on
ARM platforms will quickly obsolete any such development and the time
is better spent integrating OMAP overlay.

Scott

davilla <sdavilla@gmail.com> writes:

Hi,

Tobias asked me to review his proposal. For background, I'm one of the
mainline XBMC devs that deals with Linux/OSX platform and have
recently integrated Broadcom CrystalHD support into XBMC for hardware
video decode.

Tobias has correctly identified and targeted the major issue with
porting XBMC to ARM platforms such as the BeagleBoard. GUI rendering
under the current XBMC methods is very slow on an embedded platform
such as ARM. His development timeline is focused and looks quite
reasonable in the time allotted. The only question I would have is
with week 9 and would suggest that be spent working with OMAP overlay
instead of ffmpeg/neon decoding issues. Work elsewhere with OpenMax on
ARM platforms will quickly obsolete any such development and the time
is better spent integrating OMAP overlay.

I think you overestimate the importance of openmax. FFmpeg already
has lots of NEON code, and is gaining more every week. In terms of
this particular gsoc projects, there's probably not much to be done
there, so that time is better spent on optimising the post-decoding
pipeline, for instance by using the hardware overlay and perhaps by
eliminating any redundant copying that might be happening (I do not
know if this is the case).