From: Eric Nelson <eric.nelson@boundarydevices.com>
To: "meta-freescale@yoctoproject.org" <meta-freescale@yoctoproject.org>
Subject: RFC regarding glimagesink
Date: Sun, 28 Jul 2013 16:44:19 -0700 [thread overview]
Message-ID: <51F5ACD3.8000505@boundarydevices.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]
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
[-- Attachment #2: 0001-gstglwindow_fbES2-allow-window-size-position-to-be-s.patch --]
[-- Type: text/x-diff, Size: 1265 bytes --]
From 409464fc3f49eadac4bf3b7a050b76ab419303a0 Mon Sep 17 00:00:00 2001
From: Eric Nelson <eric.nelson@boundarydevices.com>
Date: Sun, 28 Jul 2013 15:09:19 -0700
Subject: [PATCH] gstglwindow_fbES2: allow window size/position to be specified
through the environment
Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
---
gst-libs/gst/gl/gstglwindow_fbES2.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/gst-libs/gst/gl/gstglwindow_fbES2.c b/gst-libs/gst/gl/gstglwindow_fbES2.c
index 57c02e1..2fb86e2 100644
--- a/gst-libs/gst/gl/gstglwindow_fbES2.c
+++ b/gst-libs/gst/gl/gstglwindow_fbES2.c
@@ -297,6 +297,8 @@ gst_gl_window_new (gulong external_gl_context)
EGLConfig config;
int index = 0;
+ int x=-1,y=-1,w=0,h=0;
+ char const *bounds;
setlocale (LC_NUMERIC, "C");
@@ -319,6 +321,11 @@ gst_gl_window_new (gulong external_gl_context)
}
priv->internal_win_id = fbCreateWindow (priv->device, -1, -1, 0, 0);
+ bounds=getenv("bounds");
+ if (bounds) {
+ sscanf(bounds,"%ux%u+%u+%u",&w,&h,&x,&y);
+ }
+ priv->internal_win_id = fbCreateWindow (priv->device, x, y, w, h);
fbGetDisplayGeometry (priv->device, &priv->device_width,
&priv->device_height);
--
1.8.1.2
next reply other threads:[~2013-07-28 23:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-28 23:44 Eric Nelson [this message]
2013-07-29 14:35 ` RFC regarding glimagesink Rogerio Nunes
2013-07-29 15:08 ` Eric Nelson
2013-07-29 19:29 ` Rogerio Nunes
2013-07-29 19:54 ` Eric Nelson
2013-07-29 20:06 ` Otavio Salvador
2013-07-29 20:11 ` Rogerio Nunes
2013-07-29 20:12 ` Eric Nelson
2013-07-29 20:24 ` Rogerio Nunes
2013-07-29 20:28 ` Rogerio Nunes
2013-07-29 20:06 ` Rogerio Nunes
2013-07-30 9:06 ` Thomas Senyk
2013-07-30 9:52 ` Abhijit Potnis
2013-07-30 10:58 ` Thomas Senyk
2013-07-30 14:14 ` Rogerio Nunes
2013-07-30 14:38 ` Thomas Senyk
2013-07-30 17:26 ` Rogerio Nunes
2013-08-01 8:47 ` Abhijit Potnis
2013-08-01 12:50 ` Otavio Salvador
2013-08-01 13:05 ` Rogerio Nunes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F5ACD3.8000505@boundarydevices.com \
--to=eric.nelson@boundarydevices.com \
--cc=meta-freescale@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.