[Arm-netbook] Documentation Proposal

[Vladimir Pantelic]

Iain Bullard wrote:
> I've been looking into ways to usefully access the hardware media decoder, at the moment I think creating an openmax
> integration layer http://www.khronos.org/openmax/  wrapper around the allwinner closed driver would be the most useful
> long term.
>
> For example the Raspberry Pi XBMC release is using openmax to access the hardware media acceleration, take a look at
> this repo https://github.com/xbmc/xbmc-rbp (omxplayer core) for the development work there.
>
> I don't think I'm the only one who's thought this, for example this repo:
> https://github.com/allwinner-dev-team/android_external_cedarx seems to have the OMX headers in place ready for development.
>
> Overall, an openmax IL would allow us to leverage work done for the Rpi but with a wider selection of media acceleration.

I would not do that. OMX is a pain and although people
call it a "standard", every implementation just adds it's
own quirks. Also, it's overly complex for the simple use case
of calling a codec and projects like FFmpeg, mplayer or vlc
all work under the assumption that codecs are used using
a simple open()/decode))/close() API, so most of the OMX
wrappers that I have seen in these projects are just a ton
of code to undo the mess that OMX itself puts around a simple codec.

if you want to to make something reusable, make a wrapper that
e.g. adheres to the FFmpeg/libav codec API, this one is already
well handled inside VLC, XBMC, gst...

just my 2c...