On Wed, Jul 10, 2013 at 6:26 PM, Thomas Senyk <[email protected]>wrote:
> On Wednesday, 10 July, 2013 10:25:09 Philip Craig wrote: > > On Wed, Jul 10, 2013 at 9:53 AM, Rogerio Nunes <[email protected]> > wrote: > > > On Tue, Jul 9, 2013 at 4:14 AM, Thomas Senyk < > [email protected]> > > > > > > wrote: > > > > On Friday, 05 July, 2013 13:16:23 Rogerio Nunes wrote: > > > >> Repository is public now. > > > >> I only have the code from BSP 1.1.0 there yet, but I'll add 4.0.0 > this > > > >> afternoon. > > > >> > > > >> BTW, I still need to update the gst-plugins-gl recipe in the > > > >> meta-fsl-arm layer to point to this repo. It's cleaner than the > patch > > > >> we currently have in the recipe. > > > > > > > > Sounds wonderful! > > > > If something is ready to test, let me know. > > > > > > Very small change from previous BSP to 4.0.0 in the gst-plugins-gl > > > package: > > > > > > > https://bitbucket.org/Freescale/gstreamer-gst-plugins-gl/commits/1d6c0abf2 > > > 17a90e160fd7e4c45f02a23da974130?at=fsl-0.10 I've just sent a patch to > the > > > list (awaiting approval as it was big...) to update meta-fsl-arm. > > > > > > In the bitbucket repo, branch fsl-0.10 has commits that reflect "as is" > > > packages from the BSP. > > > My idea now is to work on branch 0.10 to generate a set of patches > that we > > > can upstream. > > > I would appreciate any help. > > > > I can't speak for upstream, but do note that gstreamer 0.10 is no longer > > maintained, and gst-plugins-gl has recently been updated to 1.0, so it > > might be worth checking if upstream will accept 0.10 patches before > working > > on them. > > ... again ... a rather long mail ;) > > > I kind a gave up on 'glupload' (and therefor on gst-plugins-gl) yesterday > evening. > It sounded very good at first, but after a while I realized it can't work > in > it's current implementation/API ... it least not without X (which is a no > go > for my in any case) > > What I wanted to achieve: > Being able to use textures 'filled' by gst-plugins-gl within Qt's OpenGL > SceneGraph. > > Why IMO it will not work: > glupload has to create it's own EGLContext, for that one needs displays and > window. > The problem is that the current implementation does that be using the > vivante- > linuxfb-API which results in a separated, independent "connection" to the > display. > This means glupload's "external-opengl-context" is not usable as any > provided > EGLContext will be bound to another display connection (I tried and > failed, if > it's supposed to work but I'm doing something wrong, I'm happy to try again > with help) > > This means you'll never be able to use the generated textures outside of > gstreamer. ... I think ;) > The only use-case left is to use glimagesink to render to framebuffer > directly, > maybe adding some gstreamer-gl-effects or something. > > This is not what I indented to achieve (although I've already marked it as > my > back-up plan and doing it in QtMultimedia is trivial, if someone wants to > try > that solution let me know and I tell you what to change) > > To achieve what I want I thing the only viable solution would be to replace > the "external-opengl-context" with a 'makeGLContextCurrent'-callback ...so > that the EGLContext can be created and managed by the UI-framework rather > then > the multimedia-framework... but I'm not eager to fiddle around with > gst-API ;) > > > > If I'm wrong with any part and it's actually possible to use textures > generated by gst-plugins-gst outside of gstreamer (without X/other > 'windowing > manager'), I happy to try again if someone has a hint/idea how the stack > should look like. > > > > In the mean while I have an alternative plan: > The important part the thing is replacing the cpu based texture upload > (copy) > with a vivante-based memory-mapping ('no-copy'/'zero-copy') > Today I'm going try to implement this (using the gst-plugins-gl code as > reference) within QtMultimedia. > I'm very new to opengl, but your analysis sounds correct to me. You might be interested in looking at the qt-gstreamer package. It has a qtglvideosink plugin which uses the context you give it, rather than creating its own display etc. I did try using it, but I was trying to use a QGLWidget to get the context, and it seems to be incompatible with eglfs. It displays fine on my laptop with xcb. Maybe you know an alternative way of getting a context when using eglfs.
_______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
