[meta-freescale] RFC regarding glimagesink
Eric Nelson
eric.nelson at boundarydevices.com
Sun Jul 28 16:44:19 PDT 2013
Hi all,
I spent some time looking at the internals of glimagesink
yesterday with the thought that it should be capable of
doing some things that our customers are currently doing
via mfw_isink (in the non-X case).
In particular, I was hoping to shoe-horn some element
properties for window positioning.
I had previously noted that the fbCreateWindow() routine
accepts parameters for window positioning, but it was
currently hard-coding things for full-screen:
https://bitbucket.org/Freescale/gstreamer-gst-plugins-gl/src/1d6c0abf217a90e160fd7e4c45f02a23da974130/gst-libs/gst/gl/gstglwindow_fbES2.c?at=fsl-0.10#cl-321
That module is also trying to configure some properties, so
adding "x,y,w,h" shouldn't be very hard.
Unfortunately, it appears that things are not quite as
they appear. The gstglwindow_fbES2 isn't properly a
gstreamer element, and appears to be invoked in-directly
through the glimagesink element.
Does anybody know of a way to set the properties of the
GstGLWindow element created by the fbES2 module?
If so, can this be done through gst-launch, or only
by an app?
I hacked up a quick test of the idea, as shown in
the attached patch that reads the window "bounds"
from the environment and the results are promising.
I was able to play three instances of 1080P video in
three separate windows and the overall system load
was quite low (~7%).
I did run into a couple of issues, but these are systemic
and didn't stem from this patch:
- In high-motion sections of video, tearing is evident
because nothing's doing frame flipping.
- I had to play whack-a-mole with memory allocation
failures. I was able to get 2x1080P to run in
a loop overnight, but attempts to run 3 fail pretty
quickly after the first iteration. I suspect that
tuning the various drivers' allocations as done
in Jack's patch is needed to make this stable:
https://community.freescale.com/thread/304368
The first of those above highlights the need for a compositing
layer, which clearly needs cooperation of the toolkit used
for the rest of the U/I.
By the way, the attached patch is against branch fsl-0.10
in the Bitbucket tree, which appears to match up with the
Yocto build, but I notice that Jeremy has a patch applied
in the Yocto-0.10.
Is 'fsl-0.10' the right baseline to use for future work?
I'm interested in hearing the experiences of others with
this component.
It seems to me that there's a lot of function in this
code base, but if it's restricted to full-screen operation,
it's not very useful.
That said, I have yet to explore the other elements in the
package.
Regards,
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gstglwindow_fbES2-allow-window-size-position-to-be-s.patch
Type: text/x-diff
Size: 1227 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20130728/ccfe9612/attachment.patch>
More information about the meta-freescale
mailing list