[meta-freescale] QtMultimedia on i.MX6

[Philip Craig]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20130710/1715246a/attachment.html>