+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Feature Requests (https://forum.kodi.tv/forumdisplay.php?fid=9)
+--- Thread: [LINUX] XBMC for Linux port to ARM architecture CPU and SoC chips? (/showthread.php?tid=35139)
- davilla - 2010-08-26
TugboatBill Wrote:No storage and no lan port? Without that it's a waste of $50.
Last time I checked they make a nifty USB device called a hub to which you can attach all sorts of neat USB devices
- Starstream - 2010-08-26
The HDX-Bone is another Arm player also turned out be running linux and a version of mplayer. Has ethernet and USB storage uses the Telechips 8900 platform, dont know is thats good enough for XBMC.
There's also the Samsung WMG160 but it's probably not a good candidate
* requires DLNA DMC remote control (only available on Samsung/Android I think ?)
* has wireless
* no USB only SD card reader
* Runs WinCE embedded 6.0 with custom player can handle up to 720p
I think Samsung just stuck one of their phone CPU's inside the box these are the details on the CPU after I took it apart
S5PV105X66-LA40
A1008 ARM
N210TMA
- McGeagh - 2010-08-26
The MP-501 is NOT a cortexA8. Although confusingly named, it is actually an ARM9.
If i were to guess (as i dont know for sure) I would say perhaps it could be the ZMS-05 (from ZiiLabs)
The HDX-Bone is quite good. ARM11 based with a Mali-200 GPU (OpenGL ES 2.0)
As for the Samsung WMG160, Im unsure whats in this device... another guess would be a Cortex A8.
- TugboatBill - 2010-08-26
davilla Wrote:Last time I checked they make a nifty USB device called a hub to which you can attach all sorts of neat USB devices
LOL. I missed the USB port. Regardless, I can see it now:
How do I get XBMC to show the correct time?
Why doesn't it show the weather?
Where is my fanart?
- Hannes The Hun - 2010-08-26
we already had some discussion about the HDX bone and AFAIK some guys are in contact with HDX regarding the possibility of a full XBMC port but I wouldn't get my panties wet just yet
- EGOvoruhk - 2010-08-26
Hannes The Hun Wrote:we already had some discussion about the HDX bone and AFAIK some guys are in contact with HDX regarding the possibility of a full XBMC port but I wouldn't get my panties wet just yet
Too late my friend, too late...
- CrashX - 2010-08-26
Some interesection links on HDX and XBMC:
http://www.hdxforum.com/viewtopic.php?f=37&t=2878
ARM hardware codecs by pipe, or SHM? - BrokenCodes - 2010-09-10
ARM platform,
How about using pipe, or shm to send data to external player, that is on a lower layer than XBMC? is it possible without alot of work? if so, can open alot of arm platforms that would be too slow otherwise,by using hardware codecs...
- davilla - 2010-09-10
Using the native API for hw decode is preferred, for example openmax. Otherwise, you might as well just use the XBMC external player API if you can get XBMC compiled on the platform in the first place.
- BrokenCodes - 2010-09-10
No, not exactly what I meant
Openmax can take input from pipe, and from SHM (seperate for Audio and video)
Trident PNX84XX Series CNX api can take data from pipe (with PID for Audio, and PID for Video, or using external dmux)
Sigmatel can take data from pipe, to /dev/stbvsinc and /dev/stbasinc
with the ability to pipe data to hw codec engines, would give the ability to support alot of otherwise too slow devices. (We already do this somewhat with VDPAU, and DXVA, I just mean to pipe the data to a device, or shared mem, or ./configure --enable-hwcodec=<HW Codec LIB>
Where the codec lib uses an agreed upon API to pass compressed audio and video data to external program, or lib, and offer handles for returned decoded data
like:
Code:
struct videoCB{
E_COLORSPACE colorspace;
void * outvid;
void * outaud;
bool *recognized; // returned by called lib, stop on 0, set to -1 on init, 1 means good to go.
void * inaud; //adpcm or pcm data 44100, if 0 ignore audio
locsize * locsize_t; //hsize, vsize, hpos, vpos; //if supported, ask lib to place video in window here...
surface_mask mypos; //if supported, the depth of the expected video (Foreground, Background, invisible, etc)
}this would also make it easier to compile xbmc on devices under strict NDA, without violating the GPL.
- davilla - 2010-09-10
what handles the playback timing ? and would not the external program have to have an existing API that can be used ?
Or are you saying to create a closed source external player that xbmc pipes the data to using complex data structures such as videoCB. Oh. there's the rub, that's a possible GPL violation.
"By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program."
and
"Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking."
from http://www.gnu.org/licenses/gpl-faq.html
- topfs2 - 2010-09-10
Well regarding GPL thats only true if the closed program was made specifically for usage with GPL app. If its done well before and designed to be used by anyone and any program its ok afaik.
- BrokenCodes - 2010-09-10
Here is the scenario... and you tell me how I can solve it equitably, without violation of either
a). The GPL
b). the NDA of the company supplying the API, libraries and headers for the Hardware Codec
I want to port XBMC to a proprietary device (Specs... Dual Core Arm Cortex A9, 600Mhz). The device is under strict NDA with reguards to the hardware codecs. I wish to use the hardware codecs to render VC1, Mpeg2, Mpeg4, DIVX, and WMV video.
Of course all work would be returned upstream.
I think if done correctly, this could serve to enable XBMC to be used on a number of devices that it currently cannot be used on with ffmpeg alone.
- BrokenCodes - 2010-09-10
Does this situation not create a question with reguards to DXVA, in that we are linking (statically, or dynamically) to a proprietary or non-GPL'd library, with GPL software?
- jmarshall - 2010-09-10
If the API is open then it's no problem, as all you're doing is coding against an "operating system" library, which the GPLv2 specifically allows (otherwise there'd be no GPL stuff on Windows full stop.)
The bit where you get into trouble is where the API is not open. Assuming there was some layer that provided an open interface that anyone can code against, then I shouldn't think there'll be an issue.
Cheers,
Jonathan