XBMC Weekly report 8

My weekly report, mostly done work with the OMAP Overlay
http://xbmc.org/topfs2/2010/07/18/weekly-report-8/

All you need to do is use an alpha component >0, the DSS will blend the framebuffers in hardware. Other options include colourkeying and cutting a hole in fb0.

regards,

Koen

Koen Kooi <koen@beagleboard.org> writes:

 \* Refit the overlay code from omapfbplay to fit into the video
   renderer I created, it starts the overlay but locks
   up somewhere\.

Is it checked in, so others can help debug?

 \* Fix the remaining issues and actually get video displayed using
   OMAP Overlay

Nice!

 \* Make the overlay scale and position correctly in the GUI and
   with respect of the window underneath\.
 \* Try to get SGX to render to the topmost frame buffer to get the
   OSD over the overlay\. Not sure how this should be done code
   wise though, I guess open a new EGL Context or Surface is
   needed?

I presume by default the SGX is rendering to the graphics layer, and
that shouldn't need to be changed - video layer data only needs to be
written by the video decoder.

 \* Get rid of the unneeded memcpy’s \(might be out of scope since
   its not problematic for 480p\)

576p would good to aim for if 720p is out of reach (and looks a lot
better than 480) - and at least in this part of the world is still a
relatively common format (although it might be the only place it is).

mån 2010-07-19 klockan 23:41 +0930 skrev Michael Zucchi:

> * Refit the overlay code from omapfbplay to fit into the video
> renderer I created, it starts the overlay but locks
> up somewhere.

Is it checked in, so others can help debug?

It wasn't since I didn't want to commit failing code but I did it now
regardless :slight_smile:

I also added a --enable-omap-overlay which must be used to get
compilation with it so its disabled by default. Will add it to
documentation ASAP.

> * Fix the remaining issues and actually get video displayed using
> OMAP Overlay

Nice!

> * Make the overlay scale and position correctly in the GUI and
> with respect of the window underneath.
> * Try to get SGX to render to the topmost frame buffer to get the
> OSD over the overlay. Not sure how this should be done code
> wise though, I guess open a new EGL Context or Surface is
> needed?

I presume by default the SGX is rendering to the graphics layer, and
that shouldn't need to be changed - video layer data only needs to be
written by the video decoder.

> * Get rid of the unneeded memcpy’s (might be out of scope since
> its not problematic for 480p)

576p would good to aim for if 720p is out of reach (and looks a lot
better than 480) - and at least in this part of the world is still a
relatively common format (although it might be the only place it is).

Yeah 576p seems like a good aim as well.

Completely untested: http://www.angstrom-distribution.org/~koen/xbmc-20100721.tar.bz2

regards,

Koen

mån 2010-07-19 klockan 23:41 +0930 skrev Michael Zucchi:

> * Refit the overlay code from omapfbplay to fit into the video
> renderer I created, it starts the overlay but locks
> up somewhere.

Is it checked in, so others can help debug?

It wasn't since I didn't want to commit failing code but I did it now
regardless :slight_smile:

That's what the branch is for. Branches in free software are allowed
(imho meant) to be buggy, it's a way to share/accelerate development.

I also added a --enable-omap-overlay which must be used to get
compilation with it so its disabled by default. Will add it to
documentation ASAP.

Damn, another option, means a reconfigure/complete rebuild.

!Z

PS the main thing is to keep is building cleanly. It needn't run perfectly.

tor 2010-07-22 klockan 12:16 +0930 skrev Michael Zucchi:

> mån 2010-07-19 klockan 23:41 +0930 skrev Michael Zucchi:
>> > * Refit the overlay code from omapfbplay to fit into the video
>> > renderer I created, it starts the overlay but locks
>> > up somewhere.
>>
>> Is it checked in, so others can help debug?
>
> It wasn't since I didn't want to commit failing code but I did it now
> regardless :slight_smile:

That's what the branch is for. Branches in free software are allowed
(imho meant) to be buggy, it's a way to share/accelerate development.

True, I'll try to keep commiting sooner. It helped quite much with koen
able to crosscompile for me.

> I also added a --enable-omap-overlay which must be used to get
> compilation with it so its disabled by default. Will add it to
> documentation ASAP.

Damn, another option, means a reconfigure/complete rebuild.

The one koen links to is the most recent (he updated it while I was
committing). For now that build stops somewere in the NEON
yuv420->yuv422. Måns suspects it being due to memory buffer isn't
aligned and me having a bad kernel. So perhaps it works for you if your
lucky. I'll try later tonight getting it to work on my machine.

Just FYI ...

My build finished yesterday and it ran once - very slow (no cpu usage
for most of that) and when i tried to play a video it hung at 100%
cpu.

It left a video overlay around.

I couldn't get gdb to work so I tried updating everything and then
rebuilding everything (320minutes from a make clean fwiw) and now
(after a clean reboot) it just says "ERROR: Unable to create
application. Exiting"

!Z

tor 2010-07-22 klockan 12:16 +0930 skrev Michael Zucchi:

I also added a --enable-omap-overlay which must be used to get
compilation with it so its disabled by default. Will add it to
documentation ASAP.

Damn, another option, means a reconfigure/complete rebuild.

The one koen links to is the most recent (he updated it while I was
committing). For now that build stops somewere in the NEON
yuv420->yuv422. Måns suspects it being due to memory buffer isn’t
aligned and me having a bad kernel. So perhaps it works for you if your
lucky. I’ll try later tonight getting it to work on my machine.

Just FYI …

My build finished yesterday and it ran once - very slow (no cpu usage
for most of that) and when i tried to play a video it hung at 100%
cpu.

Dirty Region stuff is not enabled by default, not that it makes an extreme difference (less than I anticipated sadly). For rendering of GUI I think its imperitive to get rid of the color multiplications, much more than eventbased.

That is the problem with the video for now, basically that build generates an missaligned intermediate buffer which NEON according to mru locks up on.

I have tried hooking it up “directly” to ffmpeg and it works on one clip, with a bit of stride problems. However I haven’t found the real direct link yet but looking for it so bunny doesn’t work yet and the buffer which is supposed to come from ffmpeg is missaligned (Its not ffmpeg fault, xbmc player or handler is doing something funky).

At any rate, its a bit of progress because one video almost plays and it runs very fast. I’m planning on commiting this as soon as I have cleaned it up abit, its very irradic though and its more hit and miss than actually working :slight_smile:

It left a video overlay around.

Yeah, the clean of overlay is only called on a proper stop/quit. I have verified the code working though.

I couldn’t get gdb to work so I tried updating everything and then
rebuilding everything (320minutes from a make clean fwiw) and now
(after a clean reboot) it just says “ERROR: Unable to create
application. Exiting”

TBH, I have no clue on that one. That log line is only called if application fails to init. As far as I can tell from code it should only happen on these occations:

  • Logging fails to to be initialized.
  • SDL Fails to be initialized
  • Window systep fails to be initialized
  • Window fails to be created
  • Rendering system fails to be initialized (GLES)
    Could you attach the log?

Finally almost there.
http://www.angstrom-distribution.org/~koen/xbmc-20100723.tar.bz2

Just untar in root and run xbmc.

This one actually creates the overlay and uses it for the transform.
NEON for yuv420 -> yuv422 (the one from mru).

It does deadlock after about 8s, looking through code but the time seems
to coincide well with the decode buffer available so perhaps a missing
signal.

fre 2010-07-23 klockan 13:56 +0930 skrev Michael Zucchi:

Isch, pressed send to fast. A little image of the success
http://img844.imageshack.us/i/img20100723210631.jpg/.

Speedwise its definatly whatchable but hard to tell when it doesn't go
beyond 8s. The memcpy is still there for now but it seems possible to
remove atleast in abit of a hack-fashion.

fre 2010-07-23 klockan 13:56 +0930 skrev Michael Zucchi:

My build finished yesterday and it ran once - very slow (no cpu usage
for most of that) and when i tried to play a video it hung at 100%
cpu.

Dirty Region stuff is not enabled by default, not that it makes an extreme
difference (less than I anticipated sadly). For rendering of GUI I think its
imperitive to get rid of the color multiplications, much more than
eventbased.

Ahh well, it was still worth it though? I guess it shows though that
if you're doing optimisation you need a good idea of where the
bottlnecks are first :slight_smile:

Perhaps a tuned theme would be a significant help too? Are there
other themes available somewhere to try?

At any rate, its a bit of progress because one video almost plays and it
runs very fast. I'm planning on commiting this as soon as I have cleaned it
up abit, its very irradic though and its more hit and miss than actually
working :slight_smile:

Good stuff. Looking forward to trying it once I get my system unbroken.

Could you attach the log?

There's no other output, just that. But it looks like the opkg
upgrade broke GLES or some such, so I have to work that out before I
can get anywhere :-/ And nothing i've tried so far has fixed it and I
don't have much time today, but i'm trying another upgrade and i'll
see how that goes.

!Z

lör 2010-07-24 klockan 13:54 +0930 skrev Michael Zucchi:

>>

>> My build finished yesterday and it ran once - very slow (no cpu usage
>> for most of that) and when i tried to play a video it hung at 100%
>> cpu.
>
> Dirty Region stuff is not enabled by default, not that it makes an extreme
> difference (less than I anticipated sadly). For rendering of GUI I think its
> imperitive to get rid of the color multiplications, much more than
> eventbased.

Ahh well, it was still worth it though? I guess it shows though that
if you're doing optimisation you need a good idea of where the
bottlnecks are first :slight_smile:

Hehe, yeah. If XBMC had worked on Angstrom when I started perhaps I
would have spent more time checking through what the bottlenecks were.
Have a much clearer picture on that now though.

At the end of the day, definatly worth it and I'm glad I did it. Now it
is atleast possible to create a limited skin which will work ok for
sure. This was not possible before and a limited skin would have been
almost as slow as a complex one. I just had to invest much more time
into it than I thought (isn't that always the case though :slight_smile: )

Perhaps a tuned theme would be a significant help too? Are there
other themes available somewhere to try?

The biggest problem is that most skins usually fade and alter background
images depending on what you highlight, this looks good but the code
handling this is terribly unoptimzed and fading between 2 images
involves rendering 2 images both with blending enabled. This could be
optimized by not blending at all and fade them using a shader. Needs
some testing though since color multiplication (which this would need)
is needed and is very slow on beagleboard, however I really would
anticipate it being lots slower than rendering 2 quads with blending
enabled (and color multiplication for the alpha).

I have altered a skin (rapier) to not use the background images and
removed some controls which didn't work good with dirty region at that
time and I got almost fluid navigation in home (at 720p) so it greatly
depends on the skin.

Confluence (the standard) was at most 10fps before now it does 20ish
when only the menu blade changes, and 10 when the background changes,
While still slow in 720p its quite a big difference (in the right
conditions).

> At any rate, its a bit of progress because one video almost plays and it
> runs very fast. I'm planning on commiting this as soon as I have cleaned it
> up abit, its very irradic though and its more hit and miss than actually
> working :slight_smile:

Good stuff. Looking forward to trying it once I get my system unbroken.

> Could you attach the log?

There's no other output, just that. But it looks like the opkg
upgrade broke GLES or some such, so I have to work that out before I
can get anywhere :-/ And nothing i've tried so far has fixed it and I
don't have much time today, but i'm trying another upgrade and i'll
see how that goes.

The log goes into ~/.xbmc/temp/xbmc.log and if that one isn't created
that would cause the application failure. Try removing ~/.xbmc/ koen
have needed to do that a few times.

Broken GLES would definatly cause that error though. Just tell me if you
want me to dd my image and upload it somewere?

At the end of the day, definatly worth it and I'm glad I did it. Now it
is atleast possible to create a limited skin which will work ok for
sure. This was not possible before and a limited skin would have been
almost as slow as a complex one. I just had to invest much more time
into it than I thought (isn't that always the case though :slight_smile: )

Definitely worth it then.

The biggest problem is that most skins usually fade and alter background
images depending on what you highlight, this looks good but the code
handling this is terribly unoptimzed and fading between 2 images
involves rendering 2 images both with blending enabled. This could be
optimized by not blending at all and fade them using a shader. Needs
some testing though since color multiplication (which this would need)
is needed and is very slow on beagleboard, however I really would
anticipate it being lots slower than rendering 2 quads with blending
enabled (and color multiplication for the alpha).

Well i'm a little surprised even the base theme is chugging quite so
much. e.g. are there scheduling inefficiencies or just too much
heavy-weight code slowing things down outside of the work being done
(or is the sgx really that slow?)

I have altered a skin (rapier) to not use the background images and
removed some controls which didn't work good with dirty region at that
time and I got almost fluid navigation in home (at 720p) so it greatly
depends on the skin.

Oh, very nice. Maybe that could be the start point for a 'beagle'
branded theme or something?

Broken GLES would definatly cause that error though. Just tell me if you
want me to dd my image and upload it somewere?

It was just that - the second upgrade fixed it. I found out the delay
at the start is it waiting for some dbus crap (perhaps because i'm
just logged into openbox). So the rest of the app is working, but
playing the video's i've got (low res low bitrate) on the machine just
cause an instant segfault which I presume is the 'known issue' right
now

last messages are
GetImage 0
image [0, 0]
FPS: 5.49
Segmentation fault

!Z