[meta-freescale] QtMultimedia on i.MX6
Thomas Senyk
thomas.senyk at pelagicore.com
Wed Jul 10 01:26:02 PDT 2013
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.
Greets
Thomas
More information about the meta-freescale
mailing list