[meta-freescale] RFC regarding glimagesink

[Rogerio Nunes]

Hi Eric,

I've been usually working without X, so don't know much about glimagesink.
I have some comments about bitbuck branches bellow.

On Sun, Jul 28, 2013 at 7:44 PM, Eric Nelson
<eric.nelson at boundarydevices.com> wrote:
> 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?

fsl-0.10 - branch with  "as is" code from fsl BSPs.

yocto-0.10 - branch with patch(es) from the poky layer

0.10 - branch to merge fsl-0.10, yocto-0.10, upstream-0.10 and to
refactor the code to port to master (still ongoing)

>
> 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
>
> _______________________________________________
> meta-freescale mailing list
> meta-freescale at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>