2011-11-22, 19:49
We supported a small subset of OpenMAX with respect to hw video decode for tegra2. I'm not sure how current that code is anymore, I've not worked on tegra2 since eons ago.
The main issue with omx is, moving decoded picts from omx into our renderer to fit the 'dvdplayer' model. Also some omx implementations want to also handle the rendering and that's where things get complicated with respect to retaining the 'dvdplayer' model.
topfs2's gstreamer only handles video decode and is more a proof of concept. I've done a complete internal gstplayer for another project, unfortunately that code cannot be made public yet.
Make no bones about it, gstreamer is a bitch and openmax is even more of a bitch. Neither is a simple API and both have pitfalls that you have to deal with. It's non-trivial.
As for vaapi-egl, I've not seen anything yet that does hw video decode on arm, only x86 (yes, they can run gles as in cex41xx)
The main issue with omx is, moving decoded picts from omx into our renderer to fit the 'dvdplayer' model. Also some omx implementations want to also handle the rendering and that's where things get complicated with respect to retaining the 'dvdplayer' model.
topfs2's gstreamer only handles video decode and is more a proof of concept. I've done a complete internal gstplayer for another project, unfortunately that code cannot be made public yet.
Make no bones about it, gstreamer is a bitch and openmax is even more of a bitch. Neither is a simple API and both have pitfalls that you have to deal with. It's non-trivial.
As for vaapi-egl, I've not seen anything yet that does hw video decode on arm, only x86 (yes, they can run gles as in cex41xx)