Re: QtMultimedia on i.MX6

[Thomas Senyk <thomas.senyk@pelagicore.com>]

On Wednesday, 10 July, 2013 10:25:09 Philip Craig wrote:
> On Wed, Jul 10, 2013 at 9:53 AM, Rogerio Nunes <ronunes@gmail.com> wrote:
> > On Tue, Jul 9, 2013 at 4:14 AM, Thomas Senyk <thomas.senyk@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.


Greets
Thomas