2011-11-23, 06:41
davilla Wrote:No problem there, hw video decode renders to a video plane that is below GLES. GLES does not even know it's there except for the dest rect of the video. That is blended in GLES so the video area shows through. OSD (overlays) just work No idea when it will become public, I'm not in the driver's seat regarding code release on this particular project.
ok, interesting.. this sounds fairly similar to what I'd like to accomplish.. (tho' possibly w/ X11 in the middle.. although that may not strictly be required, but was just an idea to try and have more of a standard interface for a renderer rather than something too omap specific..)
davilla Wrote:Your X11 idea is interesting but that will not help most embedded where X11 is way too much overhead to tolerate.
just fwiw, I'm running now xbmc fullscreen, without a window manager.. in this setup, other than an extra context switch, there isn't really any runtime overhead introduced by X11. Ie. swap-buffers is just a page-flip ioctl and a pointer swap on kernel side, no extra GPU copy. That isn't necessarily the case if you are not full screen, or have a compositing window manager that doesn't bother to un-redirect fullscreen windows.
(ok, I guess there is some RAM and filesystem size footprint too.. not sure if that is what you meant..)
davilla Wrote:If you look at XBMC code, you will also see a directfb implementation for GLES. That's used under sigma where like other embedded platforms, hw video decode is rendered to a video plane that is actually under the GLES layer.
ok, cool, I'll have a poke around that bit of code over the upcoming long weekend to see if that gives me some ideas.