<div dir="ltr"><br><br><div class="gmail_quote">On Tue, May 22, 2012 at 11:33 AM, Iain Bullard <span dir="ltr"><<a href="mailto:iain.bullard@gmail.com" target="_blank">iain.bullard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've been looking into ways to usefully access the hardware media decoder, at the moment I think creating an openmax integration layer
<a href="http://www.khronos.org/openmax/" target="_blank">http://www.khronos.org/openmax/</a> wrapper around the allwinner closed driver would be the most useful long term.<div><br></div><div><div>For example the Raspberry Pi XBMC release is using openmax to access the hardware media acceleration, take a look at this repo <a href="https://github.com/xbmc/xbmc-rbp" target="_blank">https://github.com/xbmc/xbmc-rbp</a> (omxplayer core) for the development work there.</div>
<div><br></div><div>I don't think I'm the only one who's thought this, for example this repo: <a href="https://github.com/allwinner-dev-team/android_external_cedarx" target="_blank">https://github.com/allwinner-dev-team/android_external_cedarx</a> seems to have the OMX headers in place ready for development.</div>
<div><br></div><div>Overall, an openmax IL would allow us to leverage work done for the Rpi but with a wider selection of media acceleration.</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div>
</blockquote><div><br></div><div>I don't really like the seperate OMXplayer solution of the RPi. It basically means NO PVR as that version is only using the xbmc inbuild dvdplayer. Considering the Mele and the zomming huge load of STB like boxes, PVR sounds like a very good version to me.</div>
<div><br></div><div>I also opt for a gsteamer option. But I will leave it up to Gimli </div></div></div>