On Wednesday, 10 July, 2013 19:13:57 Philip Craig wrote: > 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.
But this is not imx6 specific, is it? If it's not: we can't get to a optimized stack without using the vivante- opengl ui If it is: I'll take a look (where to find?) _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
