From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 9D20BE013CB for ; Wed, 10 Jul 2013 01:26:17 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c50so4643943eek.25 for ; Wed, 10 Jul 2013 01:26:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding :content-type:x-gm-message-state; bh=XaobOsNHWN28UdEAHRrg993NAF3H3oPdgPcZ6Ej+Vgw=; b=omYxzPIHgwQM7F5Ppy4D7WpBiFEc1S8xiibqu3quNp9vq3Z9OCzir379sMijFpf5ND mX2dDRCihSJRe7JiHvtkCs3h6DJK5w/0Mx63ioFqdu1mg/NZ51EKW5DjJqUhVdN7dT+1 UsvQmjLkl9JhHlOqhP1RtX3EDPGwL5qjUGk7c13QlhaSaQZIc6NeA+8Rs7l0B0nsrjbN 2J4D/srEaGILjUaRvmdDk+F0KNd99uYyFcRkufTXNPYlOK/j99A0kIEX4AweekwdrtIx iwM0QYhh/gmk+5SAAbuFrbQrVRKqmpwois7JNYxmZ0AsidVZnv8D/XHtK8c/GuyUXrtE nTQg== X-Received: by 10.14.87.133 with SMTP id y5mr34922981eee.50.1373444776780; Wed, 10 Jul 2013 01:26:16 -0700 (PDT) Received: from rudolf.localnet (ppp-82-135-84-132.dynamic.mnet-online.de. [82.135.84.132]) by mx.google.com with ESMTPSA id ci50sm57978429eeb.12.2013.07.10.01.26.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 01:26:16 -0700 (PDT) From: Thomas Senyk To: Philip Craig Date: Wed, 10 Jul 2013 10:26:02 +0200 Message-ID: <10916628.lYxibBCHga@rudolf> Organization: Pelagicore AG User-Agent: KMail/4.10.4 (Linux/3.9.8-1-ARCH; KDE/4.10.4; x86_64; ; ) In-Reply-To: References: <1797012.Po2ZnTUHJW@rudolf> MIME-Version: 1.0 X-Gm-Message-State: ALoCoQk/VZBaf970328XJJHuSkQIdTDDAVZMjI25HWqBNOt7EIWNpyGeEPR0Zd8OSTYOsJyqftYH Cc: "meta-freescale@yoctoproject.org" , Otavio Salvador , Rogerio Nunes Subject: Re: QtMultimedia on i.MX6 X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 08:26:19 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Wednesday, 10 July, 2013 10:25:09 Philip Craig wrote: > On Wed, Jul 10, 2013 at 9:53 AM, Rogerio Nunes wrote: > > On Tue, Jul 9, 2013 at 4:14 AM, Thomas Senyk > > > > 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