[meta-freescale] QtMultimedia on i.MX6

[Thomas Senyk]

On Wednesday, 10 July, 2013 19:13:57 Philip Craig wrote:
> On Wed, Jul 10, 2013 at 6:26 PM, Thomas Senyk
> 
> <thomas.senyk at pelagicore.com>wrote:
> > On Wednesday, 10 July, 2013 10:25:09 Philip Craig wrote:
> > > On Wed, Jul 10, 2013 at 9:53 AM, Rogerio Nunes <ronunes at gmail.com>
> > 
> > wrote:
> > > > On Tue, Jul 9, 2013 at 4:14 AM, Thomas Senyk <
> > 
> > thomas.senyk at pelagicore.com>
> > 
> > > > 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?)