Kodi Community Forum

Full Version: [LINUX] XBMC for Linux port to ARM architecture CPU and SoC chips?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
XBMC does use gles now. But its impossible to tell you what the hardware is capable off without you actually stating what hardware your interested in is.
Well, I think that is kind of what I’m asking…
I am looking for a good arm board but I’m not sure what I’ll need.
Technically I’d like a board that runs XBMC as well as any arm platform can...with support for features that are either already developed or in development (such as hardware decode of video).
My requirements aren’t exactly set in stone because I’m unsure of what the ARM port of XBMC is actually capable of at the moment (hence I asked all the questions above to try to get a feel for what is going on and what system would be best).
However, for me to justify the purchase of any board I do need to know that most the functionality of XBMC is there and working.
First requirement is: FULL video play-back capability of 480p content regardless of codec. I ideally, hardware decode of all major video types (mpeg2, H.264, VC-1, etc.) would be nice as well because most the ARM platforms I’ve been looking at support hardware decode of these types but like I said, I don’t know what work has been done in this direction to supporting hardware decode of video.
Second, FULL audio playback, regardless of codec…flawless handling of supported audio types.
Lastly, hardwired Ethernet connectivity, preferably gigabit.
The reasoning for the above requirements is based in the requirement of function. I love XBMC as a hobby and I’d love to get involved in the ARM port but before I can do that, I need to know that I will actually be able to use this on a daily basis as one of my XBMC boxes in addition to it acting as test hardware for development.
Cheers,
Slice
P.S. answers to these questions and any of the above one in my previous post would be great. thanks
Well, XBMC on arm isn't really prime time ready. So if your looking for something to use everyday I'm not sure you should be looking there (not yet atleast).

I will say though that both tegra2 and panda should do what you want, and pandaboard looks to be the more interesting of them (atleast looking into the future). I and more are rather involved in the panda community and the hardware as such is extremely interesting and will hopefully do more or less everything we want in 1080p. But its still untested and unverified.

I have tried it in SD though and it works, no surprises there really. Played SD content at full speed and rendered GUI in 100+ fps.
topfs2 Wrote:Well, XBMC on arm isn't really prime time ready. So if your looking for something to use everyday I'm not sure you should be looking there (not yet atleast).

I will say though that both tegra2 and panda should do what you want, and pandaboard looks to be the more interesting of them (atleast looking into the future). I and more are rather involved in the panda community and the hardware as such is extremely interesting and will hopefully do more or less everything we want in 1080p. But its still untested and unverified.

I have tried it in SD though and it works, no surprises there really. Played SD content at full speed and rendered GUI in 100+ fps.

Thanks for the reply! I was looking at the panda board myself and I was thinking that it had the most potential and flexibility of any of the boards I have looked at. From your repose, I gather that hardware accelerated video decoding has not been implemented in XBMC for the TI OMAP platform (or another ARM based platform for that matter) but the board has enough horse power to decode 480P content in software (very impressive if you ask me). Anyways, I think I’ve start saving to get a panda board. Once I get it I’ll start dinking around with it and see what can be done…

A few questions though…

1. Are the libraries for video decoding on the TI OMAP platform open source? Or has TI just published the API like NVidia did with VDPAU on Linux?

2. Do the libraries and APIs vary across the TI OMAP line of products or are they the same? Reason I ask is if I’m going to start work on trying to implement this stuff I would like to only have to do it once and have it work on all the TI OMAP chips that support hardware video decoding (just like vdpau works on all the nvidia chips that support it, once vdpau was implemented, it worked across many nvidia gpus).

3. As I understand it, the core libraries that XBMC uses for video playback also have to have support for the hardware acceleration in order for it to be implementable. Do any of you guys know if any of the developers of these libraries are working on implementing TI OMAP hardware decoding? (I did a little bit of googling and it would seem as though FFMPEG has/is working on some sort of support for OMAP).

Anyways, I look forward to contributing and trying to figure this stuff out…

cheers,
ARM is rather segregated actually. Most modern support OpenMAX which is meant to be what OpenGL is for graphics but for media. According to some it falls short, I don't know enough to tell. XBMC have support for OpenMAX under the tegra2 platform, however its not as with OpenGL and just plug and play with Panda. I will be working on this when I get time, damn school.

So as with OpenGL the drivers for OpenMAX aren't open, but the API is, which is enough (most of the time).

And yes, it does SD purely on CPU, but this is possible on beagle also, which has a much slower CPU. Both cards have a DSP which can be used for decoding but afaik there is no open solution for it.

While we use ffmpeg for decoding in software as a fallback I have added hw scaling, translation and yuv->rgb support for the omap platform as a part of my google summer of code project (thanks to omapfb sourcecode). This makes SD content ok on beagle c4, anything beyond SD is kindof a nogo without tapping into the DSP.

Most of my GSoC stuff can be read http://xbmc.org/topfs2/ and http://beagleboard.org/project/XBMC/
The video (not my video) is BeagleBoard xM and its decoding SD in software and (displaying using hardware overlays I think, not sure actually).
As soon as I get my monitor I will probably post a video off it running on the panda.
Unfortunately, I have had no luck in obtaining a pandaboard as of yet. sucks...

phusho, hows mali development going? I would still really like to see some patches.
CrashX Wrote:OMAP4 support in FFmpeg: http://omappedia.org/wiki/PEAP_Projects#..._in_FFmpeg

I found this as well... I have contacted the person heading up the project but have yet to receive a response. I'm hoping some sort of progress is under way because as i understand it, this could more or less lead to turn-key support for hardware video decoding... looking forward to hearing back. I'll keep you guys posted.

cheers,
Hey folks,

I'm new to this Forum but I follow the progress of XBMC since about 6 Months and I'm very impressed of all the possibilities with XBMC.

Actually I'm very interested to have a little client like a PandaBoard which has acces to a server with DVB-T/C/S and TVHeadend.

Is it very complicated to make it run? I'm not a computer science Student, so I'm not a pro, but i already compiled things. So if it is not to hard to do this, cold you post a (little) how to? I'd like to test it and i could give you some feed back.

I don't have a PandaBoard yet, but Xmes is not far Wink

Sorry for my bad english...
OK little update I have inserted telechips decoders inside and decoding is fully hardware accelerated on 1080p. Have troubles to make interface layer transparent to see video. Tried topfs patches for dirty regions - result was almost 10 fps less and big artifacts in picture. Mali 200 is tile based hardware and some of the operations are done different than traditional hardware - one of them is clear buffer(always clear entire buffer). result is only moving parts are shown other is black. I have disabled draw complete and CPU is still on 100 % so this platform is CPU bound. I have rewritten some of the matrix functions in asembler to take advantage of the VFP unit, but need some work more. Default skin is at 35-45 FPS (depend on scene).

P.S. I spilled some coffee on my keyboard and mu "r" key is nor working very well so if there is missing some 'r'-s my apologies
phusho Wrote:OK little update I have inserted telechips decoders inside and decoding is fully hardware accelerated on 1080p. Have troubles to make interface layer transparent to see video. Tried topfs patches for dirty regions - result was almost 10 fps less and big artifacts in picture. Mali 200 is tile based hardware and some of the operations are done different than traditional hardware - one of them is clear buffer(always clear entire buffer). result is only moving parts are shown other is black. I have disabled draw complete and CPU is still on 100 % so this platform is CPU bound. I have rewritten some of the matrix functions in asembler to take advantage of the VFP unit, but need some work more. Default skin is at 35-45 FPS (depend on scene).

P.S. I spilled some coffee on my keyboard and mu "r" key is nor working very well so if there is missing some 'r'-s my apologies

Yeah thats the problem on beagle also, their GPU is also tile based so the gain is not as big as one would assume. I found this out after the implementation was done, however I overall gained fps not lost atleast Smile Are you sure your not CPU bound, because current implementation of the dirty regions add quite a significant CPU load (this can be lowered significantly by introducing event rendering though.). Which of the dirty region solvers did you use? And yeah, there are quite some artefact's currently, that + cpu load why its not in trunk yet Smile

Does your machine use NEON and is that what you used to boost the matrix transformations? If so I'd love to test some patches, the cpu load is far from high on beagle or panda but would be cool to see how much difference it is.


snoopy159 Wrote:Hey folks,

I'm new to this Forum but I follow the progress of XBMC since about 6 Months and I'm very impressed of all the possibilities with XBMC.

Actually I'm very interested to have a little client like a PandaBoard which has acces to a server with DVB-T/C/S and TVHeadend.

Is it very complicated to make it run? I'm not a computer science Student, so I'm not a pro, but i already compiled things. So if it is not to hard to do this, cold you post a (little) how to? I'd like to test it and i could give you some feed back.

I don't have a PandaBoard yet, but Xmes is not far Wink

Sorry for my bad english...

PandaBoard is far from end-user ready, i.e. its not just apt-get install xbmc and your done. That being said its not that hard atm, biggest problem is python which I had to disable (can provide patch for that), I know davilla compile external instead which is also ok, but you need to compile and provide python 2.5 as ubuntu does not. The other problem is that the SGX (GPU drivers) does not provide any GLES headers so you need to uninstall them to compile XBMC on target, which is more than annoying (I have notified the ubuntu panda devs and they are working on it). Crosscompiling should make this a non problem though.

I plan to write up a blog post about how it works on panda (along with video) and can probably add some documentation about what is needed to compile (when you have patches its not really harder than on normal ubuntu).
topfs2 Wrote:Yeah thats the problem on beagle also, their GPU is also tile based so the gain is not as big as one would assume. I found this out after the implementation was done, however I overall gained fps not lost atleast Smile Are you sure your not CPU bound, because current implementation of the dirty regions add quite a significant CPU load (this can be lowered significantly by introducing event rendering though.). Which of the dirty region solvers did you use? And yeah, there are quite some artefact's currently, that + cpu load why its not in trunk yet Smile

Does your machine use NEON and is that what you used to boost the matrix transformations? If so I'd love to test some patches, the cpu load is far from high on beagle or panda but would be cool to see how much difference it is.

Yes I am CPU bound. Optimizations are made for ARM 1176 with VFP unit, not NEON. I have tried all solvers result was more or less same. Black screen with moving RSS control Smile. On animation all is OK. Do you have some suggestions about event rendering system?
phusho Wrote:Yes I am CPU bound. Optimizations are made for ARM 1176 with VFP unit, not NEON. I have tried all solvers result was more or less same. Black screen with moving RSS control Smile. On animation all is OK. Do you have some suggestions about event rendering system?

Ah, well considering that your CPU bound I wouldn't touch dirty region for now, even if it _might_ help its probably better to focus on getting CPU load down. Event rendering is a really big thing to tackle tbh.

As you said, the transformations is where we spend quite a bit of CPU so thats a good place to start, another is font rendering which is one of the biggest loads in XBMC currently, the idea that have been discussed to lower it is by creating either a VBO per text and transform it instead of generating it all the time. i.e. somthing along the lines like int bar = CFont::GenerateText("foo", colour, ...); and CFone:Big GrinrawText(bar); instead of building and drawing it on glyph basis per frame. Could also use draw to texture instead of VBO but if your not GPU bound (polygon bound) you gain quite a bit by going VBO (memory mostly).

So I'd try commenting out font rendering and see how that helps.
Another area that needs some asm/vfp love is mathutils::round, that's high on the hit list when profiling and the routines in mathutils::xxxx need to be converted to asm in the same way as on x86 platforms.
oprofile is a great tool for finding out the bounding factor, I found on beagle and angstrom that something was really wrong with SDL mixer (isnt it always SDL...) and when I disabled GUI sounds I went from 100% to 20%.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48